SSH FAQ Section 1: About Secure Shell (SSH)? (2024)

1.1.What is Secure Shell?

To quote the README file:

Secure Shell (SSH) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for rlogin, rsh, and rcp.

Additionally, SSH provides secure X connections and secure forwarding of arbitrary TCP connections. You can also use SSH as a tool for things like rsyncand secure network backups.

The traditional BSD 'r' - commmands (rsh, rlogin, rcp) are vulnerable to different kinds of attacks. Somebody who has rootaccess to machines on the network, or physical access to the wire, can gain unauthorized access to systems in a variety of ways.It is also possible for such a person to log all the traffic to and from your system, including passwords (which ssh never sends inthe clear).

The X Window System also has a number of severe vulnerabilities. With ssh, you can create secure remote X sessions whichare transparent to the user. As a side effect, using remote X clients with ssh is more convenient for users.

1.2How widespread is its use?

The most current figures available are over 2 million Secure Shell users in over 60 countries.This is not an accurate amount, but an estimate. It also does not necessarily include thedifferent implementations of Secure Shell for different operating systems.

1.3What protocols does SSH use?

For the SSH1 protocol, you can find this information in an old IETF draft available here.It is also available with the source distribution.

For the SSH2 protocol, you can find this information in the SSH2 IETF drafts:

• SSH Protocol Architecture: draft-ietf-secsh-architecture-04.txt
• SSH Connection Protocol: draft-ietf-secsh-connect-06.txt
• SSH Transport Layer Protocol: draft-ietf-secsh-transport-06.txt
• SSH Authentication Protocol: draft-ietf-secsh-userauth-06.txt
• Generic Message Exchange Authentication For SSH: draft-ietf-secsh-auth-kbdinteract-00.txt

1.4What encryption algorithms does SSH use?

SSH uses the following ciphers for authentication:

* Note: This is only for the commercial release (Datafellows) of SSH2.

1.5How does SSH authenticate?

SSH authenticates using one or more of the following:

• Public key (RSA or DSA)
• Password
• Kerberos
• .rhosts or /etc/hosts.equiv

1.6What does SSH protect against?

Ssh protects against (again, from the README):

• IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. Ssh even protects against a spoofer on the local network, who can pretend he is your router to the outside.
• IP source routing, where a host can pretend that an IP packet comes from another, trusted host.
• DNS spoofing, where an attacker forges name server records
• Interception of cleartext passwords and other data by intermediate hosts
• Manipulation of data by people in control of intermediate hosts
• Attacks based on listening to X authentication data and spoofed connection to the X11 server

In other words, ssh never trusts the net; somebody hostile who has taken over the network can only force ssh to disconnect, but cannot decrypt or play back the traffic, or hijack the connection.

The above only holds if you actually use encryption. Ssh does have an option to use encryption of type "none" this is only for debugging purposes, and should not be used.

1.7What doesn't SSH protect against?

Ssh will not help you with anything that compromises your host's security in some other way. Once an attacker has gained rootaccess to a machine, he can then subvert ssh, too.

If somebody malevolent has access to your home directory, then security is nonexistent. This is very much the case if your homedirectory is exported via NFS.

1.8What is the difference between SSH1 and SSH2?

Because of the different protocol implementation, they are not compatible.

1.9Who maintains SSH?

SSH Communications Security, is the developer of secure shell (SSH) protocoland maintains the releases of SSH1 and SSH2. SSH Communications Security,F-Secure, and Van Dyke all sell their own releases of the application.

For more information on support, see section 8 of this FAQ.

1.10Can I run SSH legally?

Most likely. It depends on your country's laws for cryptography and which version of SSH that you're using. Check out the information on licensing, cryptography laws, and patents on cryptographic algorithms below.

1.10.1Licensing

Please direct any licensing concerns to SSH Communications Security.

The following lists the licensing information from the official distribution siteat ftp.cs.hut.fi/pub/ssh.

SSH1: The UNIX version of ssh 1.2.27 may be used freely for non-commercial purposes and may not be sold commercially as a separate product, as part of a bigger product or project, or otherwise used for financial gain without a separate license The definition of "commercial use" is generally interpreted as using ssh for anything that would generate financial gain, such as logging into a customers system to do administration, or providing ssh as a secure login to your partners or vendors. Seethe COPYING file for more information.

