How SSH works
SSH gives you a text-based session on the server itself, as though you were sitting in front of it. You type commands and the server carries them out: copy a directory, export a database, read the tail of an error log, clear a cache, run an update. Everything travelling between your machine and the server is encrypted.
You authenticate either with a password or with a key pair, and the key pair is the better option. A key pair is two matching files: a private key that never leaves your computer, and a public key placed on the server. Access is granted by proving the two correspond, so there is no password to guess, phish or reuse elsewhere.
Secure file transfer rides on the same connection, which is why hosts offering SSH almost always offer SFTP alongside it.
Why SSH matters
Some jobs are practical only from the command line. Copying a large site between servers, importing a database too big for a browser upload, searching thousands of files for an injected script, or running a content management system’s own command-line tools are all far quicker this way, and occasionally possible only this way.
For migrations in particular it is the difference between a clean move and a lossy one. Transferring files directly from server to server preserves permissions and timestamps, and avoids the slow, failure-prone route down through a home internet connection and back up again.
Where SSH goes wrong
Access handed out casually is the main risk. An SSH login is usually the widest access a server offers, and password-based logins on a public address attract constant automated guessing. If the account carries administrative rights, one weak password is the whole server.
The second is running commands nobody understands. Pasting a fix from a forum into a production shell has destroyed more sites than any attacker. There is no confirmation dialogue and no undo.
The third is forgetting to revoke. Keys left on a server after a contractor moves on keep working indefinitely and silently, because nothing expires them on its own.
What to do about it
If you do not administer servers, you probably do not need SSH, and that is a perfectly reasonable answer. Ask your host or your developer to run the task, or use the tools in your hosting control panel instead.
If you or your team do use it, insist on key-based authentication with password logins disabled, one key per person rather than a shared one, and a written record of who holds access so it can be withdrawn. Take a backup before any command that writes, and rehearse anything unfamiliar on a copy of the site rather than the live one. During a hosting migration that discipline is what keeps a bad hour from becoming a bad week.