The SSH protocol is used to provide an encrypted tunnel between the SSH client and a SSH server. It also provides a level of confidence that the client is communicating with a known host through the use of host keys, which can be configured to only allow a connection to a host whose public finger print is pre-registered with the SSH client. Many enterprises use SSH with either user/password authentication or Public Key Exchange (PKE).
Public Key Exchange (PKE).
Enterprises use PKE as it replaces the need for a user to enter a password. This is ideal for where every user of an application connects to the host using a generic user and then is presented with an application logon where the users logs on with their user ID/password. Also system administrators will often have the need to logon to multiple UNIX/Linux servers which means managing passwords across servers can be a big issue.
If we take a look at how PKE works (see figure 1 below) we can see that the user (owner) has the private key within their profile directory. When they connect to an SSH enabled host the server checks to see if the user holds the private key matching the public key held on the server in the user’s home/profile directory – if they do then the user is logged on without the need of a password.
The problem is the user may connect to many servers, especially if they are a system administrator as illustrated in figure 2. As we can see, each server that they connect to has to have the user’s public key in the user’s home/profile directory. This is not too difficult to manage across a couple of servers – but beyond that it becomes a problem; especially if there are a number of users as this has to be done for each user.
The reason that the security team don’t like this is if the user’s key is compromised then there is no way to revoke the key – it has to be manually deleted from each server and a new key created – which leaves a compromised key valid until changes are made. The keys used never expire so are never refreshed on a regular basis but some enterprises wish to renew the keys every 30 days.
Also If a user changes role in the enterprise it is very common for the UNIX/Linux users to still have access to systems which they no longer need in their new role. So what’s the answer?
X.509 Certificates
Using certificates provides a solution which the security team like; as the keys used can be expired; can be immediately revoked if the key is compromised and can be revoked if the user changes role or leaves the organisation.
However – SSH as standard doesn’t support the use of X.509 certificates for user authentication. Where the SSH server does support X.509 certificate user authentication then they generally operate as in figure 3.
Figure 3 shows that the user certificate is validated by the SSH server which has to have the X.509 certificate chain installed in-order to be able to validate the client X.509 certificate. This means that if a user logs on to 10 servers each server has to be managed to allow the user to be authenticated using their X.509 certificate. If Certificate Revocation Lists (CRL) are used then each server must have the updated CRL list available.
It is because of the problems associated with the managing of the Public Key Infrastructure (PKI) shown above that many of the benefits of using X.509 certificate authentication are never realised. So how can we centralise the management of the X.509 certificates?
Micro Focus PKI Services Add-On.
Micro Focus have a solution which is a freely available add-on to the Reflection for Secure IT server (RSIT) – the add-on is called the PKI Services Manager add-on.
Figure 4 shows that the complexity of managing the X.509 user certificate is carried out by a single server (or servers for failover/load balancing). The PKI manager provides the all-important certificate validation and user mapping. It also validates the X.509 certificate against the Certificate Revocation List using a file or the Online Certificate Status Protocol (OCSP).
This means that for the enterprise the use of passwords can be removed and replaced with X.509 certificates which can be stored on the local machine or on a smart-card.
The keys used can be expired and revoked immediately should the user’s certificate or any of the intermediate certificates be compromised. New keys can be issued to users in-advance of the old keys expiring. The whole X.509 key validation can be centrally managed, so whether you have 10s of servers or 1000s of servers the managing of the keys can be simplified and centralised.
The PKE key authentication that Security doesn’t like can be replaced with a standard they respect.
This article was first published in Open Horizons Magazine, Issue 39. 2017/4, p32-33.
....To view the full article you must have a full Digital Subscription.