Discuss the security issues associated with SSH

Introduction
SSH was originally a program written by Tatu Ylonen, a student at the Helsinki University of Technology to replace the traditional insecure remote access programs such as rlogin, rcp, and telnet (SSH Communications Security, n.d.) It has evolved into a protocol that is used for remote access. The Internet Engineering Task Force (IETF) has standardised the SSH protocol version 2. It encrypts passwords and other data that travels over the network to make them secure. SSH provides a more secure option for remote access as compared to Telnet, RSH, Rlogin and FTP. SSH 2.0 is the current version of the protocol that is widely used. SSH uses RSA-based authentication. The RSA security algorithm uses two keys, one public key and one private key. It is not possible to derive one key from the other. Each server has a public and private key paid for his or her own use. The users who want to connect to the server are given the public key and they use the public key to encrypt the messages they send to server. The RSA algorithm is designed such that messages that are encrypted using the public key can only be decrypted by the private key (and not even the public key itself) This means that only the server, which has the private key, can decrypt the messages sent by the connecting user. SSH thus encrypts all the traffic that passes through an unsecured network. However, SSH has the capability to forward ports and this has greatly expanded its use (Cole, 2005). For example, FTP is also implemented over SSH to derive the more secure SFTP, which offers all the security benefits of SSH together with the capabilities of FTP.
Dwivedi (2003) points out that the architecture of the SSH protocol offers four types of security features:

1. Authentication – SSH provides users with the option of using either public or private keys, in addition to the username and password combination as is used by ftp, Telnet, etc. This provides an additional layer for security in the process of verification of users.
2. Encryption – Communications between two computers connected via SSH is encrypted. This means that unlike FTP for example, the username and password, and other information do not pass through the network in plain text. This means that SSH again provides another layer of security. SSH provides encryption in a variety of standards, such as triple-DES, Blowfish, Two-fish, etc.
3. Packet-Level Integrity – SSH also offers packet-level security by using MD5 and SHA1 hashing of each session. This means that packet sniffing will not give the cracker direct access to information.
4. Authorization – SSH also incorporates IP or DNS filtering. This means that SSH can permit or restrict connections based on an IP address or hostname.

SSH in network management
SSH is a very attractive solution for network management, and is more so in large companies where there typically is a significantly larger number of servers compared to the number of administrators. Remote access for administration in this case is crucial to the normal operation of the servers.
SSH is typically used to replace other remote services such as Telnet and FTP. Often, it is also used as an alternative to the more commonly used simple username password combinations, where the more secure public key infrastructure can be used for login. SSH offers an attractive proposition because there are many free of cost implementations that are available, such as Open SSH. Choosing SSH in these circumstances is most likely results in reduced overall costs. SSH is particularly attractive because it can be used to tunnel other programs over it to make them secure. Secure implementations of such programs are scp (secure copy, the secure version of remote copy), sftp (secure ftp, the secure version of ftp, remote file transfer program), etc.
Security issues with SSH
While there is wide consensus that SSH is the safer option compared to other remote access programs such as FTP and Telnet, it is also exactly that – the safer option, and not the failsafe option. This means that SSH also has its own vulnerabilities and can be compromised. Using SSH thus does not mean security is taken care of. Cheswick et al (2003) list the following as some of the security issues with SSH:

1. The SSH protocol isn’t failsafe – The SSH protocol itself has had to be changed twice because of security problems (CERT Vulnerability Note Vuhash596827) and the IETF Standards Group is working on standardising version 2.0. The server runs as root, and this is very dangerous from a security point of view.
2. The server cannot specify different authentication measures for different clients, i.e. all clients must have the same level of authentication. This means that if the ssh server chooses one method of authentication then all the clients who want to connect to it must provide that method of authentication.
3. System administrators use ssh as the single wall of security – there is no backup security measure. This means that if suddenly a major security hole is found in SSH, then it has to be repaired immediately. This means that the system administrators have to always be on hand and prepared to run when the problem is spotted.
4. The user can use a password to lock the RSA or DSA key file. This means that if a cracker gains access to the server, that file can be subjected to dictionary attacks.
5. Other protocols can be tunnelled over ssh.

