# Secure Shell

## Summary


In computer networking, there's a need to log into a remote computer. Historically, this was done using *telnet* (since late 1960s) and *rlogin* (since 1980s). However, these early programs were not secure. **Secure Shell (SSH)** is a protocol created to address these deficiencies. It basically establishes a secure connection over an insecure network. 

SSH adopts a client-server architecture. Client refers to the machine attempting to connect to a remote server. SSH authenticates both the client and the server. It specifies how client and server can agree on a shared secret for subsequent encryption of packets. Finally, it also provides data integrity protection. 

SSH has two versions: SSH-1 and SSH-2. SSH-2 was standardized by the IETF. 

SSH has wide adoption. Modern operating systems come with built-in SSH clients.  OpenSSH is a popular open source implementation. Commercial implementations are also available.

## Discussion

### What are the applications of SSH?

A common application of SSH is to **remote login**. In the early days of computer networking, trusted users within a corporate or university network had access to mainframes. For such trusted users, `telnet` was good enough. As networking expanded to WANs and the Internet, there was a need for a more secure protocol. This is what SSH provides. Once remotely logged into a computer, the user can execute programs via a terminal. 

**Port forwarding** or **SSH tunnelling** is another useful application of SSH. TCP/IP traffic is encrypted and tunnelled through an SSH connection. This is also useful to bypass firewalls. Telnet, SMTP, NNTP, IMAP and other insecure protocols can be tunnelled through SSH. X forwarding is a special case of port forwarding. 

SSH can be used to **transfer or copy files** via SFTP and SCP. SSH can automate server access and therefore enables process automation by cloud-based services. SSH keys can also offer Single Sign-On (SSO) so that users need not repeatedly type passwords. 


### What are main features of SSH?

SSH has the following main features or purposes: 

    + **Authentication**: Client can authenticate the server and vice versa. Algorithms include RSA and DSA (such as Ed25519 and Ed448).
    + **Key Exchange**: Client and server agree on what keys to use for encryption. Algorithms include Diffie-Hellman and RSA.
    + **Encryption**: SSH can encrypt it's payload, packet length, padding length and padding bytes. Algorithms include chacha-poly1305, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm, aes256-gcm, arcfour128 and arcfour256.
    + **Data Integrity**: By including a Message Authentication Code (MAC) field to each packet, the receiver can check that the packet hasn't been tampered with. MAC is calculated from a sequence number field (not transmitted) and unencrypted bytes. Algorithms include hmac-sha2-256 and hmac-sha2-512.
    + **Compression**: Payload going into an SSH packet can be optionally compressed. Algorithms include zlib.

### How does SSH differ from SSL?

Both SSH and SSL (Secure Sockets Layer) are about secure communications. However they differ in terms the sort of applications they enable. The main use of SSH is remote login and providing secure tunnels for insecure programs. System administrators or tech savvy users use SSH. SSL focuses on securing communications between a web browser and a web server. SSL powers websites and e-commerce.  

Like SSH, SSL does authentication, data integrity checks and encryption. While SSH has many ways to authenticate clients, SSL authentication uses certificates. Though SSL offers both server and client authentication, the latter is impractical and rarely used. 

For secure file transfer, SSH enables SFTP. SSL provides a similar service via File Transfer Protocol over SSL (FTPS). 


### Which are the components of SSH?

SSH-2 includes three distinct protocol components:  

    + **Transport Layer Protocol (SSH-TRANS)**: This is a low-level protocol by which client and server negotiate their support for SSH version and algorithms. Key exchange and server authentication are performed.
    + **Authentication Protocol (SSH-AUTH)**: This does client authentication. Client can attempt any authentication method supported by the server. The client may send "none" method to trigger the server to send a list of supported methods.
    + **Connection Protocol (SSH-CONN)**: From a single connection multiple logical channels are setup. For example, one channel might be an interactive user session while another might be an SSH tunnel for an insecure application.

### Could you describe the SSH protocol handshaking?

When a client contacts the server, a TCP connection is established. As the next step, client and server **negotiate** on two things based on their capabilities: (a) the version of SSH to use; (b) the algorithms to use. 

The **Key Exchange (kex)** procedure follows. This includes explicit or implicit **server authentication**. This outputs a shared secret K and an exchange hash H. Encryption and authentication keys are derived from these. H from the first key exchange serves as the session identifier. RFC 4253 recommends that keys be re-exchanged every hour or after 1 GB of data transfer. 

