SSH and SFTP

To administer a server or edit a site's files, you need to connect to it remotely. For a long time, Telnet and FTP did that by sending the password in plain text, readable by anyone along the way. SSH encrypts the entire session and verifies the server's identity. The most widespread implementation, OpenSSH, ships on nearly every Linux server and is built into recent versions of Windows and macOS.

SSH: the remote terminal

A command such as ssh user@example.com opens a terminal on the server, on port 22 by default. From there you run commands as if you were sitting at the machine: reading logs, counting files, or using WP-CLI to manage WordPress. On the first connection, the client shows the fingerprint of the server's key: checking it protects you against an intercepted connection.

SFTP: files over the same channel

Despite its name, SFTP has nothing to do with FTP: it's a subsystem of SSH. The usual clients (FileZilla, WinSCP, Cyberduck) support it, with the same username and the same port as SSH. Don't confuse it with FTPS, which adds TLS to classic FTP. On shared hosting, SFTP access is sometimes available without a shell, and it then runs inside the account's isolated environment, for example with CageFS.

Key-based authentication

Instead of a password, SSH accepts a key pair. Since OpenSSH 9.5, ssh-keygen creates an Ed25519 key by default: the private key stays on your computer, and the public key is added to the account's ~/.ssh/authorized_keys file on the server. When connecting, the client proves that it holds the private key without ever sending it.

ssh-keygen -t ed25519
ssh-copy-id user@example.com

Protect the private key with a passphrase: the ssh-keygen documentation recommends 10 to 30 characters that are hard to guess. A stolen key without a passphrase opens the server just like a password would.

Hardening the SSH server

On a VPS or a dedicated server, the /etc/ssh/sshd_config file controls the service. By default, PasswordAuthentication is set to yes and PermitRootLogin to prohibit-password (root can log in, but not with a password). Once your keys are in place and tested from a second session:

• set PasswordAuthentication to no, which makes brute force attacks on SSH passwords pointless;
• set PermitRootLogin to no and use a personal account with sudo;
• restrict the allowed accounts and, if possible, the source addresses.

For WordPress

• Switch from FTP to SFTP in your client and with your contractors, and delete unused FTP accounts.
• Give each person their own access, with their own key, removed when the job is over.
• Check the permissions of uploaded files: our article on 644 and 755 permissions gives the right values.
• If you suspect a hack, SSH gives you access to the diagnostic tools described in our guide is my site hacked?