Besides these generic problems with SSH, every version of SSH, proprietary or open, is also susceptible to different types of vulnerabilities. For example, vulnerabilities were found in OpenSSH’s Challenge Response Handling (CERT, 2002) and buffer management (CERT, 2003).
Scambray et al (2005) further point out that SSH has had some serious vulnerability that allows root compromise. They state that one of the most damaging vulnerabilities associated with SSH is the flaw in the SSH1 CRC-32 compensation attack detector code which was added to address a serious crypto-related vulnerability with the SSH1 protocol; This new piece of code introduced a new flaw in the attack detection code that could lead to the execution of arbitrary code in SSH servers and clients that incorporated the patch.
Subversion
When the cracker tries to hack into a network, they use very many different methods in their attempts. One such method is called subversion. Here the cracker uses his prior knowledge of the intrusion detection system to cause many false negatives to occur. It is important to recognise that even false negatives convey some information to the cracker – information about what is not the username/password. Using this information the cracker may successfully guess the username/password and gain access to the system through SSH. Once the cracker has gained access to the system, it does not matter how secure the communication with the outside world is – the system has been compromised. Here the intrusion detection system has failed to detect the attack, as the intrusion detection system is itself learning the behaviour of the network – it just ‘learnt’ that the network faces a lot of negative attempts, instead of detecting it to be abnormal. If a human network administrator had examined the log files, then it was highly possible that the attempt would have been detected. However, such an attack can also be spread over a very long time, long enough to fool even human network administrators. The main contention here is that SSH does not provide any protection against brute force attacks, and subversion over the network (Brockmeier, 2000, GIAC, 2007).
Hardening and protecting SSH
As described in the paragraphs above, while SSH is a very secure protocol, it does have some vulnerabilities which are unavoidable. There are however, many ways for a system or network administrator to make changes to the configuration of SSH in order to make it more secure. Changing the default configurations is desirable because attempting intrusion by making use of the default configurations is one of the first start points for a cracker. One of the most important and easiest ways to harden SSH is simply to keep SSH updated – this means that patches for new vulnerabilities that have been found would be installed, thus foiling attacks based on those vulnerabilities, and reducing the ways in which the network or system could be attacked.
There are also various other widely accepted, logically determined methods for hardening SSH. Disallowing root access is one way to make it more difficult for crackers to gain root access. Another less commonly used tactic is to use a port other than the default port 22. This is just a tactic to fool the less determined cracker – most crackers do port scanning to determine which services are up and running. If a host will only accept ssh connections from known clients with some transaction beforehand, the host can specify a different port for ssh service, and the client can be configured to access via this different port. Then when a potential cracker scans the port 22, he will find that SSH does not operate in that port. At this point, it is highly possible that the less determined cracker will assume that server does not run SSH and either give up, or choose some other method to resume their attempts. Either way, these results in a higher notch security – at the very least extra effort is required from the crackers. If the SSH server has strict information about the clients that allowed to access the services, the server can also specify specific client host information in the /etc/hosts.allow and hosts.deny file in most implementations of SSH on Unix flavours. This will also only the hosts listed in the hosts.allow file to connect to the ssh server and disallow all connections from clients who are from hosts in the hosts.deny file. This gives the network/system administrator a great degree of control over the ssh server and service. Restricting the version of the protocol is also another widely recommended measure. This is because there is important security issues with SSH protocol version 1, and the newer SSH protocol version2, commonly termed SSHv2, was created and addressed these problems. This means that the SSH version 1 still has the security issues that have not been fixed. Restricting the protocol version is also recommended because most SSH clients today support SSH version 2, and the restriction would therefore not have much effect to the ability of clients to connect to the server. (Perry, 2005)
Baal (2006) also recommends other measures to harden SSH. Some of these are to allow ssh access only from specific IP addresses to specific local user accounts. This creates unique links between the IP addresses and user accounts. For example, if the system administrator knows that a certain user only accesses ssh from two specific locations, he can then map the IP addresses from that locations to that user accounts – any cracker from any other location then cannot gain access to the system using that user account even if he or she has obtained the password for the user account. Baal (2006) also recommends disallowing password authentication to force people to use key-pairs. Crackers often use the information provided in the banner messages to determine the SSH version and service type that is running. They can then use this information to determine which vulnerabilities will be present, and gain access to the system. It may therefore be desirable to forge the banners, i.e. systems administrators can configure the system to display wrong information about the version and type of SSH service running. This will help fool the crackers.
While the specific methods for hardening and protecting SSH is described above, the more generic methods of making the network also serve to enhance the security of SSH. One of the most important ways of protecting the system is to use strong passwords – this makes it very difficult for brute force and dictionary attacks to succeed. However, this is also one of the most overlooked methods of hardening the network. The use of strong passwords will also help protect SSH against brute force attacks and subversion. System administrators can create rules to force users to use strong passwords, and this will also help against brute force and dictionary attacks on SSH.
Conclusion
It is important to remember that no system is completely secure, 100% safe against intruders, as long as it is connected to a network. A computer that is switched off and stored in a bomb-proof cement box is perhaps the most secure a computer can be – but even then there isn’t a 100% guarantee that no one can access the system – someone can always chip the cement box slowly and ultimately gain access to the computer.
Even if networks are totally secured such that it is very difficult to break into the network, other methods such as social engineering can be used. In this background, SSH is just one security measure that will provide a relatively higher level of security. The power provided by SSH through its tunnelling capability combined with the strong security, encryption and even compression has made SSH become one of the most popular services for providing secure remote access. SSH has in fact become the tool of choice for system administrators all over the world. It provides all of the functionalities from existing tools, but also provides it in a more secure way. This has resulted in SSH replacing the more entrenched Telnet service (Rosasco and Larochelle, 2003), and its success in enterprise.