Next, the client makes a **service request**. The service request can be either SSH-AUTH, SSH-CONN or SSH-AUTH followed with SSH-CONN. With SSH-TRANS, a password could be used for **client authentication**. A more popular method is use pubic-private key pair, called key-based authentication. Another method is host-based authentication where server allows connections from specific hostnames. Once authenticated, client and server can establish a channel and exchange data. 


### How is SSH-2 different from SSH-1?

SSH-1 is a monolithic protocol whereas SSH-2 is designed as three separate components: SSH-TRANS, SSH-AUTH and SSH-CONN. With this modular approach, SSH-2 improves on many aspects: algorithm negotiation, multiple methods of key exchange, certificates for public keys, more flexible authentication, stronger integrity checks, and periodic renewal of session key. 

For client/server authentication, DSA works with only SSH-2 whereas RSA works with both versions of SSH. Mathematically, DSA is based on the discrete logarithm problem whereas RSA is base on the prime factorization problem. SSH-2 is extensible, that is, it can work with any public-key signature algorithm. For password-based authentication, SSH-2 allows users to change password. 

SSH-2 doesn't support DES and IDEA encryption algorithms, either due to their weakness or licensing restrictions. SSH-2 adds SFTP to the SSH suite. 

Unlike SSH-1, SSH-2 supports multiple interactive sessions. Many **channels** can be multiplexed over the same SSH connection. Thus, X or port forwarding can be done without opening separate terminal sessions for each. 

As per RFC 4253, servers that support both versions are required to identify the `protoversion` as **SSH-1.99**.  


### What tools are available for using SSH?

Two common tools that run on top of SSH are **SFTP** for secure file transfer and **SCP** for secure file copy. These are secure counterparts of earlier UNIX/Linux programs FTP and RCP. Popular implementations include OpenSSH, PuTTY and Tectia SSH. Built-in SSH clients are available on Windows, Linux and Mac. SFTP programs include WinSCP (Windows), gFTP (Linux) and Fetch (Mac). 

SSH requires key generation and management. The tool `ssh-keygen` generates public-private key pairs. Once generated, the client's public key needs to be copied to the server. This is aided by the `ssh-copy-id` tool. On the server, the clients' public keys are stored at `~/.ssh/authorized_keys`. 

When initiating an SSH connection, the user will be prompted for the passphrase. The tool `ssh-agent` stores the client's private key so that the user need not enter the passphrase for subsequent SSH connections. The tool `ssh-add` adds the key to the agent once the correct passphrase is supplied. 


### What are some limitations of SSH?

SSH works well in low-latency environments. In high-latency environments such as 4G connections or satellite links, making an SSH connection or relaying user commands can be slow. Mobile Shell (Mosh) has come up as an alternative for these scenarios. It uses SSH for the initial connection but subsequently uses UDP rather than TCP. 

SSH keys don't expire. SSH key mismanagement is an issue. Stolen keys, hardcoded root authorized keys, and host key copied from one host to another are all problems. The Sony breach of 2014 was achieved with stolen SSH keys. 

Port forwarding occurs at the application layer, not at the network layer. Hence, it's not completely transparent to the application. Some configuration may be needed to get it working. For example, FTP data channels are hard to forward. For complete transparency, alternatives such as IPSec or VPN may be more suitable. 


### How can I make SSH connections more secure?

There are a few things system administrators can do on the server side to make SSH more secure. Hackers may try brute-force password attacks. This can be avoided by disabling password-based authentication. Disable remote login for the root user. Be restrictive, that is, allow SSH only for some users. SSH by default uses port 22. Configure the server to use a non-default port. 

When creating public-private key pair, use a strong passphrase. Key generation requires randomness. Use a hardware random number generator. Update the seed file after generating the SSH host key. 

In large organizations, SSH key management solutions are needed. SSH Communications Security's Universal SSH Key Manager and Venafi's SSH Protect are examples. SSH keys should be at locations accessible by only the root user. 

Though SSH sessions are encrypted, traffic analysis can still yield may clues as to what's happening. This could be mitigated by including random amount of padding. 


### Which are the RFCs that specify SSH?

The Secure Shell (SECSH) Working Group of the IETF defined a number of documents for SSH. We note the following as essential reading: 

    + **RFC 4250**: The Secure Shell (SSH) Protocol Assigned Numbers
    + **RFC 4251**: The Secure Shell (SSH) Protocol Architecture
    + **RFC 4252**: The Secure Shell (SSH) Authentication Protocol
    + **RFC 4253**: The Secure Shell (SSH) Transport Layer Protocol
    + **RFC 4254**: The Secure Shell (SSH) Connection ProtocolThe above documents refer to further RFCs that update them: 6668, 8268, 8308, 8332, 8709, 8758, 9141, 9142.  

