April 2021


  1. Secure Shell lets you securely connect to remote servers. You connect using an account that exists on the remote server. Once you’ve connected you’ll be dropped into a shell session.

  2. The computer you connect from is the “local” or “client” computer. The computer you connect to is the “host” or the “server”.

  3. When you’re connected to the server using SSH, any commands you input from the client are sent securely and privately (through a “tunnel”) to the remote computer, where the commands are executed.

  4. SSH is implemented using the client-server model. The server must be running a small app to listen for SSH connections. This kind of app is called a daemon (pronounced day-mon). For SSH to work, the host must be running the SSH daemon. The SSH daemon listens for connections on a specific port (22), authenticates connections requests, and (if the connection request is approved) it will spawn the correct environment. The correct environment is a terminal session.

  5. The client (the computer you connect from) must be running an SSH client, which is a small app that can communicate using the SSH protocol. (A protocol is a set of rules.) It needs to be able to receive information about which host to connect to, which user to connect as and which credentials to use when trying to connect.


Passwords and Keys

  1. Clients authenticate using passwords or keys. Passwords are less secure than keys. Keys are very secure. You can also connect using no authentication by specifying a particular IP address I think.

  2. Passwords are encrypted, and are conceptually familiar, but can (and will) be brute forced. There are tools that will block repeated attempts or block/allow authentication attempts from particular IP addresses.

  3. SSH keys using public and private (or secret) key pairs and are very secure. Keys are generated in pairs. The public key can be shared freely without concern. The secret key must be kept as secure and secret as a password.

  4. To authenticate using a key pair, the client must have both keys (a key pair) on their computer. The server must have the public key in a file called authorized_keys. If the server has the private key then something has gone wrong and you should be alarmed.

The server stores the public keys of users who can connect as a particular user in the file ~/.ssh/authorized_keys. The file contains a list of public keys, one public key on each row.

  1. The default location to store the public key on the remote server is in the users home folder in a subdirectory called .ssh/authorized_keys. The full path would be ~/.ssh/authorized_keys


  1. When a client wants to connect to a server using SSH, it tells the server which public key to use. The server then checks in the authorized_keys file for the public key.

  2. A unique session ID is generated and shared between the client and server.

  3. If the server has the same public key that the client sent when it began the connection attempt, the server generates a random string and encrypts it using the public key. This random string can only be decrypted using the private (secret) key associated with the public key.

  4. The server sends the encrypted string to the client. The client decrypts it using the secret key and combines the original random string with the session ID. The client then hashes the combined string and sends the hash back to the server.

  5. The server already has the hash of the string combining the original random string and the session ID. If the hash from the client matches the hash on the server, the server can be sure that the client has the private key.