SSH

This web page is a brief look at SSH - having looked at SSL, I thought it would be interesting to have a look at SSH as well.

Some of the bits and bobs of SSH are similar to SSL, so it might be useful for you to read the SSL page first.

Introduction to SSH

SSH is a mechanism for providing a secure connection in order to allow secure interaction with a server - it replaces old insecure protocols like telnet, rlogin, and ftp, in which both passwords and data are passed in clear text form, so can be captured by attackers using packet sniffers.

SSH is short for Secure Shell.

SSL and SSH

As described in the SSL webpage, SSL is a mechanism for setting up a secure communication medium between a client and a server. It is normally the browser that would instigate, or request, an SSL connection.

SSH is also a mechanism for setting up a secure connection communication medium between a client and a server. However there are significant differences between SSL and SSH.

In SSL

as far as the SSL connection is concerned, the server doesn`t care who the user or client is
it is the connection that is being protected
an SSL connection between a client and a server can be set up without any form of authentication onto the server
if the services offered by the server require user authentication, this is done after the SSL connection has been established

However in SSH,

the server cares a lot about who the user/client is
it is the server that is being protected, as well as the connection itself
user/client authentication is an essential part of setting up the SSH connection

Like SSL, SSH is connection orientated - once the connection has been set up, it stays up for as long as both the client and the server require it. Once either party has finished, the connection is closed down.

Versions of SSH

There are two versions of SSH, SSH-1 and SSH-2.

SSH-1 was the original version of SSH, and was subsequently found to have security weaknesses, so was superseded by SSH-2

SSH-1 and SSH-2 are not compatible, however for historical reasons, much of the SSH software can operate in either SSH-1 or SSH-2. However SSH-2 is the preferred version, which should always be used if possible.

SSH protocol stack

SSH is actually built up from more than one protocol - there are actually three of them, and that doesn`t include the extra add-on protocols such as sftp and scp. The SSH protocols are

SSH connection protocol
SSH authentication protocol
SSH transport protocol

Now here there is a bit of an information uncertainty - some websites say that the protocol stack looks like -


          SSH connection protocol

        SSH authentication protocol

          SSH transport protocol

                  tcp

                  ip

            data link layer

            physical layer

and some websites say that SSH connection protocol sits alongside the SSH authentication protocol, on top of the SSH transport layer protocol - like this -


          SSH connection protocol / SSH authentication protocol

                      SSH transport protocol

                              tcp

                              ip

                        data link layer

                        physical layer

At the time of writing, I don`t have a definitive answer as to which is correct. Maybe it is a sort of mixture of the two.

SSH transport protocol

The SSH transport protocol usually sits above TCP/IP, but it can also sit above other types of data transfer systems. When it is sitting above TCP/IP, it usually uses TCP port 22. SSH very definitely needs the transmission error protection built into TCP/IP - if SSH is to be run over some other protocol, that protocol must provide error protection as good as that provided by TCP/IP.

The transport protocol is responsible for -

key exchanges
checking it is the correct server
encryption
data integrity
possible compression, if it is required
providing a unique session ID, for use by higher layers

The starting point for negotiation between the client and the server is the exchange of public and secret keys, in a similar way to SSL. Part of the responsibility of the SSH transport layer is to renegotiate the shared secret key after some time period, or after a certain amount of data has been exchanged. This helps to reduce the risk of an evesdropper trying to capture the shared secret key.

Checking for the correct server is again in a similar way to SSL, and relies on the public key infrastructure and certificates held within the client. The same risk as in SSL exists, in that it may be possible for an attacker to "arrange" for the client to know about, and therefore accept, a false certificate.

SSH allows for quite a few different types of encryption - different types of encryption can be used for the two directions of data flow, however it is recommended that the same type is used for both directions. The minimum allowed is 128 bit encryption. IANA has some documentation on SSH on the internet, and it lists no less than 34 different types of encryption.

The maximum packet length is 32,768 bytes.

Data integrity is ensured by the use of a MAC with each packet - a MAC is a value computed from the combination of a shared secret key, a packet sequence number, and the contents of the packet. The algorithm used to calculate the MAC is agreed during the key exchange. MAC`s are not encrypted.

