Secure Shell

Secure Shell or SSH refers to both a network protocol and appropriate programs, with which one can establish an encrypted network connection to a remote device in a secure way. Often this method is used to make locally a remote command line available, that is, on a local console editions of the remote console will be issued and the local keystrokes are sent to the remote computer. This can be used for example for remote maintenance of a standing in a remote data center server. The newer protocol version SSH-2 provides additional functions such as data transfer via SFTP.

The IANA has the TCP port assigned to the Protocol 22.

  • 3.1 authentication
  • 3.2 encryption
  • 3.3 Vulnerability


The first version of the protocol (now called SSH -1) was established in 1995 by Tatu Ylönen rsh in response to the demand for drop-in replacements for Berkeley Unix services including commands ( remote shell ), rcp ( remote copy ) and rlogin (remote login) developed. He published his implementation in 1995 as freeware, then quickly gained popularity; The end of 1995 there were already 20,000 users in fifty countries.

In December Tatu Ylönen founded the company SSH Communications Security, SSH in order to market and further develop. The original software originally contained open-source source code, but evolved over time more and more to proprietary software.

After some weaknesses in the integrity check of SSH-1 had become known, in 1996, a revised version of the protocol was developed with SSH -2. It is incompatible with SSH -1. Among other things, the protocol was divided into different parts and thus the use of strong encryption and authentication algorithms possible. Thus, the vulnerability was fixed. Currently, the protocol is considered safe.

1999, the desire for a free implementation of SSH was loud and out of the last free version of the original implementation, the separate OpenSSH project developed. Ever since that time the SSH protocol exists in two implementations: the Open - Source Software ( OpenSSH ) and as proprietary software (product name: SSH Tectia ), developed and marketed by SSH Communications Security, so the original developers around Ylönen.

2005, ten years after the original development, the company SSH Communications Security went with Generation 3 ( G3 SSH ) to the public. This protocol supports the use of the proprietary algorithm " Crypticore " (which exist according to the manufacturer benefits especially in data throughput ), but which is considered uncertain ( see Encryption ). The other, more established encryption algorithms are supported. 2006 this protocol (version 2) was proposed by the IETF as an Internet standard. Certification according to FIPS 140-2 standard established for more.


SSH provides a secure, authenticated and encrypted connection between two hosts over an insecure network. Thus, it also serves as a replacement for the previous rlogin, telnet and rsh; this transferred all network traffic, including passwords, unencrypted.

The original application is to log in to remote computers over a network (usually the Internet), but in particular SSH -2 is not only limited to terminal functions.

  • SFTP and SCP provide cryptographically secure alternatives to FTP and RCP.
  • X11 can be transported over SSH and thus secured.
  • About SSH, any TCP / IP connections can be tunneled ( port forwarding ); while a single port is forwarded from a remote server to the client or vice versa, respectively. Thus, for example, an otherwise unencrypted VNC connection will be secured.
  • An SSH client can behave like a SOCKS server, enabling automated access to remote computers through SSH tunnel, about to bypass a firewall.
  • About SSHFS can a remote file system to be mounted on the local machine.
  • With "ssh -keyscan " the public key of a remote computer can be read. So you can with the help of the corresponding public key to determine, for example, if the IP address and / or DNS entry of an SSH server has been tampered with.

Alternatively, the compound may also be compressed to speed up transmission and save bandwidth.

This can now be fundamentally more application scenarios represent:

Note: Of course, SSH can also run on several stations.


In the case of Secure Execution subsystem can subsystems that are defined in an SSH server installation, be executed remotely, without having to know the exact path of the program to be executed on the server. SFTP is the most common subsystem.

In the relevant RFCs, however, several such subsystems are defined.

Any administrator can define its own subsystems beyond; this should be in the case of non- IANA - registered subsystems the Conventions for Names are complied with (keyword @ syntax).


The security of SSH is ensured by a set of cryptographic algorithms for encryption and authentication.


The server identifies itself to the client with an RSA, DSA or ECDSA certificate, which manipulations can be detected on the network (no one else can pretend to be a well-known server).

The client can optionally authenticate via public key authentication with a private key whose public key is stored on the server, or an ordinary password. While the latter always requires user interaction (as long as the password should not be stored unencrypted on the client machine ), allows the public-key authentication is that client computers can login without user interaction to SSH servers, without compromising a password must be stored on the client in plain text. To further ensure the SSH private key can be protected with a password. Newer versions of the OpenSSH server support multi-factor authentication, which requires a combination of supported authentication method must be successfully completed.


After successful authentication, a secret key is generated for the duration of the session, with the all subsequent communications are encrypted. If supported by both sides, is repeated the negotiation of the key under certain conditions (eg, amount of data transferred, user request ). Depending on the protocol version this is a different encryption algorithm to use: SSH - 2 is used by default to AES with a 128 -bit key length. In addition, 3DES, Blowfish, Twofish, CAST, IDEA, Arcfour and SEED are supported with different key lengths. The new generation SSH G3 also supports the proprietary algorithm Crypticore, which is frowned upon among experts as Crypto Security -through - obscurity algorithm and except for a speed boost (according to manufacturer) provides no security benefits.


The integrity check using SSH - 1 has vulnerabilities that allow an attacker to spy on a SSH-1 session. Therefore, only a new protocol version from SSH-2 should still be used up. These are characterized by modular design of the transport, authorization and connection layers and allow unlike SSH - 1, the use of various encryption algorithms.


SSH implementations were originally only available on Unix, however, now have both the SSH server and clients for other platforms programmed (see also: History ). Popular for example, the SSH client PuTTY (for Microsoft Windows and Unix, and Symbian ) and WinSCP. Under Cygwin there is a sshd for Windows, based on OpenSSH. So you can log in via SSH on a Windows machine and gets there a shell. For scripted tasks, such as backup, this is a powerful tool.

With OpenSSH, there is a free implementation of SSH, which has now reached a very high penetration rate. For more free designs are dropbear or lsh.

Furthermore, there are for Microsoft Windows, the free SSH implementation freeSSHd. The SSH server can be installed as a service under Windows. The user control supports NT authentication, so you can log on to a domain. More comprehensive is the Bitvise SSH server, which is also available for personal and non-commercial use free of charge.

The SSH Communications Security provides the SSH Tectia client / server to a commercial SSH implementation, which requires authentication with smart cards and USB tokens (PKCS # 11) and X.509.v3 certificates allows. Also, OpenSSH can use smart cards.

Norms and Standards

SSH is standardized according to the following Request for Comments (RFC ):

  • 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 Protocol
  • RFC 4255 - Using DNS to Securely Publish Secure Shell ( SSH) Key Fingerprints
  • RFC 4256 - Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
  • RFC 4335 - The Secure Shell ( SSH) Session Channel Break Extension
  • RFC 4344 - The Secure Shell ( SSH) Transport Layer Encryption Modes
  • RFC 4345 - Improved Arcfour Modes for the Secure Shell (SSH ) Transport Layer Protocol
  • RFC 4419 - Diffie -Hellman Group Exchange for the Secure Shell (SSH ) Transport Layer Protocol
  • RFC 4432 - RSA Key Exchange for the Secure Shell (SSH ) Transport Layer Protocol
  • RFC 4462 - Generic Security Service Application Program Interface (GSS - API) Authentication and Key Exchange for the Secure Shell ( SSH) Protocol
  • RFC 4716 - The Secure Shell ( SSH) Public Key File Format
  • RFC 4819 - Secure Shell Public Key Subsystem
  • RFC 6668 - SHA -2 Data Integrity Verification for the Secure Shell (SSH ) Transport Layer Protocol