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 rsync and secure network backups.
The traditional BSD 'r' - commmands (rsh, rlogin, rcp) are vulnerable to different kinds of attacks. Somebody who has root access 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 in the clear).
The X Window System also has a number of severe vulnerabilities. With ssh, you can create secure remote X sessions which
are transparent to the user. As a side effect, using remote X clients with ssh is more convenient for users.
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 the
different implementations of Secure Shell for different operating systems.
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:
| Cipher | SSH1 | SSH2 |
| DES | yes | no |
| 3DES | yes | yes |
| IDEA | yes | yes |
| Blowfish | yes | yes |
| Twofish | no | yes |
| Arcfour | no | yes |
| Cast128-cbc | no | yes |
SSH uses the following ciphers for authentication:
| Cipher | SSH1 | SSH2 |
| RSA | yes | yes * |
| DSA | no | yes |
* Note: This is only for the commercial release (Datafellows) of SSH2.
SSH authenticates using one or more of the following:
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.
Ssh will not help you with anything that compromises your host's security in some other way. Once an attacker has gained root access 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 home
directory is exported via NFS.
Because of the different protocol implementation, they are not compatible.
SSH Communications Security, is the developer of secure shell (SSH) protocol and maintains the releases of SSH1 and SSH2. However, since SSH Communications Security releases the non-commercial product, there is no formalized support for it.
Since SSH has licensed the Secure Shell technology to Data Fellows, they control the commercial SSH distribution and provide support for SSH.
For more information on support, see section 8 of this FAQ.
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.
Note: Currently, licensing questions about SSH should be directed to Datafellows, not SSH Communications Security.
The following lists the licensing information from the official distribution site at 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. See the COPYING file for more information.
In email between Data Fellows and the Steve Acheson (one of the maintainers), the following questions were asked and answered:
===============================================================
S: Steve Acheson, FAQ
Maintainer
P: Petri Nyman, F-Secure
SSH Product Manager for Data Fellows
S>Can a company use the 1.2.26 release of the SSH software freely
for
S>internal support and administration without violating the license
S>agreement?
P>You can freely use it for internal support and administration
of your own
P>equipment located in your premises.
S>Does connecting from one machine to another via SSH to
S>read email, do work, etc, violate this agreement?
P>No, unless you provide this ability to a third party or connect
to a third
P>party's computer to provide a service.
S>Does connecting from a purchased PC client SSH software to a non-licensed
S>SSH server violate the agreement?
P>No.
S>Does connecting to a remote site, that is not company owned, but
company
S>administered, via SSH to do administrative work violate the agreement?
P>Yes. You need a commercial license for that.
===============================================================
Earlier versions of ssh had a less restrictive license; see the file COPYING in the accompanying source distributions.
SSH2: The licensing for SSH2 is more strict than the licensing for SSH1. The UNIX version of ssh 2.0.13 may only be freely used for educational or personal use (see license agreement). If commercial use is wanted, it must be purchased from Data Fellows. See LICENSING.SSH2 for more information.
If you are interested in the licensing information of other SSH products, please
contact the maintainer. If it is a commercial product, please contact the company
directly.
In some countries, particularly France, Russia, Iraq, and Pakistan, it may be illegal to use any encryption at all without a special permit.
If you are in the United States, you should be aware that, while ssh was written outside the United States using information publicly available everywhere, the US Government may consider it a criminal offence to export this software from the US once it has 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 the
cryptography laws throughout the world. Check out Bert-Jaap Koops
Crypto Law Survey.
The algorithms RSA and IDEA, which are used by ssh, are claimed as patented in different countries, including the US. Linking against 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 fine without it.
For information on software patents in general, see the Leauge for Programming Freedom's homepage at
http://lpf.org/.
From the SSH home page:
SSH2 currently runs on the following platforms:
The non-commercial Unix version of SSH1 works on almost all unix variants, including at least the following:
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.
Because of the licensing restrictions on SSH2, many companies like ISPs are not running SSH2. Instead, they are still running SSH1. You should check which version of SSH you are connecting to before installing a client.
If you are installing a daemon, check to make sure your remote clients are connecting
to you with the right version of SSH.
| Table of contents of this chapter | | General table of contents | | Beginning of this section |