Once the keys have been exchanged, and a secure connection has been set up, the client can request that the server provides a service - typically this will be SSH-authentication, or SSH-connection.

The SSH transport protocol is somewhat similar to TLS.

SSH authentication protocol

This layer is sometimes referred to as SSH user authentication protocol, but in fact user authentication isn`t always what is used - in some circumstances client authentication can be used instead - or as well.

The IETF specification for SSH authentication specifies three different mechanisms for authentication -

user authentication using a user name known to the server, and a password - the SSH authentication protocol doesn`t have to worry about sending passwords in clear text, as the SSH transport layer encrypts everything anyway- however the password text string must be encoded in UTF-8
user authentication using keys - the user has its own private + public key which the server knows about, and accepts as legitimate, and therefore accepts the connection - used by itself, it is maybe a bit iffy as far as security is concerned, but it could be used along with password authentication to add an extra security layer
host authentication using keys - the host has its own private + public key pair - the client sends a signature created from the private key, which the server can check with the host`s public key - once that is done, user authentication is allowed based on the user name, but no password is required - again, it is maybe a bit iffy as far as security is concerned, but could be combined with password authentication
the security of this kind of authentication can be increased by having the server check the ip address of the remote host - you could presumably also have network firewall rules in place which would also limit ip addresses, however since the remote host is initiating the connection with the server, there would have to be a tunnel through a stateful packet filter firewall

OpenSSH, which is a very widely used open-source implementation of SSH, adds a fourth mechanism for authentication - GSSAPI.

GSSAPI - General Security Services Application Programme Interface - allows the client server pair to use other technologies for authentication, such as Kerberos.

Whether GSSAPI is regarded as part of the SSH authentication protocol, or whether it is a replacement for it, I haven`t seen any reference to.

The IETF standard I found didn`t mention GSSAPI, however it is mentioned in amongst the IANA documentation.

It is normal to have the server configured so that the server offers the client a variety of ways to achieve authentication, and the client can choose which method to use. However which method or methods the server offers is obviously dependent on the security policy of the organisation.

It is a requirement that the server has a time-out for authentication - if the client has not authenticated within this time-out period, the server will withdraw the offers.

SSH connection protocol

The SSH connection protocol sits above (?) the previously set up secure, encrypted, and authenticated lower layers, and provides a number of channels - one for each required connection between the client and the server. The channels are multiplexed by the SSH connection protocol, so multiple connections can co-exist over the top of a single SSH transport / SSH authentication lower layer stack. The multiple connections can be of similar or different type - for example, remote command line shells, remote X11 sessions, and forwarded TCP/IP connections.

The IANA documentation on SSH refers to these four channel types -

session
x11
forwarded-tcp/ip
direct-tcp/ip

Either the client or the server can request the setting up of a new channel - each channel is identified by a number - however the client and the server may refer to it with a different number ( which seems a little confusing ! ).

A request to set up a new channel is done through "channel requests", which provide information on how much data is expected to be transferred.

Only one application or service specific connection can be carried on each channel.

Channels can be set up and closed down independently of other channels, and independently of the lower SSH transport and SSH authentication protocols.

The existence of the SSH connection protocol as part of the whole SSH package makes SSH more powerful than TLS, as TLS does not have the capability of carrying multiple channels over a single transport layer.

The end

That`s about as far as I can go with SSH without a substantial expansion of all the various components. There is quite a lot of meat to it, and whole books are written about it - so the whole of SSH wouldn`t fit on one web page anyway. However I hope the above is a useful introduction.

website design by ron-t

website hosting by freevirtualservers.com

+ +