1.10.2Cryptography laws

In some countries, particularly France, Russia, Iraq, and Pakistan, it may be illegal to use any encryption at all without a specialpermit.

If you are in the United States, you should be aware that, while ssh was written outside the United States using informationpublicly available everywhere, the US Government may consider it a criminal offence to export this software from the US once ithas been imported, including putting it on a ftp site. Contact the Office of Defence Trade Controls if you need more information.

There's a really good link that keeps up to date with the Wassenaar Agreement and thecryptography laws throughout the world. Check out Bert-Jaap Koops Crypto Law Survey.

1.10.3Patents on Cryptographic algorithms

The algorithms RSA and IDEA, which are used by ssh, are claimed as patented in different countries, including the US. Linkingagainst the RSAREF library, which is possible, may or may not make it legal to use ssh for non-commercial purposes in the US.You may need to obtain licenses for commercial use of IDEA; ssh can be configured without IDEA and works perfectly finewithout it.

For information on software patents in general, see the League for Programming Freedom's homepage at http://lpf.ai.mit.edu/.

1.11What operating systems does SSH run on?

From the SSH home page:

SSH2 currently runs on the following platforms:

• ix86; NetBSD 1.2, 1.3
• ix86; FreeBSD 2.2.x, 3.0-current
• ix86; Linux 2.0.34
• Sparc; Solaris 2.6, 2.5.1
• PowerPC; AIX 4.1, 4.2.x
• hppa1.1; HP/UX 10.20
• hppa2.0; HP/UX 11.00
• Mips; IRIX 6.2

The non-commercial Unix version of SSH1 works on almost all unix variants, including at least the following:

• 386BSD 0.1; i386
• AIX 3.2.5, 4.1, 4.2; RS6000, PowerPC
• A/UX 3.1.1
• BSD 4.4; several platforms
• BSD/OS 1.1, 2.0.1, 3.0; i486
• BSD/386 1.1; i386
• BSDI 2.1, 3.0; x86 (using gnu make)
• ConvexOS 10.1; Convex
• Digital Unix 4.0, 4.0A, 4.0B; Alpha
• DGUX 5.4R2.10; DGUX
• DolphinOS 3.8
• FreeBSD 1.x, 2.x, 3.0; Pentium
• HPUX 7.x, 9.x, 10.0; HPPA
• IRIX 5.2, 5.3, 6.2, 6.3; SGI Indy
• IRIX 6.0.1; Mips-R8000
• Linux 1.2.x, 2.0.x Slackware 2.x, 3.x, RedHat 2.1, 3.0; i486, Sparc
• Linux 3.0.3, 4.0; Alpha
• Linux/Mach3, Macintosh(PowerPC)
• Linux/m68k (1.2.x, 2.0.x, 2.1.x)
• Mach3; Mips
• Mach3/Lites; i386
• Machten 2.2VM (m68k); Macintosh
• NCR Unix 3.00; NCR S40
• NetBSD 1.0A, 1.1, 1.2, 1.3; Pentium, Sparc, Mac68k, Alpha
• OpenBSD 2.0; x86, mac68k.
• NextSTEP 3.3; 68040
• OSF/1 3.0, 3.2, 3.2; Alpha
• Sequent Dynix/ptx 3.2.0 V2.1.0; i386
• SCO Unix; i386 (client only)
• SINIX 5.42; Mips R4000
• Solaris 2.3, 2.4, 2.5, 2.5.1, 2.6; Sparc, i386
• Sony NEWS-OS 3.3 (BSD 4.3); m68k
• SunOS 4.1.1, 4.1.2, 4.1.3, 4.1.4; Sparc, Sun3
• SysV 4.x; several platforms
• Ultrix 4.1; Mips
• Unicos 8.0.3; Cray C90

There are also non-commercial ports of SSH for SSH1 including PalmOS, Windows, Macintosh, OS/2, BeOS, WindowsCE, Java, and OpenVMS. See section 2 of this FAQ for information on how to SSH.

1.12. Shouldn't I be using only SSH2?

Because of the licensing restrictions on SSH2, many companies like ISPs are notrunning SSH2. Instead, they are still running SSH1. You should check which version ofSSH you are connecting to before installing a client.

If you are installing a daemon, check to make sure your remote clients are connectingto you with the right version of SSH.