Secure Shell

Created August 16, 2025 • Last modified September 02, 2025 @ 12:43 AM

Secure Shell (SSH) is a protocol that is used to establish secure, encrypted connections between a client device and a remote server.

Basic Usage

Establishing an SSH connection to a remote host requires the installation of an SSH client. On Linux, OpenSSH is a popular choice. MacOS and modern versions of Windows both come with an SSH client out of the box, although some configuration might be required on Windows to use it. Once the client is installed, you can establish a connection by running

ssh <username>@<remote host IP>

Provided that the remote host is configured to accept SSH connections on the default SSH port (port 22), the remote host will prompt you for the password.

SSH Key Pairs

As long as the remote server you wish to connect to is configured for it, SSH connections can also be established with SSH key pairs, which are asymmetric keys generated with very cryptographically strong public key algorithms. One key pair contains two keys, a private key and a public key.

The public key can be freely shared with anyone, but the private key must be kept secret from everyone but the client. The reason the public key can be shared with anyone is because the keys are asymmetric, and so the public key can only encrypt data, it cannot decrypt anything. The private key, however, can decrypt data that was encrypted by the public key, and so if someone else gets hold of your private key, they can also decrypt all of your SSH traffic.

You can generate an SSH key pair using the ssh-keygen command. Then, you can add your public key to a remote server’s authorized_keys file (that you can authenticate into with either a password, a separate key pair, or other means) by running the ssh-copy-id command. Once your public key is added to a remote server’s authorized_keys file, you can open a connection and authenticate automatically, eliminating the need to enter a password. This feature can be disabled by the remote server’s administrator with options in the sshd_config file though.

Security Considerations

In a hardened SSH server configuration, password authentication is often disabled and authentication is only accepted through a more secure method, like public key authentication.

A properly hardened SSH server configuration will often change the SSH port to something other than the default SSH port 22, as this will filter out a great deal of malicious SSH connection requests. Still, for the determined adversary, finding the port that is open for SSH connections is often as simple as running nmap.

Configuration

SSH configuration is handled primarily with two files:

  • ssh_config configures the SSH client, i.e., how the machine connects to remote servers. On Linux, it can be configured for specific users at ~/.ssh/config or system wide at /etc/ssh/ssh_config.
  • sshd_config configures the SSH server, i.e., how the machine handles incoming SSH connections from other clients. On Linux, it is configured system wide at /etc/ssh/sshd_config.

Each configuration file has many options that allow for very specific control over how SSH operates on the client or server.

ssh_config

One common option for the ssh_config file is to specify default values when connecting to specific hosts. For example,

Host server
    HostName server.address.com
    User admin
    Port 25231
    IdentityFile ~/.ssh/id_rsa_server

would set a default user called admin, a default port 25231, and a default private key at ~/.ssh/id_rsa_server to be used when connecting to the host server. So, the command

ssh -i ~/.ssh/id_rsa_server -p 25231 admin@server.address.com

simplifies down to ssh server. In this sense, many configuration options in ssh_config are for convenience and preference.

sshd_config

The sshd_config file is all about keeping the server secure. For example, a common set of configuration options in sshd_config (options that I use for the web server that serves this website) are

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

These configuration options do what they sound like, but just to be clear:

  • PasswordAuthentication no disables password authentication, so even if you know a username and password combination for an actual account on the server, you won’t be able to establish a connection with the credentials. So maybe you’re asking how you can login at all if you can’t use the password. The next option takes care of that:
  • PubkeyAuthentication yes enables authentication via public key. The public key that generates when you run ssh-keygen will allow you to login to the server so long as the public key is in the server’s authorized_keys file.
  • PermitRootLogin no disables establishing SSH connections with the root user, which goes a long way to limit the attack surface of the server with regard to SSH connections.