Check out the new USENIX Web site.

Home About USENIX Events Membership Publications Students
Sixth USENIX Security Symposium

SSH -- Secure Login Connections over the Internet

Tatu 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 Introduction

The 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:

  • Network monitoring: it is easy to record passwords, financial data, private messages, or corporate secrets from the network.

  • Connection hijacking: it is possible to hijack a connection without either party noticing it, insert new commands at the command prompt, and remove the output of those commands from the output sent to the user. The same mechanisms can, for example, be used to manipulate remote banking connections to make wire transfers with a different sum and account than what the user thinks (and sees). Having the accounts protected by one-time passwords does not help.

  • Routing spoofing: standard routing protocols and commonly used router configurations permit anyone in the world to reconfigure routings. This can be used to bring connections into networks through which they do not normally go, and where they can be hijacked.

  • DNS (domain name server spoofing): active network-level attacks can be used to make name servers return whatever data is beneficial for further attacks. Verification by reverse-mapping does not help. The same holds for practically all widely used network services.

  • Denial of service attacks: here the purpose is to prevent others from using a particular service. The simplest implementation of this attack is to overload the target machine with requests; however, more subtle forms are available, such as reconfiguring the routers so that packets no longer go to the machine, hijacking connections to the machine and returning erroneous results, etc.

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 [12].

2 An Overview of SSH Secure Remote Login

SSH 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 [10]) 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 Protocol

SSH 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 [9], or an RC4 [9] 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 [1] 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:

  • The client opens a connection to the server. (Note that an attacker may cause the connection to actually go to a different machine.)

  • The server sends its public RSA host key and another public RSA key (``server key'') that changes every hour. The client compares the received host key against its own database of known host keys (in future, it will validate the host key using a public key infrastructure; however, at present no such infrastructure exists).

    At present, SSH is not able to validate keys for hosts that it does not already know. It will normally accept the key of an unknown host and store it in its database for future reference (this makes SSH usable in practice in most environments). However, SSH can also be configured to refuse access to any hosts whose key is not known.

  • The client generates a 256 bit random number using a cryptographically strong random number generator, and chooses an encryption algorithm from those supported by the server (normally IDEA or three-key 3DES). The client encrypts the random number (session key) with RSA using both the host key and the server key, and sends the encrypted key to the server.

    The purpose of the host key is to bind the connection to the desired server host (only the server can decrypt the encrypted session key). The server key is used to make decrypting recorded historic traffic impossible after the server key has been changed (usually every hour) in the event that the host key becomes compromised. The host key is normally a 1024 bit RSA key, and the server key is 768 bits. Both keys are generated using a cryptographically strong random number generator.

  • The server decrypts the RSA encryptions and recovers the session key. Both parties start using the session key (until this point, all traffic has been unencrypted on the packet level). The server sends an encrypted confirmation to the client. Receipt of the confirmation tells the client that the server was able to decrypt the key, and thus holds the proper private keys.

    At this point, the server machine has been authenticated, and transport-level encryption and integrity protection are in use.

  • The user is authenticated to the server. This can happen in a number of ways; the dialog is driven by the client which sends requests to the server. The first request always declares the user name to log in as. The server responds to each request with either ``success'' (no further authentication is needed) or ``failure'' (further authentication is required).

    Currently supported authentication methods are:

    • Traditional password authentication. The password is transmitted over the encrypted channel, and thus cannot be seen by outsiders.

    • A combination of traditional .rhosts or hosts.equiv authentication and RSA-based host authentication. Host authentication works by the server generating a 256 bit challenge, encrypting it with the client's public host key, and sending the encrypted challenge to the client. The client decrypts the challenge, and computes MD5 [7] of the challenge and other information that binds the returned value to the particular session. The client then sends this value to the server; the server makes the corresponding computations and compares the values.

    • Pure RSA authentication. The idea is that possession of a particular private RSA key serves as authentication. The server has a list of accepted public keys. The client requests authentication by a particular key, and the server responds with a challenge similar to that in RhostsRSA authentication.

    • Support is also included e.g. for Security Dynamics SecurID cards. Adding new authentication methods is easy.

  • After authentication has been successful, a preparatory phase begins. In this phase, the client sends requests that prepare for the actual session. Such requests include allocation of a pseudo-tty, X11 forwarding, TCP/IP forwarding, etc. Adding new preparatory operations is easy.

    After all other requests, the client sends a request to start the shell or to execute a given command. This message causes both sides to enter the interactive session.

  • During the interactive session, both sides are allowed to send packets asynchronously. The packets may contain data, open requests for X11 connections, forwarded TCP/IP ports, or the agent, etc. Finally at some point the client usually sends an EOF message. When the user's shell or command exits, the server sends its exit status to the client, and the client acknowledges the message and closes the connection.

More information about the protocol can be found in [13].

3.1 X11 and TCP/IP Forwarding

SSH 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 [8] 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 Agent

SSH 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 SSH

SSH 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 [5]). 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 Protocol

The 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 Protocol

The 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 Protocol

The 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 Implementation

SSH 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 ./configure make make install

7 Performance

Performance 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 Conclusion

SSH 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

[1] J. Campbell. C Programmer's Guide to Serial Communications, Sams, 1993.

[2] Lai, X. On the Design and Security of Block Ciphers. ETH Series in Information Processing, vol. 1, Hartung-Gorre Verlag, Konstantz, 1992.

[3] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones. SOCKS Protocol Version 5, RFC 1928, 1996.

[4] Mockapetris, P. Domain Names -- Concepts and Facilities, RFC 1034, Internet Engineering Task Force, 1987.

[5] Public Key Cryptography Standards, #1. RSA Laboratories. Available for anonymous ftp at ftp.rsa.com.

[6] 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.

[7] Rivest, R. The MD5 Message Digest Algorithm, RFC 1321, Internet Engineering Task Force, 1992.

[8] Scheifler, R. X Window System Protocol. X Consortium Standard, Version 11, Release 6. Laboratory of Computer Science, Massachusetts Institute of Technology, 1994.

[9] Schneier, Bruce. Applied Cryptography, 2nd edition. John Wiley &em; Sons, 1996.

[10] Stevens, W. Richard. TCP/IP Illustrated. Volume 1: The Protocols. Addison-Wesley, 1994.

[11] TIS Firewall Toolkit, Trusted Information Systems Inc., 1993.

[12] Wiener, M. J. Efficient DES Key Search. Technical Report TR-244, School of Computer Science, Carleton University, 1994.

[13] 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.


Relevent URLs

https://www.cs.hut.fi/~ylo/
Tatu Ylonen's home page.

https://www.cs.hut.fi/ssh/
SSH Home Page.

https://www.ssh.fi/
SSH Communications Security Ltd.

https://www.datafellows.com/
Data Fellows Ltd.

?Need help? Use our Contacts page.

Last changed: 1 May 2002 aw
Conference Index
USENIX home