Two online sources have published useful lists of RFCs pertaining to SSH:  OmniSecu and OpenSSH.

## Milestones

Jul  
1995

Ylönen, a researcher at the Helsinki University of Technology, discovers a password-sniffing attack. Plain-text communication protocols are inadequate and underscore the necessity of secure communication. To address these, Ylönen creates **Secure Shell (SSH)** with a focus on security and encryption. Ylönen releases the first version of SSH, named **SSH-1**. Internet Assigned Numbers Authority (IANA) assigns **port number 22** to SSH. By the year's end, about 20,000 users from 50 countries are using SSH. Given this popularity, in December 1995, Ylönen commercializes the technology under the name SSH Communications Security, Ltd. 

Nov  
1995

Ylonen publishes an IETF Internet-Draft that details SSH. This is the first formal description of the protocol. The draft expires in May 1996. 

Sep  
1996

SSH Communications Security, Ltd. releases **SSH-2**. SSH-1 had evolved in an ad hoc manner and had limitations and flaws. SSH-2 introduces more secure algorithms. It improves session identifier and key exchange. However, SSH-2 is incompatible with SSH-1. The last free version of SSH-1 is 1.2.12. 

Feb  
1997

The use of SSH-2 (as released by SSH Communications Security, Ltd.) has licensing restrictions. At the IETF, a new Working Group named Secure Shell, aka **SECSH**, is formed. It's mandate is to standardize SSH that can also be used openly. The first IETF Internet-Draft of SSH-2 comes out in February 1997. 

Dec  
1999

OpenBSD developers need a secure communication protocol. A few members work to modify and enhance *OSSH*, a fork of SSH created by Swedish programmer Groenvall. OpenBSD releases the first version of **OpenSSH**. In subsequent years, OpenSSH gains wide adoption, particularly in all POSIX-compliant operating systems. 

Feb  
2002

A vulnerability is discovered in the CBC mode block cipher. One suggested solution is to use more secure cipher modes. Systems could disable weak ciphers (3des-cbc, aes128-cbc, aes256-cbc, des-cbc), weak key exchange algorithms (diffie-hellman-group-exchange-sha1, diffie-hellman-group1-sha1) and weak MAC algorithms (hmac-md5, hmac-md5-96, hmac-sha1-96). For example, HP switches can be configured to block these weak options. 

Jan  
2006

IETF publishes the main RFCs that standardize SSH-2: 4250, 4251, 4252, 4253 and 4254. In October, the Working Group SECSH is closed. 

Mar  
2006

IETF publishes RFC 4432 that specifies **RSA Key Exchange**. IETF's SSH-2 uses Diffie-Hellman key exchange, which can take tens of seconds on slow devices. RSA-based key exchange is therefore proposed. The latter was supported in the original SSH-1 protocol. 

Jul  
2012

IETF publishes RFC 6668 that specifies the use of **SHA-2** for data integrity verification. Specifically, it defines hmac-sha2-256 (recommended) and hmac-sha2-512 (optional). This comes as a response to SHA-1 and MD5 algorithms that are now considered weak. In March 2018, RFC 8332 is published. This adds public key algorithms rsa-sha2-256 (recommended) and rsa-sha2-512 (optional). 

Feb  
2020

IETF publishes RFC 8709 that formalizes the use of **Ed25519 and Ed448 algorithms**. These are Digital Signature Algorithms (DSAs) used for authenticating clients and servers. In SSH, they're not used for encryption. OpenSSH 6.5 (released in 2014) introduced support for Ed25519. This RFC formalizes this and adds Ed448. 

Apr  
2020

IETF publishes RFC 8758 that **deprecates RC4**. RC4 encryption with its 128-bit key has known weaknesses. It's replacement are "arcfour128" (128-bit key) and "arcfour256" (256-bit key) that are specified in RFC 4345 (January 2006). In both algorithms, the first 1536 bytes generated by the cipher are discarded. 

Jan  
2022

IETF publishes **RFC 9142** that recommends which key exchange methods are safe and which ones should be avoided. Specifically, SHA-1 hash should be avoided. It also states, "A key exchange method is considered weak when the security strength is insufficient to match the symmetric cipher or the algorithm has been broken."