SSH stands for Secure Shell. It is a protocol to connect to remote machines over TCP/IP. It is like HTTPS(or TLS) with addons. HTTPS only transfers files. SSH can do much more than just transferring files.
SSH protocol defines a server and a client. The server is the machine you want to connect to, and the client is the machine you are connecting from. The server listens on a port (default is 22) and the client connects to that port.
There are several ways to log into the ssh server. One way is to use a username and password. This mechansim is generally not recommended as it does not scale as number of hosts increase. The server asks for a username and password(or certificates/keys), and if they are correct as per the remote OS, the client is connected to the server.
The other mechanism is to use certificates. Certificates are like keys. The server has a public key and the client has a private key. The client sends the public key to the server and the server checks if the client has the private key. If the client has the private key, the server allows the client to log in.
Before SSH
Before SSH, there was telnet. Telnet is a protocol that allows you to connect to a remote machine and execute commands. The problem with telnet is that it is not secure. The data is sent in plain text. This means that anyone who is listening to the network can see what you are typing. This is a big security risk. There was rsh and rlogin before telnet. They were also insecure.
Over time SSH has become the de facto standard for connecting to remote machines. It is secure and easy to use. It is also very flexible and can be used for a wide range of tasks. It replaced ftp with sftp, telnet/rsh/rlogin with ssh and rcp with scp.
Protocol Vs Product
There are several implementations of the SSH protocol. The most popular one is OpenSSH. OpenSSH is an open-source implementation of the SSH protocol. Other implementations are SSH.com, Tectia, etc. OpenSSH is widely used because it is secure, reliable, and easy to use. It is also free and open-source, which means that anyone can use, audit and modify it.
How SSH works
Stage 1 : Handshake
When you connect to a remote machine using SSH, the client and server exchange keys. This is called the SSH handshake. The keys are used to encrypt the data that is sent between the client and server. This ensures that the data is secure and cannot be read by anyone who is listening on the network. This key is symmetric and is used to encrypt the data that is sent between the client and server. This key is different from the public/private keys used for authentication. This key is used to encrypt the whole connection so that no eavesdropper can listen to the conversation.
- The client connects to the server on port 22.
- The server sends its public key to the client.
- The client generates a random number and encrypts it using the server’s public key.
- The client sends the encrypted number to the server.
- The server decrypts the number using its private key and sends it back to the client.
- The client encrypts the number using the server’s public key and sends it back to the server.
- The server decrypts the number using its private key and sends it back to the client.
- This process is repeated a few times to ensure that both the client and server are who they say they are.
- Once the keys are exchanged, the client and server can communicate securely. The data is encrypted using the agreed key and sent over the network. The data is decrypted on the other end using the same key. This ensures that the data is secure and cannot be read by anyone who is listening on the network. All a listener will see is encrypted data.
Example of SSH handshake
Once we have the key generated for the session by both the client and the sever, we can go ahead with the actual login step where we can use username/password or certificates to authenticate the user. Do note that from here on everything will be encrypted. So your username and password will not be sent in plain text, unlike telnet/rsh/rlogin. An SSH MITM attacker only sees encrypted blobs of texts. And only the server, which also has the common key, can decrypt them.
Telnet connect
Server is running OpenSSH version 9.9 while the remote client is running SSH 9.7
For example, Github is running babeld ssh server, another implementation of the SSH protocol.
You can see the server version in client’s window. This is because the server sends its version to the client in plain text. This may become a security risk as you continue the conversation and an attacker can use this information to exploit the server. This is why it is important to use SSH instead of telnet. Just FYI, you will still see versions in plain text, until a secure channel is established. After that everything is encrypted.
Stage 2 : Login to remote OS
Once the keys are generated for the session by both the client and the server, we can go ahead with the actual login step where we can use username/password or certificates to authenticate the user. Do note that this key is different from public/private keys used for authentication.
This implies that until a common key is generated on both ends, the client-server communication is done in plain-text which is not secure. We can see this in a network analyser intercepting data on port 22.
At this point our connection is encrypted.
SSH Login
Once a secure channel is established, the client has multiple ways to login into the remote system.
Username and password is the basic auth that any OS supports.
Keys generated during the secure channel setup is used to encrypt all the next set of packets, thus a secure connection.
The encrypted username/password is sent to the server, the server decrypts it and checks with the OS if the username/password is correct. If it is, the server sends a success message and the client is logged in. A secure shell is provided to the logged in user.
If username/password combination is incorrect, the OpenSSH server sends a failure message and the client is disconnected.
The actual auth is being done by asking the OS. The server is just a middleman to pass the request to the OS and get the response back.
Certificates where the public key is sent to the server and the server checks if the client has the private key. If it does, the server sends a success message and the client is logged in with a secure shell spawned. The client can then execute commands on the remote machine.
Note : Public/Private asymmetrical key pairs that can be created are only used for authentication, after a secure channel is established, not for the encryption of the SSH connection itself. The symmetric key generated in setting up the secure SSH connection before the actual auth to the remote OS begins is used for encrypting the whole connection itself, so that nobody can eavesdrop on the channel to grab asymmetric keys or usernames/passwords or data once the user logs in. Even if there is somebody is listening on the connection, grabbing all the packets into a database, those packets can never be decrypted. Also note that the secure channel setup key is rotated either periodically or after a certain amount of data has passed through the channel. So even if a DHE key leaks, only a fixed number of packets can be decrypted. The attacker would need all the DHE keys generated during a session to do any meaningful damage. Leaking of an in-memory DHE key would be a much bigger issue.