SSH Overview | The Bigger Picture

Suppose I access any website from my computer. The ongoing connection itself, through which my computer communicates with the remote web-server, is managed on layer 5, the session layer, through the HTTP protocol.

SSH and Telnet also operate on layer 5. While the session itself is maintained by layer 5, it doesn’t actually do anything. You can think of it as a phone call where no one is saying anything. Getting the JPEG file to my computer, therefore, will require a data transfer riding on top of the session on the transport layer, using, in this particular case, the TCP protocol.

Types of SSH Session:

  1. RSA rhost authentication – /etc/hosts.equiv | /etc/ssh/shosts.equiv | /home/username/.rhosts | /home/username/.shosts
  2. Private/public key-pair authentication
  3. Password authentication


  1. RSA rhost authentication:
    1. RSA rhost authentication works if the remote host contains a file named either hosts.equiv or shosts.equiv in, respectively, the etc or etc/ssh/ directories, or .rhosts, or .shosts in a user’s home directory. Should any of those files contain an entry identifying the client machine and its current user, and should the host server already have a compatible entry for the client’s host key, then login will be permitted.
  2. Private/public key-pair authentication:
    1. If none of the above files exist (For RSA rhost authentication), and largely because of structural weaknesses within the rhost system itself, that will usually be the case by default, then the SSH program running on the client will identify to the server which local, encrypted key pair it wants to use. But before that can happen, of course, you’ll need a key pair to work with. If you don’t already have one, you can generate a key pair in the ~/.ssh directory within your user’s home directory on a Linux client using the ssh-keygen program.
    2. The location of the SSH keys generated by the ssh-keygen command are following:
      1. SSH User Keys Location – /home/username/.ssh/
      2. SSH System Keys Location – /etc/ssh/
      3. SSH Configuration Files:
        1. File to control client behavior – /etc/ssh/ssh_config
        2. File to control server behavior – /etc/ssh/sshd_config
  3. Password authentication:
    1. This is the same as Windows authentication. You have to put in the password created at the time of user creation which is stored on the server, and is matched when you try to login.

How SSH authentication takes place

For the remote server to authenticate you, these are the steps which need to happen:

  • You create an SSH keypair (Private Key + Public Key) on your local machine.
  • You just copy/append the contents public key from your local machine to the .ssh/authorized_keys file of the remote server.
  • Now, when you will try to SSH to the remote server from your local machine, you will specify in the command that you are trying to authenticate with the private key file that you already have created in the first step and the authentication will be successful since you have imported the corresponding public key to the remote server’s authorized_keys file.
  • First, lets create keypair: ssh-keygen -t rsa and then select all default options by just pressing Enter key.
  • In the output of the above command, you will see that the private and public key files will be generated e.g.: Your identification has been saved in /home/ec2-user/.ssh/id_rsa Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub
  • Now, just copy/append the id_rsa.pub’s CONTENT file from the directory mentioned in your case to the ~/.ssh/authorized_keys.
  • To confirm that the SSH trust has been established, just try to SSH from your local machine to the remote server by using this command – ssh -i /location/of/private/key username@remote_server_ip

The gist of the above is, after you have copied the content of your public key to the ~/.ssh/authorized_keys file in the server, and your client machine sends its request to open a new session, the server’s SSH program will send a random number that’s been encrypted using the client’s public key. If the client can decrypt the number using its own private key, then the server will allow you to launch into a session.


SSH Key Pass-Phrase Significance:

  • Now, about that local passphrase. How can we be expected to remember yet one more password?
  • You can simplify the process by invoking SSH without losing the extra security a passphrase provides by having a key agent handle your passphrases for you on your machine.
  • You first launch ssh-agent, which will return a new process id confirming that the program is running, and then run ssh-add against the key pair you’d like to serve.
  • Now, whenever you use ssh to open a shell session on a remote computer, the local passphrase will be handled invisibly by ssh-agent.

Leave a Reply

Your email address will not be published. Required fields are marked *

twenty + fifteen =