Sixth USENIX Security Symposium
SSH Secure Login Connections over the InternetTatu Ylönen
SSH Communications Security Ltd.
Tekniikantie 12, FIN-02150 ESPOO, Finland
Tel. (intl) +358-0-4354 3205 fax +358-0-4354 3206
SSH provides secure login, file transfer, X11, and TCP/IP connections over an untrusted network. It uses cryptographic authentication, automatic session encryption, and integrity protection for transferred data. RSA is used for key exchange and authentication, and symmetric algorithms (e.g., IDEA or three-key triple-DES) for encrypting transferred data.
SSH is intended as a replacement for the existing rsh, rlogin, rcp, rdist, and telnet protocols. SSH is currently (March 1996) being used at thousands of sites in at least 50 countries. Its users include top universities, research laboratories, many major corporations, and numerous smaller companies and individuals.
The SSH protocol can also be used as a generic transport layer encryption mechanism, providing both host authentication and user authentication, together with privacy and integrity protection.
1 IntroductionThe Internet has become the most economical means for communication between two remote sites. Its uses include communicating with clients, connecting remote offices, file transfer, remote systems administration, banking services, working at home, and many others.
However, the Internet does not provide any protection for the transmitted information, and can become an information security nightmare for companies connected to it. Firewalls and access controls such as one-time passwords do not fully solve the problem, as it is easy to record and analyze any transmitted data or to hijack an already established connection and use it to attack machines inside the firewall.
The threats from the Internet include:
The current IP protocol does not in any way guarantee any aspects of information security (e.g., authentication, privacy, data integrity). As higher level protocols are mostly based on the assumption that the lower level protocol can be trusted -- and as this is not the case -- the higher level protocols aren't any more reliable. If security is needed, it must be entirely implemented on the application level.
An acceptable solution must guarantee at the same time authentication of both ends of the connection, secrecy of transmitted information, and integrity of transmitted data. For example, if only authentication and integrity (but no secrecy) is provided, the user is likely to eventually type a password to another machine or service, which will then be shown in the clear.
Strong encryption seems to be the only solution to network security. Since several major governments have demonstrated growing interest in economic espionage (including, e.g., United States, Russia, France, and Japan), commercial systems are now faced with some of the most skilled and resourceful opponents in the world, and must be designed using the strongest possible methods to be of any use. Increasing economic significance will also lure interest from criminal organizations, which are certainly well enough funded to break e.g. DES-level encryption methods without much trouble .
2 An Overview of SSH Secure Remote LoginSSH permits secure login connections and file transfer over the Internet or other untrusted networks. Cryptographic algorithms are used to authenticate both ends of the connection, to automatically encrypt all transmitted data, and to protect the integrity of data. Values returned by services such as DNS or network protocols (e.g., TCP/IP ) are considered only advisory, and are validated using cryptography. SSH also automatically and securely forwards X11 connections from the remote machine, and can be configured to forward arbitrary TCP/IP ports. It can also be used for secure file transfer.
3 The SSH ProtocolSSH uses a packet-based binary protocol that works on top of any transport that will pass a stream of binary data. Normally, TCP/IP is used as the transport, but the current implementation also permits using an arbitrary proxy program to pass data to/from the server, and includes direct support for SOCKS and FWTK based firewalls.
The packet mechanism and related authentication, key exchange, encryption, and integrity mechanisms implement a transport layer security mechanism, which is then used to implement the remote login functionality. An attacker is limited to breaking the connection.
Every transmitted packet starts with random padding, followed by (optionally compressed) packet type, packet data, and integrity protection data.
The entire packet is encrypted using a suitable algorithm, such as IDEA-CFB [2, 9], 3DES-CBC , or an RC4  equivalent algorithm (RC4 is a trademark of RSA Data Security, Inc). The packet type and data fields can be compressed with the gzip algorithm before encryption. Compression reduces the amount of transmitted data to about a third for typical interactive sessions.
Integrity protection is currently (March 1996) provided by including CRC32  of the packet under encryption. However, it is being replaced by HMAC-SHA; see Section 5. If tampering is detected, the error is logged, the user is notified, and the connection is terminated.
On the transport, each encrypted packet is prefixed by the length of the packet data, excluding padding (the total length on the wire is the given length rounded up to a multiple of eight bytes in such a way that the length of padding is 1-8 bytes).
The SSH protocol works on top of the packet-level protocol, and proceeds in the following phases:
More information about the protocol can be found in .
3.1 X11 and TCP/IP ForwardingSSH can automatically forward the connection to the user's X server over the secure channel. Forwarding works by creating a proxy X server at the remote machine by allocating the next available TCP/IP port number above 6001 (these correspond to X display numbers so that the port corresponding to display n is 6000+n). The SSH server then listens for connections on this port, forwards the connection request and any data over the secure channel, and makes a connection to the real X server from the SSH client. The DISPLAY variable is automatically set to point to the proper value. Note that forwardings can be chained, permitting safe use of X applications over an arbitrary chain of SSH connections.
SSH also automatically stores Xauthority data  on the server. In fact, the client generates a random MIT-MAGIC-COOKIE-1 authentication cookie, and sends this cookie to the server, which stores it in .Xauthority. When a connection is made, the client verifies that the authority data matches the generated random data, and replaces it with the real data. The motivation for sending a fake cookie is that old cookies left at the server are useless after logout (many users keep the same terminal open for months at a time, and may briefly log into dozens of machines during that time; it is important to not leave the cookies lying around in all of these machines).
TCP/IP forwarding works similarly: the server listens for a socket on the desired port, forwards the request and data over the secure channel, and makes the connection to the specified target port from the other side. There is no authentication for forwarded TCP/IP connections.
3.2 The Authentication AgentSSH supports using an authentication agent. The agent is a program that runs in the user's local machine (or, in future, on a smartcard connected to it). The agent holds the user's private RSA keys. It never gives out the private keys, but accepts authentication requests and gives back suitable answers.
In the Unix environment, the agent communicates with SSH using an open file handle that is inherited by all children of the agent process (the agent is started as a parent of the user's shell). Other users cannot get access to the agent, and even for root it is fairly difficult to send requests to a file descriptor held by some process. Different mechanisms are used on other operating systems.
SSH can forward the connection to the agent to another process running on the server machine (such as another SSH connection). In this way, it is possible to go through an arbitrarily long chain of machines, located anywhere around the world, without the authentication keys ever leaving the agent.
4 Cryptographic Methods Used in SSHSSH attempts to provide strong security without making normal use any more difficult than necessary. Its security relies on cryptographic methods.
SSH uses RSA [6, 9] for host authentication and user authentication. Host keys and user authentication keys are normally 1024 bits.
The server key that changes every hour is 768 bits by default. It is used to protect intercepted historical sessions from being decrypted if the host key is later compromised. The server key is never saved on disk.
Key exchange is performed by encrypting the 256-bit session key twice using RSA. It is padded with non-zero random bytes before each encryption (according to PKCS#1 ). Server host authentication happens implicitly with the key exchange (the idea is that only the holder of the valid private key can decrypt the session key, and receipt of the encrypted confirmation tells the client that the session key was successfully decrypted).
Client host authentication and RSA user authentication are done using a challenge-response exchange, where the response is MD5 of the decrypted challenge plus data that binds the result to a specific session (host key and anti-spoofing cookie).
The key exchange transfers 256 bits of keying data to the server. Different encryption methods use varying amounts of the key: IDEA-CFB uses 128 bits, 3DES-CBC 168 bits, RC4-equivalent 128 bits per direction, and DES-CBC 56 bits. The reasons for using IDEA in CFB mode is mainly historical; the new protocol (Section 5) will use IDEA-CBC instead.
Transmitted data is currently protected against modification by computing a CRC32 of all packet data (including random padding) before encryption. The checksum and all packet data are encrypted. Presumably it will be difficult for an attacker to modify the plaintext data so that the checksum still matches without breaking the encryption first. (The integrity mechanism has changed in the new protocol; see Section 5.)
All random numbers used in SSH are generated with a cryptographically strong generator. SSH has a pool of 8192 bits of randomness. The first time it is started, it uses several commands to gather entropy from the system (on Unix, '`ps laxww'', ``ps -al'', ``ls -alni /tmp/.'', ``w'', ``netstat -s'', ``netstat -an'', and ``netstat -in''). The entropy is mixed into the pool, stirring the pool frequently. The stirring involves encrypting the pool twice using MD5 in CBC mode so that every bit of the pool depends on every other bit. Additional noise is obtained from various system parameters (e.g., disk I/O counts, page swapping counts, interrupt counts, CPU usage) every time the pool is stirred, and if /dev/random is available, 128 bits of noise are taken from there every few minutes and stirred into the pool.
5 The New ProtocolThe SSH protocol is currently undergoing major changes. The protocol will be split to two levels, a generic secure transport layer mechanism and a high-level SSH protocol.
5.1 The New Transport Layer ProtocolThe new transport layer protocol has been designed to be flexible, allowing negotiation of all algorithms and parameters, simple, secure, easily verifiable, and fast. It performs a full algorithm negotiation, key exchange, and mutual host authentication in a total of 1.5 round-trip times typical, and 2.5 round-trip times worst case. A minimal number of round-trips will become increasingly important in future as network bandwidth increases but the speed of light remains constant. Mobile computing, in particular, will put strong demands on the number of roundtrips; over a GSM phone, for example, a round-trip is around a second.
There have been several cryptographic improvements. All data exchanged during key exchange is authenticated. HMAC-MD5 or HMAC-SHA outside encryption are used for data integrity protection. IDEA is now used in CBC mode. All data, including the packet length, is now encrypted (except the MAC). Keys are re-exchanged periodically. The protocol can also interface with a public key infrastructure.
5.2 The New SSH ProtocolThe new SSH protocol runs over the transport layer protocol, which provides a secure channel. The SSH protocol performs user authentication, session management, and handshaking for multiple simultaneous connections (forwarded X11 connections, etc).
User authentication now permits the client to send authentication requests without waiting for responses from the server after each request. This reduces round-trips. Additionally, whenever an authentication request fails (or is insufficient), the server will tell the client which authentication methods can continue the dialog. This permits the server to guide the client through a multi-phase authentication according to the server's per-user policy. The server can require multiple authentications.
All authentication methods that require user input have been merged under one interactive authentication type. This handles passwords, one-time passwords, SecurID cards, and other such methods. The user basically converses with the server using a simple text-based protocol. The protocol does, however, permit dialog-based windowed implementation and local editing at the client.
The new protocol also supports proper flow control for individual channels (e.g., forwarded X11 clients). This will prevent a runaway program from jamming the entire connection. Details of the new protocol are still being specified as of this writing.
6 The Current ImplementationSSH was first published on the Internet in July 1995. Since then, it has been ported to a number of platforms and there have been several other improvements.
SSH currently runs on almost all Unix variants, including e.g. AIX, BSD, Convex, DGUX, HPUX, IRIX, Linux, Mach3, OSF/1, SysV, Solaris, SunOS, Ultrix, and Unicos. A commercial Windows version is available from Data Fellows, and a Macintosh version is due in the fall 1996. A free OS/2 version is also available.
The current Unix version supports SOCKS and FWTK based firewalls, and
permits using an arbitrary proxy program to make the connection. In
most environments, it can be installed simply by
7 PerformancePerformance of SSH can divided into two important parameters: startup time and transfer rate.
The startup time means the time from starting the SSH client to the moment when first data bytes are transferred. The startup time is on the order of a second on 486 or Pentium class machines connected to an ethernet, and on the order of a few seconds for long-distance connections.
Transfer rate means the number of bytes per second that can be transmitted over the secure channel. In the case of SSH, it depends on the encryption algorithm used. On 486-class machines, the rate is 1-2 megabits/second for IDEA, 3-4 megabits/second for DES, and about 5 megabits per second for RC4-equivalent. The rate is almost directly proportional to the speed of the machines; some faster machines run RC4-equivalent in software at speeds exceeding 40 megabits per second.
To summarize, the encryption speed on even slower modern machines is sufficient to fill an ethernet network. Most of the time, transfer rate is not limited by encryption but by the transfer rate of the network. Furthermore, on long-distance connections SSH can be substantially faster than telnet or rlogin, due to compression of transferred data.
8 ConclusionSSH solves one of the most acute security problems on the Internet: that of securely logging from one machine to another, and securely transferring files between machines. It does this in a way that is convenient and completely transparent to users. At the same time, it automates passing the X11 connection, and makes using X11 over long distance connections secure.
SSH uses strong cryptography to achieve this goal. Its fundamental principle is that the network or any of its services cannot be trusted. Usability in normal environments has been a major design concern from the beginning, and SSH attempts to make things as easy for normal users as possible while still maintaining a sufficient level of security. For the most security conscious environments, SSH can be configured to never trust the network, and fail if it cannot e.g. verify the host key of the remote host.
Experience has shown that the CPU overhead caused by strong encryption is negligible. One need not try to justify why to encrypt; doing so costs almost nothing. However, not using strong encryption in all communications can have severe consequences. Also, the strongest available encryption methods should be used, as they are no more expensive than weak methods. Weak encryption will just make transmitted data available to foreign intelligence agencies and criminal organizations.
SSH is currently (June 1996) being used at thousands or tens of thousands of sites in at least 50 countries around the world. There are about one thousand addresses on the mailing list, and many of those are redistribution aliases or newsgroup gateways. The SSH WWW pages are accessed about 1000-2000 times every day (about once every minute). During about a period of about ten days (examined in February 1996), accesses came from about 6000 hosts (many of them WWW proxy/cache servers) in 55 top-level domains. The actual number of people using SSH is not known.
SSH is freely available for non-commercial use. Its WWW home page, including pointers to ftp sites and commercial versions, is available at https://www.cs.hut.fi/ssh.
References J. Campbell. C Programmer's Guide to Serial Communications, Sams, 1993.
 Lai, X. On the Design and Security of Block Ciphers. ETH Series in Information Processing, vol. 1, Hartung-Gorre Verlag, Konstantz, 1992.
 M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones. SOCKS Protocol Version 5, RFC 1928, 1996.
 Mockapetris, P. Domain Names -- Concepts and Facilities, RFC 1034, Internet Engineering Task Force, 1987.
 Public Key Cryptography Standards, #1. RSA Laboratories. Available for anonymous ftp at ftp.rsa.com.
 Rivest, R., Shamir, A., and Adleman, L. M. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, vol. 21, no. 2, 1978, pp. 120-126.
 Rivest, R. The MD5 Message Digest Algorithm, RFC 1321, Internet Engineering Task Force, 1992.
 Scheifler, R. X Window System Protocol. X Consortium Standard, Version 11, Release 6. Laboratory of Computer Science, Massachusetts Institute of Technology, 1994.
 Schneier, Bruce. Applied Cryptography, 2nd edition. John Wiley &em; Sons, 1996.
 Stevens, W. Richard. TCP/IP Illustrated. Volume 1: The Protocols. Addison-Wesley, 1994.
 TIS Firewall Toolkit, Trusted Information Systems Inc., 1993.
 Wiener, M. J. Efficient DES Key Search. Technical Report TR-244, School of Computer Science, Carleton University, 1994.
 Ylönen, Tatu. The SSH (Secure Shell) Remote Login Protocol , 1996. Available on the Internet from the SSH Home Page at https://www.cs.hut.fi/ssh. Also included in the SSH distribution.
This paper was originally published in the
proceedings of The Sixth USENIX Security Symposium, July 2225, 1996,
San Jose, California, USA
Last changed: 10 Jan 2003 aw