Standard Unix/Linux commands such as: rlogin, rsh, rcp or Client Telnet which are also available in systems running Microsoft Windows provide remote access or file copying (rcp). At the time protocols and tools themselves were being developed and the biggest dreamers could not have imagined that the Internet would grow as large as it is today. The struggle that exists today to protect every open port, or activated service, or developed application from persons who take pleasure in breaking into computer systems and destroyed other people’s work, had not even been thought of. As a result, sessions of the said tools were easy to hack, because the data was transmitted over totally unprotected networks. Often the only authentication method was password authentication and the intruder could capture a password in transit by connecting via rsh and executing, for example, the command rm -rf /home acting as a root-enabled user. Telnet was considered a fairly secure protocol to work with remote terminals (in the Unix world, “terminal” means whatever computer you are sitting at), issuing commands at the prompt as if the machine were local. It is no wonder that a replacement for telnet was developed to secure logins and remote command execution. It is easy to guess that SSH, Secure Shell, is the utility to replace telnet. SSH provides an encrypted terminal session strongly secured with symmetric encryption algorithms. Encryption is supported by public-key cryptography mechanisms to protect the session key used by a symmetric encryption algorithm. Other SSH features and capabilities include:


  • a variety of user authentication methods,

  • tunnelling arbitrary TCP connections through the secure SSH session;

  • X Windows session tunnelling,

  • support for external authentication methods, including Kerberos, SecurID, Smart Card

  • secure file transfers using SCP mechanisms.

These capabilities permit the user to protect against attacks such as:


  • IP spoofing,

  • IP source routing,

  • DNS spoofing,

  • interception of clear text passwords,

  • Listening in on X-Windows authentication data and spoofed connections.

There are currently two versions of SSH available, SSH Secure Shell Version 1 and Secure Shell Version 2. SSH1 not as secure as SSH2 and is being slowly withdrawn from use.



What does SSH1 protect?


One of the key concepts for SSH1 is that each host in the network, or at least each host that accepts SSH logins, has a unique RSA cryptographic key, for identification purposes. The length of the host key is by default 1024 bits. Additionally, whenever the SSH1 server is activated, the second RSA key is automatically generated. This is called own server RSA key, and by default is 768-bit long. In order to enhance security, this key is regenerated after a specific timeout (1hour by default), if in the meantime the server had used the key. This key is never saved in any server file. Whenever a client connects to the server, in response, the server sends a set of both public and host keys. The client compares the host public key with a master key. This procedure is to verify if the connected host is the same as the host in the first query. Due to this fact, the host RSA key is considered immutable. It is worth noticing that the server key cannot be used to authenticate the host, as this key is frequently modified. After host authentication is successively performed, a 256-bit session key is randomly generated by the client and encrypted with the server key and the server host key together. This type of prepared information is then sent to the server which has a set of private keys and can un-encrypt the value sent by the client. This cipher is now used as a key for symmetric, cryptographic algorithms to encrypt the session. For this purpose, Blowfish or 3DES encryption algorithms are used, and 3DES is normally used by default. The client selects the encryption algorithm to use from those offered by the server. After the negotiation phase has been successfully completed between server and client, the rest of the traffic in the SSH1 session is encrypted with the existing algorithm using the session key. Afterwards the user can be securely authenticated on the server. The password is never sent as clear text on the network and because SSH is not limited to password authentication, more sophisticated methods can be employed, for example public-key cryptographic algorithms. SSH also supports less secure methods such as Rhost authentication. The authentication procedure itself during an SSH1 session is as follows:

  • if the machine the user logs in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote machine, and the user names are the same on both sides, the user is immediately permitted to log in.

  • if .rhosts or .shosts exists in the user’s home directory on the remote machine and contains a line containing the name of the client machine and the name of the user on that machine, the user is also permitted to log in.

Since these two authentication methods are not secure, they are usually not accepted by properly configured servers. Other authentication methods are Rhost methods combined with RSA-based host authentication. Using this method, an option exists for the server to tighten the access security by additionally verifying the client’s host key. SSH host keys are placed in /etc/ssh/ssh_known_hosts or $HOME/.ssh/known_hosts of specified users. Such modified   standard Rhost authentication is a partial remedy to security weaknesses due to IP spoofing, DNS spoofing and routing spoofing. However, Rhost authentication is not very secure so its use requires careful attention and generally the best advice is to not to use it.


As a third authentication method, SSH uses a scheme based on pubkey cryptography system where an integrated pair of keys is used – one public key and one private key. RSA is one example. The concept is that the user’s successful authentication requires that the server knows the user’s public key and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the client logs in, it tells the server which key it would like to use for authentication. The server checks if this key is permitted, and if so, sends the ssh client a random number, called a challenge, encrypted by the user’s public key. This challenge can only be encrypted using the key owner’s private key i.e. only by the party holding the pair of keys. The user’s client then decrypts the challenge using the private key, and if the challenge is the same as on the prior server’s response, this is the proof that the user knows the private key corresponding to the public key. In this way, one may ensure that the private key is never disclosed to the server. The user creates his/her RSA key pair by running ssh-keygen. This stores the private key in $HOME/.ssh/identity, and the public key in $HOME/.ssh/ In order to use RSA authentication, the user should copy the public key to $HOME/.ssh/authorized_keys in his/her home directory on the remote server. RSA authentication is much more secure than the previously described Rhosts authentication.


In addition to the discussion on RSA authentication, the authentication agent may be a reasonable solution where the user has to login to multiple servers. (This issue, however, is supported by SSH2 and will be discussed subsequently).


