This sections answers general questions about this document. Click here for the contents of this section.
The official and latest version of this HTML document is available from its official sites and mirrors.
Official sites (United States distribution):
European mirror (UK):
If you're interested in maintaining a mirror of this document (especially for those outside of the United States), drop either of the maintainers a line.
You can also get other versions of this document:
This document is currently maintained by Anne Carasik (anne@ipsec.com) and Steve Acheson (satch@employees.org).
If you found a broken link, inaccurate information, or something to add, please send your corrections about the document to either Anne Carasik (anne@ipsec.com) or Steve Acheson (satch@employees.org). If you are looking for support, go here.
This FAQ is created by Anne Carasik and Steve Acheson, based off of the FAQ from Steve Acheson, which is based off of the original FAQ (quite out of date) by by Thomas.Koenig@ciw.uni-karlsruhe.de. You can still find the original FAQ at http://www.uni-karlsruhe.de/~ig25/ssh-faq/index.html, although it is no longer being maintained.
As for the current document:
All information contained in this FAQ is provided "as is." All warranties, expressed, implied or statutory, concerning the accuracy of the information of the suitability for any particular use are hereby specifically disclaimed. While every effort has been taken to ensure the accuracy of the information contained in this FAQ, the authors assume(s) no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
Secure Shell Frequently Asked Questions may be reproduced and distributed in its entirety (including this authorship, copyright, and permission notice), provided that no charge is made for the document itself, without the author's consent. This includes "fair use" excerpts like reviews and advertising, and derivative works like translations.
In other words, use your own good judgment :-)
Most of the credit, of course, goes to Tatu Ylönen for writing SSH and making it available to the public. Also, thanks to Sami Lehtinen and Timo Rinne for currently maintaining the current version of SSH.
Of course thanks go to Steve Acheson and Thomas König for their work in previous FAQs.
This section should answer general questions about SSH and what it does and doesn't do. Click here for the contents of this section.
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:
SSH uses the following ciphers for encryption:
|
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.
The difference between SSH1 and SSH2 is they are two entirely different protocols. SSH1 and SSH2 encrypt at different parts of the packets, and SSH1 uses server and host keys to authenticate systems where SSH2 only uses host keys. SSH2 is a complete rewrite of the protocol, and it does not use the same networking implementation that SSH1 does. Also, SSH2 is more secure.
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
SCan a company use the 1.2.26 release of the SSH software freely for
Sinternal support and administration without violating the license
Sagreement?
PYou can freely use it for internal support and administration of your own
Pequipment located in your premises.
SDoes connecting from one machine to another via SSH to
Sread email, do work, etc, violate this agreement?
PNo, unless you provide this ability to a third party or connect to a third
Pparty's computer to provide a service.
SDoes connecting from a purchased PC client SSH software to a non-licensed
SSSH server violate the agreement?
PNo.
SDoes connecting to a remote site, that is not company owned, but company
Sadministered, via SSH to do administrative work violate the agreement?
PYes. 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:
There may be other implementations that have developed for SSH2; however, I do not have that information. If you do, please let me know.
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.
This section should give you information on where to pick up different implementations of Secure Shell. Click here for the contents of this section.
If you're looking for the official release of SSH, it is listed below.
The central site for distributing ssh is at the Helsinki University of Technology. The files are available via FTP at ftp://ftp.cs.hut.fi/pub/ssh/.
Official releases of SSH1 are PGP-signed, with the following key ID:
|
Type |
Bits |
Date |
User ID |
|
DCB9AE01 |
1024 |
1995/04/24 |
Ssh distribution key <ylo@cs.hut.fi |
|
Key fingerprint = C8 90 C8 5A 08 F0 F5 FD 61 AF E6 FF CF D4 29 D9 |
|||
Official releases of SSH2 are PGP-signed, with the following key ID:
|
Type |
Bits/KeyID |
Date |
User ID |
|
pub |
2048/AFCA7459 |
1998/07/11 |
Ssh 2 Distribution Key <ssh2@ssh.fi |
Ssh is also available via anonymous ftp from the following sites:
Note that some mirrors may not have the most recent snapshots available.
Here is a list of other implementations SSH clients and servers. The official distribution from Helsinki University of Technology is not included with these downloads.
Niels Möller is developing a GPL'd C implementation of the ssh version 2 protocol. Pick up the latest release at http://www.lysator.liu.se/~nisse/archive/.
Most recently, OpenBSD has also created a free SSH implementation of SSH1. You can find it at http://www.openbsd.org/crypto.html#ssh. You can get the Linux port at http://violet.ibs.com.au/openssh/.They say that after someone installs OpenBSD, they immediately install SSH afterward. Very cool.
There are a couple of different Java implementations of SSH.
For some reason, a lot of people have created SSH ports to Windows :-). This is the current list of Windows ports.
NiftyTelnet 1.1 SSH is Jonas Wallden's implementation of SSH1 for Macintosh. It is available at http://www.lysator.liu.se/~jonasw/freeware.html.
There is David Jones' OpenVMS SSH1 server available at http://www.er6.eng.ohio-state.edu/~jonesd/ssh/. The OpenVMS SSH1 client is done by Christer Weinigel and Richard Levitte and is available at http://www.free.lp.se/fish/.
The ISAAC group released a version of the SSH1 client for the Palm Pilot, Top Gun ssh 1.2. It's available at http://www.isaac.cs.berkeley.edu/pilot/.
Mov Software has released a port of SSH1 to WindowsCE called sshCE. You can register for beta testing at http://www.movsoftware.com/sshce.htm.
The current BeOS R4 port of SSH1 for Intel and PowerPC platforms is available through Be directly at http://www.be.com/beware/Network/ssh.html.
The most current port of the SSH1 client to OS/2 is available at ftp://hobbes.nmsu.edu/pub/os2/apps/internet/telnet/client/ssh-1.2.27-b1.zip, which runs on OS/2 Warp 3+.
There are two current commercial releases of SSH. They are sold by Datafellows and Van Dyke Software.
F-Secure Tunnel and Terminal is available at http://www.datafellows.com/products/cryptography/f-sshtt.htm. It runs on UNIX, Windows, and Macintosh. It implements the SSH2 protocol, and does have a command-line scp for Windows. Please contact Datafellows directly for more information.
SecureCRT is available at http://www.vandyke.com/products/SecureCRT/. It runs on Windows platforms and supports the SSH1 and SSH2 protocol. Please contact Van Dyke directly for more information.
This section gives you basic information on how to install the Secure Shell distribution from SSH Communications Security. Click here for the contents of this section.
The latest version of SSH1 is 1.2.27, and SSH2 is 2.0.13. If you are not using the latest version, you may run into problems.
The latest version of lsh is 0.1.3, and be aware that lsh is still in testing mode and is not ready for prime-time yet.
To install SSH, download the tar files and place in a temporary directory. Then do the following:
# gzip -dc ssh-2.0.13.tar.gz | tar -xvf -
# cd ssh-2.0.13
# ./configure
# make
# make install
Please read the INSTALL file for more specifc instructions.
If you run into any problems, check out the troubleshooting section before sending it to the SSH mailing list.
Note:
You may have to use specific options with configure to get SSH to work the way you want (with certain ciphers, using TCP Wrappers, socks support, etc.).If you run the server, sshd, as a user other than root then you can only login as that user.
If you install the client, ssh, non setuid root you will still be able to connect and login to remote servers, but you will not be able to use the .rhosts form of user authentication.
You can also start up sshd yourself as non-root, supplying the -p option so it binds to a non-privileged port (1024), and then connect from another system with ssh -p. This will only allow connections to your own account, and sshd will, as a rule, not be restarted when your machine reboots.
You will have to decide whether this is useful for you or not.
Solaris 2.6, 2.7:
This section gives you basic information on how to run the clients and servers from SSH1 and SSH2. This covers the Secure Shell distribution from SSH Communications Security. Click here for the contents of this section.
This part goes into some very basic usage about the latest release of SSH1, 1.2.27. If this doesn't answer your question, try the man pages that came with the distribution (Read the Fine Manual :-).
To use ssh1 to login to a computer with the same username:
$ ssh remote.example.org
To use ssh1 to login to a computer with a different username:
$ ssh -l username remote.example.org
To use ssh1 to securely send a command to a remote system:
$ ssh remote.example.org command
You can also define the cipher, turn on compression, define configuration file location, forwarding, and many other things. For more information, check out the ssh1 man page.
To use scp1 to copy a file to a remote system:
$ scp localdir/to/filelocation user@host:/dir/for/file
To use scp1 to copy a remote file to the local system:
$ scp user@host:/dir/for/file localdir/to/filelocation
To keep the file attributes of the source file from the source host, use -p:
$ scp -p user@host:/dir/for/file localdir/to/filelocation
For more information, check out the scp1 man page.
To run the sshd1, just type it on the command line (usually as root, unless you're not running an ssh daemon as root).
# sshd
You can also define the host key files, the configuration files, the port, and the number of bits in the server key. See the man page for more details.
Note:
You can start up sshd in a start-up script on your system.To put public keys in memory, use ssh-agent. To run it by itself, it will run in the background and load your public key into memory:
$ ssh-agent
If you want to run it with an x-window (like xterm or dtterm), you can run it like so:
$ ssh-agent xterm &
Here's the man page.
You can add other identities to ssh-agent using ssh-add. You can also list and delete identities with ssh-add (which should have been named ssh-identity manager :-).
To add an identity:
$ ssh-add identityfile
If used without any file defined, it will automatically add the default identification file. See the man page for more details.
This part goes into some very basic usage about the latest release of SSH2, 2.0.13. If this doesn't answer your question, like SSH1--try the man pages that came with the distribution.
In ssh2, it uses similar syntax that ssh1 uses. To use ssh2 to login to a computer with the same username:
$ ssh2 remote.example.org
To use ssh2 to login to a computer with a different username:
$ ssh2 -l username remote.example.org
To use ssh2 to securely send a command to a remote system:
$ ssh2 remote.example.org command
You can play with more functionality on ssh2 than ssh1 like toggling the forwarding for the authentication agent and X traffic. Note that the options are different from ssh1. For more information, check out the ssh2 man page.
To use scp2 to copy a file to a remote system:
$ scp2 localdir/to/filelocation user@host:/dir/for/file
To use scp2 to copy a remote file to the local system:
$ scp2 user@host:/dir/for/file localdir/to/filelocation
To keep the file attributes of the source file from the source host, use -p:
$ scp2 -p user@host:/dir/for/file localdir/to/filelocation
Also note that scp2 has other functionality such as simulating a smv (secure move) command with the -u option. For more information, check out the scp2 man page.
To run the sshd2, just type it on the command line (usually as root, unless you're not running an ssh daemon as root).
# sshd2
You can also define the host key files, the configuration files, the port, and other options (there is no server key in sshd2). See the man page for more details.
Note:
You can start up sshd2 in a start-up script on your system.To put public keys in memory for SSH2, use ssh-agent2. To run it by itself, it will run in the background and load your public key into memory:
$ ssh-agent2
If you want to run it with an x-window (like xterm or dtterm), you can run it like so:
$ ssh-agent2 xterm &
Here's the man page.
You can add other identities to ssh-agent2 using ssh-add2. You can also list and delete identities with ssh-add2 (which should have been named ssh-identity2 manager :-).
To add an identity:
$ ssh-add2 identityfile
If used without any file defined, it will automatically add the default identification file. See the man page for more details.
To transfer data using SSH, use the sftp2 client. The syntax is:
$ sftp2 remoteserver user
The remote server should be running sshd2. See the man page for details.
The central problem of administering ssh is the management of host keys. To allow a client to connect to a remote host with RSA host authentication, the server needs to know the client's public key.
You can collect these automatically each night using either make-ssh-known-hosts.pl (distributed with the ssh source distribution) or with the much faster ssh-keyscan, from ftp://ftp.cs.hut.fi/ssh/contrib/.
Thomas König has written a script to process output from one of these utilities, check for new keys, warn about hosts which have changed their keys (which could be an indication of a man in the middle attack) and generate a complete new file. This script is available from http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list.
With these utilities, you can write scripts to verify public keys on a regular basis. When new machines are running ssh or people have changed public keys, you may want to contact the people in question directly, to make sure there were no man in the middle attacks (to which these utilities are vulnerable).
This section gives you some information on how getting Secure Shell to work with other applications. Click here for the contents of this section.
Yes. Since ssh is a drop-in replacement for rsh, backup scripts should continue to work. You can use datbkr by David Cinege, which uses SSH to do backups over an SSH connection. You can get datbkr at http://www.psychosis.com/datbkr.
You can also use rdist and rsync, which there is more information at below.
Yes; you can use TCP forwarding for that, by using its secure TCP forwarding features. You can also tunnel through another open port through the firewall (I'm sure all those system admins love me now :-) by running a daemon on the remote side on a port that's allowed through a firewall, like SSL (port 443).
Set up the remote daemon running sshd on port 443:
# sshd -p 443
Then, on your local system, open a connection on port 443:
$ ssh -p 443 remotehost.example.org
Yes.
If you use rdist, don't forget to compile the path to ssh into it. Alternatively, you may specify the -P option so rdist uses ssh, and not rsh.
If you use password authentication with rdist 6.1.2 through 6.1.5, you will need to apply the following patch to rdist to make it work:
--- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996
+++ src/rshrcmd.c Tue Jun 11 16:52:05 1996
@@ -63,7 +63,7 @@
/* child. we use sp[1] to be stdin/stdout, and close
sp[0]. */
(void) close(sp[0]);
- if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0 || dup2(0, 2) < 0) {
+ if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0) {
error("dup2 failed: %s.", SYSERR);
_exit(255);
}
This also applies if you get a "Warning: Denied agent forwarding because the other end has too old version." error (which occurs if your client is 1.2.17 or later, and it connects to an older server).
Another alternative would be to use rsync, a rdist replacement, which was designed to work with ssh, and makes better use of bandwidth. More information can be found at http://rsync.samba.org/rsync. You can use the --rsh=/usr/local/bin/ssh option to use SSH as a transport.
You can run PPP over a regular ssh connection. See http://www.inka.de/~bigred/sw/ssh-ppp-new.txt for a working solution. It's a good idea to enable compression for this.
However, this may cause problems for forwarding TCP connections, because both the TCP connection over which ssh runs and a TCP connection forwarded over the PPP/ssh tunnel may retransmit at the same time. In this case, it is better to use encrypted IP tunneling via UDP. A possible implementation of this is http://www.inka.de/~bigred/devel/cipe.html .
Also look into Magnus Lundström's replacement for ssh-ppp in C for Linux, which is now being ported to other OS's. See http://detached.net/vpnstarter. The vpnstarter is more reliable (and easier to set up) than ssh-ppp.
There is a general working solution for RPC-based services, such as NIS. You can download it from ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/ . NIS, in particular, is working.
In principle, this could also be adapted for NFS; this has not been done yet.
Services which are based purely on UDP, such as DNS, have not been secured with ssh yet, although it is possible in principle.
If you want to avoid sending ftp passwords in cleartext over the net, you can use ssh to encrypt your command channel. This will still leave your data channel open to all attacks on TCP, and will not work through a firewall.
You can either use ftpsshd by Per-Erik Martin at http://www.docs.uu.se/~pem/hacks/ for SSH1, or you can do this by hand.
Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do
myhost$ ssh -g -L 1234:ftphost.example.com:21 ssh-server
This logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost.
Note:
You need to use -g if you're forwarding to localhost.Then, in another window, you do
myhost$ ftp localhost 1234 220 ftphost FTP server (Foonix 08/15) ready. Name: (myhost:yourname): 331 Password required for yourname Password: 230 User yourname logged in.
This works if the remote ftp daemon accepts PORT commands which specify a different host from the one the command channel appears to come from, and if the ftp client always uses PORT. This is true for vanilla UNIX ftp client and ftpd servers; it may not work for more advanced ftpds, such as wu-ftpd.
For servers which do not accept this, you can see wether you ftp client supports passive mode, and wether the ftp server accepts PASV.
For POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) has written a script which protects the mail transfer and passwords ussing ssh. It requires no modification to existing POP servers or clients, and is available from ftp://ftp.internatif.org/pub/unix/gwpop/ .
Other services could be secured by similar means. Note, however, that unencrypted ftp data connections are still vulnerable to session hijacking and snooping.
Socks 4 and 5 support should work in 1.2.16 or later. Socks support in version 2.0.11 and later should work.
There's two patches available for AFS in SSH:
Yes. To configure the sources and create an SSH build that supports TCP Wrappers:
# ./configure --with-lib-wrap=/PATHOF/libwrap.a
Then add the following lines to Secure Shell Makefile:
-I/PATHOF/tcpwrappers
WRAPLIBS = -L/PATHOF/tcpwrappers -lwrap
You will also need to define the /etc/hosts.allow and /etc/hosts.deny appropriately. See the TCP Wrappers documentation for more details.
To configure the sources and create an SSH build that supports X forwarding:
# ./configure --with-x
Run make and make install normally. You'll also want to make sure your configuration file is set properly. In /etc/ssh_config for ssh1:
ForwardX11 yes
In /etc/sshd_config for sshd1:
X11Forwarding yes
In /etc/ssh_config for ssh1:
ForwardX11 yes
In /etc/ssh2/sshd2_config for sshd2:
ForwardX11 yes
Note that you do not have to change the /etc/ssh2/ssh_config file. If you are running TCP Wrappers along with X forwarding, you need to make sure you add the necessary sshdfwd-X11: line in the /etc/hosts.allow file. This should not contain the host you are coming from.
It is not likely that this will be implemented. GL uses a totally different protocol from X, and at least gld would have to be replaced.
OpenGL, when run as an X server extension, should pose no problem. You may need to set the environment variable GLFORCEDIRECT=no.
No, not currently. As digital certificates become more popular, SSH will probably support digital certificates in the future.
Only in SSH2. It's supported in release 2.0.13 or later.
This section gives you information on how to get and apply patches for Secure Shell. Click here for the contents of this section.
Please 'cd' to your ssh source directory, and give the command:
% patch -p1 -l < /path/to/sshpath
Then run make distclean, configure, make, and make install again.
The official location for recent patches to SSH1 and SSH2 is available from http://www.ssh.fi/sshprotocols2/. You can get older patches for SSH1 and SSH2 at http://www.ssh.fi/sshprotocols2/oldnews.html.
James Barlow maintains a repository for ssh patches at:
http://www.ncsa.uiuc.edu/General/CC/ssh/patch_repository/
His comments:
"I have put in a few patches we have done, a few that have been posted to the newsgroup, and a few others that I know of. There is a page that describes submitting patches, and if anybody has comments they can let me know. Most of the patches currently relate to the 1.2.x version, but I can put up patches for the 2.0.x version as well."
This section gives you very basic information on how to troubleshoot Secure Shell. This section is especially crucial to get any additions or corrections as SSH continues to grow and get used. Click here for the contents of this section.
This section goes over compiling problems that may affect any platform.
For some operating systems, there are bugs in the gmp assembler routines. Try:
# make distclean
# configure --disable-asm
# make
# make install
to compile.
Check your path. Make sure you can find xauth with the "whereis xauth" or "which xauth" command. If not, add the path to xauth the way your shell likes you to do this, then run configure again.
This section covers some of the problems with running SSH that are not operating system dependent.
Check whether gethostbyname() really returns the complete lists of possible IP addresses (you might, for example, have your system configured to search /etc/hosts first, which might contain only one of the IP addresses).
There are several possibilities why this could be the case in SSH1; common ones include
RhostsRSAAuthentication is a functional replacement for the 'r' utilities; this requires the ssh program to be setuid root, a secret key in /etc/ssh_host_key file on the client, a corresponding public key entry in /etc/ssh_known_hosts, plus entries in ~/.[sr]hosts or /etc/[s]hosts.equiv.
RSAAuthentication is done on a per-user basis and requires a ~/.ssh/identity file on the client side (to be generated with ssh-keygen), plus a matching ~/.ssh/authorized_keys on the server side.
This is a configuration problem.
SSH1 attempts to fall back to the "r" commands when it cannot connect to an ssh daemon on the remote host. It does this by execing your old rsh to use the old protocol.
There are two possibilities why this could be:
In that case, you might want to move the old rsh and rlogin binaries into /usr/old, patch the old rsh binary by running the Perl script
perl -pi.orig -e 's+/usr/(bin|ucb)/rlogin+/usr/old/rlogin+g ;' /usr/old/rsh
which will generate a patched version of rsh and save the old one in /usr/old/rsh.orig.
Reconfigure ssh with --with-rsh=/usr/old/rsh.
SSH2 doesn't ever use rsh. And won't in the future, either. It would be against the draft.
This is due to a known race condition in the ssh protocol before 1.2.13.
Some changes have been made to the protocol in 1.2.14 to prevent this. Unfortunately, these changes may also cause hangs when using TCP forwarding between 1.2.14 and earlier versions. In these cases, upgrade to 1.2.27 on both ends.
It is very likely that you are looking at a telnet, rlogin or X session to the machine that you run ssh on. Check that those packets really are ssh packets (for example by checking their port number; sshd listens on port 22).
This is a limitation in the RSAREF library. You should set a host key with at most 896 bits.
When a client connects, sshd forks a child that does the protocol handling, and this child forks a second child for the user shell or command. The problem is that the setuid() call to the correct user appears only in the second child, so the first child keeps running as root.
Among other potential problems this means that connections redirected with -Lx:host:port will be made from the root uid to host:port, since the first child does them. This means that when the target host does an ident query, it gets back only "root" and no indication of the actual user.
This has been reported as a bug; it is not known wether this will be fixed in a future release.
This section goes over some known problems with forwarding X traffic through SSH.
No, it doesn't. Use "ssh -f otherhost xclient" instead, or "ssh -n otherhost xclient &" if you want a script to be compatible with rsh.
rxvt closes all file descriptors when starting up, including the one used by ssh-agent. Use xterm, or look at the mailing list archives at http://www.cs.hut.fi/ssh/ssh-archive/ for Timo Rinne's rxvt patch.
This can happen if the xauth program was not found at configure time. Correct the path, reconfigure and recompile.
It can also happen if ssh was configured with the --with-libwrap option and the necessary sshdfwd-X11: line in the /etc/hosts.allow file doesn't contain the host you are coming from.
Another problem is with Solaris. Cameron Simpson's experience:
We have a longstanding problem with xauth on Solaris. About a year ago the Solaris X distribution was rebuilt to put the UNIX socket in a special directory in /var to avoid a security issue with having it in /tmp (an attacker could move it sideways and insert a fake one). Then some months later the X distribution was modified again, moving the socket back because the better fix was more careful use of permissions in /tmp.
Meanwhile, we'd built our own X distributions for extra stuff and because the Sun one lags behind the X.org one. So now we have various X servers and xauth programs lying around which have different ideas about where the X socket it, and ssh forwarding can break if the xauth the sshd runs and the X server the user is using have different mindsets.
The solution is to make sure your homegrown X builds match the current OS distribution's ideas. So we're going to have to clean out our old local copies and rebuild, but we've not had time yet. The workaround is to put a symlink in one spot pointing at the other, so both paths to the socket work.
At any rate, you should add "xauth and the X server have different ideas about where the UNIX domain socket is" to the list of possible causes of xauth failure, listing the above situation as an example.
Either the remote end has disabled X11 forwarding (ForwardX11 No in the config file), or either the xauth command or the X11 libraries were not found when compiling the server.
This section goes over some known problems with SSH on Linux systems.
You need to set the hostname to the fully qualified domain name for this to work. Some Linux distributions set the hostname to the first part of the FQDN only.
This is an incorrectly configured Linux system; do a "cd /usr/lib; ln -s libc.sa libg.sa" as root to remedy this.
This section goes over some known problems with SSH on Solaris systems.
Set the CPP environment variable to "cc -E -Xs" before running configure.
For Solaris 2.4, this s a kernel bug. Get the patch 101945-37 to fix it. Please note that at least one earlier version, 101945-36, seems to have reintroduced the bug.
If you experience the same problem with Solaris 2.5.1, upgrade to ssh 1.2.27 (this was fixed in 1.2.14), which should solve the problem.
This is a problem with the Solaris shared library code, which causes a hang with some name server functions.
Get Patch 103187-02 (for x86, 103188-02) to fix this. This problem may or may not be fixed in Solaris 2.5.1.
This is a bug in gcc 2.7.0, which causes it to generated incorrect code without optimization. Supply the "-O" or "-O -g" options to gcc when compiling. Alternatively, upgrade to gcc 2.7.2 or later.
This section goes over some known problems with SSH on other operating systems not covered above. This currently includes AIX, HP-UX, and Alpha OSF/1.
For Alpha OSF/1 1.3.2, this is due to a bug in the vendor-supplied compiler with maximum optimization.
Turn off all optimization for ssh-keygen, or use gcc. Gcc 2.7.2 is known to have problems on the Alpha, however.
This is believed to be a bug in HP-UX 9 xauth, SR 5003209619. Patch PHSS_5568 is believed to fix this problem.
This is a bug in AIX 3.2.5, reported as APAR IX38941, and fixed by patches U435001, U427862, U426915, and a few others. Contact your IBM representative for details.
This section gives you a list of references to help you when you run into a problem with Secure Shell.Click here for the contents of this section.
Before going to anyone for support, please read the FAQ (this document :-) and any of the whitepapers that may help you at SSH Communications Security at http://www.ssh.fi/sshprotocols2/.
There are other links listed below including tutorials and publications that may help you.
For the non-commercial releases of SSH (including other implementations for UNIX, Windows, etc.), please use the ssh maliing list for support. No support for the non-commercial release of SSH is provided by SSH Communications Security because of the licensing agreement with Datafellows.
If you are using the non-commercial release of SSH as an evaluation before purchasing, please contact Datafellows directly.
Even though SSH does not provide support for the non-commercial release, you can always ask the nice people on the SSH mailing list for help. :-)
Contact Datafellows directly. They have the exclusive license to the commercial SSH releases.
SSH Communications Security develops the SSH technology along with IPSec toolkits. However, Datafellows has licensing rights to sell and support SSH. SSH Communications Security does not provide support for SSH; however, SSH Communications Security does develeop the technology--so bug reports are welcome.
If these resources don't help, you can post to the Usenet newsgroup comp.security.ssh or send mail to the gatewayed mailing list for ssh users at ssh@clinet.fi. To subscribe, send mail to majordomo@clinet.fi with
subscribe ssh
in the body of the message.
Before subscribing, you might like to take a look at the archives of the mailing list, at
There are at least (if you know of any others, let me know) two decent user level tutorials available on the web:
There are some web pages on various aspects of SSH. Here are the ones I have:
There are two articles in SunWorld by Steve Acheson on SSH:
There is a book out on Secure Shell (both SSH1 and SSH2), UNIX Secure Shell, ISBN 0071349332 by Anne Carasik, available from McGraw-Hill Publishing. For those outside of the United States, the book is available without the CD-ROM. I hate the US crypto laws.. :-(
This section covers some miscellaneous things about Secure Shell.Click here for the contents of this section.
No; you should keep it turned on, for security reasons.
Today's CPUs are fast enough that performance losses (if any) only are noticable for local Ethernet speeds, or faster.
You might want to specify blowfish encryption instead of the default, IDEA for SSH1 and 3DES for SSH2, with -c blowfish, for faster operation.
Following are some measurements where the different encryption methods were applied between a P5/90 and a 486/100, both running Linux, for copying files with scp across a lightly loaded Ethernet.
The model chosen was t=a+x/b; a is the startup time in seconds, and b the sustainable transfer rate in kB/s. Also given are the 68.3% confidence intervals for the data, as determined by the Levenberg-Marquardt algorithm as implemented a pre-3.6 version of gnuplot.
Encryption a[s] da[s] b[kB/s] db[kB/s] none 2.37 0.37 386.1 5.8 rc4 1.96 0.27 318.2 2.9 tss 2.33 0.37 298.5 3.5 des 2.07 0.19 218.8 1.0 idea 2.25 0.45 169.6 1.3 3des 1.92 0.11 118.2 0.2
Across a heavily loaded Ethernet, rc4 encryption together with compression may actually be faster than using rcp.
The good news is the protocols ssh uses are freely available. There are no restrictions if anybody wants to write a version that is available under different conditions and is interoperable with existing SSH installations.
Secure Shell 2 is also on the Internet Standards Track. This means that a second, independent implementation is required. The only other current SSH2 implementation is lsh. Look at www.lysator.liu.se/~nisse/archive/ for more information.
You will have to be aware of patents, like RSA and IDEA, and export control issues before writing a second implementation.
Maintainer's note: This will probably be moved to another section in the FAQ later on...
Here is a simple script by Ross Golder to make using ssh more transparent. When you first login (open an Xterm etc.), you'll be prompted for your passphrase. After that, it will automatically configure your environment to the ssh-agent it started.
When logging out of a multi-user machine, I just use a 'killall ssh-agent' (not as root!).
Install the following file as $HOME/.ssh/setup and set the execute permission (chmod 700 setup), and add a call to it in your $HOME/.bashrc.
#!/bin/sh
# Checks for current ssh agent, otherwise starts one.
# For bash and ksh users:
#
# include the following in your ~/.bashrc or ~/.kshrc or ~/.profile
#
# . $HOME/.ssh/setup
#
# For csh and tcsh users:
#
# include the following in your ~/.cshrc or ~/.tcshrc
#
# source $HOME/.ssh/setup
#
SSH_ENV=$HOME/.ssh/environment
function start_agent {
echo "Initialising new SSH agent..."
ssh-agent ${SSH_ENV}
chmod 600 ${SSH_ENV}
. ${SSH_ENV} /dev/null
ssh-add
}
# Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
. ${SSH_ENV} /dev/null
ps ${SSH_AGENT_PID} /dev/null || {
start_agent;
}
else
start_agent;
fi
There are several other secure connection or authentication bits of software about. You might want to check them out as well.