If the above mentioned methods fail, then the user is prompted for a password; since all communications are encrypted, the password cannot be intercepted and read.


SSH1 was passed through standardization routines where other weaknesses of this protocol were revealed such as permission to listen to the session in transit. As a result of these changes a new SSH2 protocol has been developed that is gradually replacing SSH1. In fact recent servers are not always guaranteed to support SSH1, whereas others have it disabled by default.
Client programs may also support SSH2 protocol.



SSH1 and SSH2 are different versions of the same program. Each host has its own unique RSA or DSA authentication key, not just an RSA key as SSH1 has. The first difference found is during the SSH server start-up  – there is no server key. The session key produced by Diffie-Hellman is used to encrypt the real session key. Once the session key has been established, the traffic is encrypted using one of the following symmetric algorithms:

  • 128 bit AES

  • Blowfish

  • 3DES

  • CAST128

  • Arcfour

  • 192 bit AES

  • 256 bit AES

Additionally, session integrity is provided through sha1 or md5 hash algorithms. This list of algorithms obviously has a certain preference and nothing stands in the way of using other symmetric algorithms, provided that both the server and the client support them.

Both SSH1 and SSH2 use some authentication methods. By default, the client attempts to authenticate itself using the set of following methods:


  • Rhosts authentication

  • pubkey authentication

  • keyboard-interactive authentication

  • password authentication


Public key authentication is similar to SSH1 authentication except that the RSA or DSA algorithm is used instead and the keys are listed in $HOME/.ssh/id_dsa and $HOME/.ssh/ for DSA and  $HOME/.ssh/id_rsa$HOME/.ssh/ for RSA respectively. In contrast to SSH1, when a client wishes to authenticate his use of public/private keypairs, he signs in with the client’s private key where the session identifier derived from a shared Diffie-Hellman value and then the server check, whether the matching public key is listed in the authorized_keys. If public key authentication fails, then another authentication method is attempted to prove the user’s identity. The order of authentication methods is established with PreferredAuthentications in the configuration file. By default, the configured order is as follows: host-based, public-key, keyboard-interactive, password.


Note, that SSH2 allows other authentication methods to be used, for example Kerberos, X.509 certificates, electronic credit cards and other means.


Both SSH1 and SSH2 support the mechanisms of authentication agent. With ssh-agent program (standard) the user can add identities to the authentication agent. One example can be the Agent, which initially does not have any private keys. Keys are added using ssh-add, that in a typical case results in adding the files $HOME/.ssh/id_rsa, $HOME/.ssh/id_dsa and $HOME/.ssh/identity. If these files are encrypted with a passphrase, ssh-add asks the user for the passphrase. Multiple identities (keys) can be stored in a single agent. The ssh-add -l displays the identities currently held by the agent.


The idea is that the agent is run on the user’s laptop, local PC or terminal. Therefore, authentication data need not be stored on any other machine, and authentication passphrases will never be passed over the network. However, the connection to the agent is forwarded over SSH, and the user can thus use the privilege given by the identities anywhere in the network securely. The agent will never send private keys, instead all operations that require a private key will be performed locally by the agent, and the result will be returned to the requester. As a result, private keys are additionally protected from unintended loss of data.


Remote execution


When the user’s identity has been accepted by the server and he has gained access to it, the server either executes the command given by the user, (this command is similar in function to rexec), or gives the user a normal shell on the remote machine. Obviously, all communication between the client and server will be encrypted.


X11 and TCP forwarding

If the configuration option ForwardX11 is active and the user is using X11 (the DISPLAY environment variable is set) all X11 traffic is automatically forwarded over a secure SSH channel and the connection to the real X server is made from the local machine.

On Windows servers, forwarding of arbitrary TCP/IP connections over the secure channel is used rather than X11 forwarding.



Server Authentication

SSH clients automatically maintain and check a database containing identification for all hosts that have ever been involved in the interaction. The database for each user is stored in $HOME/.ssh/known_hosts, and additionally, at the server level in /etc/ssh/ssh_known_hosts. Any new hosts are automatically added to the database. If a host’s identification ever changes, the client warns the user about this to prohibit from sending the user’s password to an unauthorized server and also to prevent a Trojan horse attack. Another purpose of this mechanism is to prevent man-in-the-middle attacks. The StrictHostKeyChecking option can be used to enhance security. While active, it will prevent logins to the server if their identification has changed. This option can be established and enforced on the users by the system administrator.





With SSH it is possible to create a secure communication channel between the server and the client. This channel can be used for different purposes, not necessarily for launching a remote terminal session but for sending any data using the forwarding feature. SSH supports a variety of authentication methods, and new options may be added if required.  Data in transit can be protected with multiple symmetric algorithms that use the key negotiated at the beginning of an SSH session. Both the client and the server can authenticate each other to enhance security against different kinds of attacks.




Fig. 1   SSH communication


Fig. 2  IP spoofing


Prawdziwy klucz = The authenticated key

Prawdziwy serwer SSH = The authenticated SSH server

Serwer podszywajcy sie…. = A fake server acting as the real server.  The supplied key does not match the autenticity

Faszywy serwer SSH = The spoofed SSH server

Poczenie z  klienta… = Connecting the client and verifying the key


Fig. 3 TCP forwarding


Serwer WWW = WWW server

Serwer SSH = SSH server

Klient SSH = SSH client

Przyjecie poczenia = Accepting the connection at the port # 2300 followed by forwarding to the WWW server at the port # 80

Poczenie z serwerem,,,, = The connection between the SSH server and the port # 2300

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top