The Secure Shell (SSH) Frequently Asked Questions

0. Meta-info

1. About Secure Shell (SSH)

2. Getting SSH

3. Installing SSH

4. Running SSH

5. SSH and other applications

6. Patches for SSH

7. Troubleshooting SSH

8. Getting support for SSH

9. The ever-popular miscellaneous section

0.  Meta-questions

This sections answers general questions about this document. Click here for the contents of this section.

0.1.  Where do I get this document?

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:

0.2.  Who maintains this document?

This document is currently maintained by Anne Carasik ( and Steve Acheson (

0.3.   Where do I send questions, additions, corrections etc. about this document?

If you found a broken link, inaccurate information, or something to add, please send your corrections about the document to either Anne Carasik ( or Steve Acheson ( If you are looking for support, go here.

0.4.  Revision history

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 You can still find the original FAQ at, although it is no longer being maintained.

As for the current document:

0.5.  Legalese

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

0.6.  Credits

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.

1. About Secure Shell (SSH)

This section should answer general questions about SSH and what it does and doesn't do. Click here for the contents of this section.

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

1.2 How 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 the different implementations of Secure Shell for different operating systems.

1.3 What 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:

1.4 What encryption algorithms does SSH use?

SSH uses the following ciphers for encryption:

























SSH uses the following ciphers for authentication:






yes *




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

1.5 How does SSH authenticate?

SSH authenticates using one or more of the following:

1.6 What does SSH protect against?

Ssh protects against (again, from the README):

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.7 What 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 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.

1.8 What is the difference between SSH1 and SSH2?

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.

1.9 Who maintains SSH?

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.

1.10 Can 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.1 Licensing

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

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

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?


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.

1.10.2 Cryptography laws

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.

1.10.3 Patents on Cryptographic algorithms

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

1.11 What operating systems does SSH run on?

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.

1.12 . Shouldn't I be using only SSH2?

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.

2. Getting Secure Shell (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.

2.1. Where is the official SSH distribution and mirror sites?

If you're looking for the official release of SSH, it is listed below.

2.1.1 Offical site

The central site for distributing ssh is at the Helsinki University of Technology. The files are available via FTP at

Official releases of SSH1 are PGP-signed, with the following key ID:




User ID




Ssh distribution key <

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:




User ID




Ssh 2 Distribution Key <

2.1.2 Mirrors

Ssh is also available via anonymous ftp from the following sites:

Note that some mirrors may not have the most recent snapshots available.

2.2 How about getting other relatively free versions of SSH?

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.

2.2.1 UNIX

Niels Möller is developing a GPL'd C implementation of the ssh version 2 protocol. Pick up the latest release at

Most recently, OpenBSD has also created a free SSH implementation of SSH1. You can find it at You can get the Linux port at say that after someone installs OpenBSD, they immediately install SSH afterward. Very cool.

2.2.2 Java

There are a couple of different Java implementations of SSH.

2.2.3 Windows

For some reason, a lot of people have created SSH ports to Windows :-). This is the current list of Windows ports.

2.2.4 Macintosh

NiftyTelnet 1.1 SSH is Jonas Wallden's implementation of SSH1 for Macintosh. It is available at

2.2.5 OpenVMS

There is David Jones' OpenVMS SSH1 server available at The OpenVMS SSH1 client is done by Christer Weinigel and Richard Levitte and is available at

2.2.6 Handheld devices

The ISAAC group released a version of the SSH1 client for the Palm Pilot, Top Gun ssh 1.2. It's available at

Mov Software has released a port of SSH1 to WindowsCE called sshCE. You can register for beta testing at

2.2.7 BeOS

The current BeOS R4 port of SSH1 for Intel and PowerPC platforms is available through Be directly at

2.2.8 OS/2

The most current port of the SSH1 client to OS/2 is available at, which runs on OS/2 Warp 3+.

2.3 How about getting commerically supported versions of SSH?

There are two current commercial releases of SSH. They are sold by Datafellows and Van Dyke Software.

2.3.1 Datafellows F-Secure Tunnel and Terminal

F-Secure Tunnel and Terminal is available at 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.

2.3.2 Van Dyke Software SecureCRT

SecureCRT is available at It runs on Windows platforms and supports the SSH1 and SSH2 protocol. Please contact Van Dyke directly for more information.

3. Installing Secure Shell (SSH)

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.

3.1. What is the latest version of SSH?

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.

3.2. How do I install SSH?

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.).

3.3 Does it make sense to install SSH as a non-root user on UNIX?

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.

3.4 Where do I get pre-compiled binaries for SSH?

Solaris 2.6, 2.7:

4. Running Secure Shell (SSH)

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.

4.1. How do I run SSH1?

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 :-).

4.1.1 ssh1

To use ssh1 to login to a computer with the same username:

$ ssh

To use ssh1 to login to a computer with a different username:

$ ssh -l username

To use ssh1 to securely send a command to a remote system:

$ ssh 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.

4.1.2 scp1

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.

4.1.3 sshd1

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.

4.1.4 ssh-agent1

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.

4.1.5 ssh-add1

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.

4.2. How do I run SSH2?

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.

4.2.1 ssh2

In ssh2, it uses similar syntax that ssh1 uses. To use ssh2 to login to a computer with the same username:

$ ssh2

To use ssh2 to login to a computer with a different username:

$ ssh2 -l username

To use ssh2 to securely send a command to a remote system:

$ ssh2 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.

4.2.2 scp2

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.

4.2.3 sshd2

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.

4.2.4 ssh-agent2

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.

4.2.5 ssh-add2

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.

4.2.6 sftp2

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.

4.3. How do I administer SSH after I have the daemon running?

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 (distributed with the ssh source distribution) or with the much faster ssh-keyscan, from

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

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).

5. Secure Shell and other applications

This section gives you some information on how getting Secure Shell to work with other applications. Click here for the contents of this section.

5.1. Can I run backups over ssh?

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

You can also use rdist and rsync, which there is more information at below.

5.2. Can I use ssh to communicate across a firewall?

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

5.3. Can I use rdist or rsync with ssh?


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);

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 You can use the --rsh=/usr/local/bin/ssh option to use SSH as a transport.

5.4. Can I use ssh to securely connect two subnets across the Internet?

You can run PPP over a regular ssh connection. See 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 .

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 The vpnstarter is more reliable (and easier to set up) than ssh-ppp.

5.5. Can I use ssh to securely forward UDP-based services, such as NFS or NIS?

There is a general working solution for RPC-based services, such as NIS. You can download it from . 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.

5.6. Can I use ssh to protect services like ftp or POP?

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 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 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
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 ( 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 .

Other services could be secured by similar means. Note, however, that unencrypted ftp data connections are still vulnerable to session hijacking and snooping.

5.7. Can I use ssh across a Socks firewall?

Socks 4 and 5 support should work in 1.2.16 or later. Socks support in version 2.0.11 and later should work.

5.8. Is there ssh support for AFS/Kerberos?

There's two patches available for AFS in SSH:

5.9. Can I use TCP wrappers for added security on 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:

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.

5.10. How do I tunnel X through SSH?

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.

5.11. Can I forward SGI GL connections over ssh?

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.

5.12. Does SSH support digital certificates?

No, not currently. As digital certificates become more popular, SSH will probably support digital certificates in the future.

5.13. Does SSH work with PGP keys?

Only in SSH2. It's supported in release 2.0.13 or later.

6. Patches for Secure Shell

This section gives you information on how to get and apply patches for Secure Shell. Click here for the contents of this section.

6.1. Applying patches for SSH

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.

6.2. Official patch distribution from SSH Communications Security

The official location for recent patches to SSH1 and SSH2 is available from You can get older patches for SSH1 and SSH2 at

6.3. Other patch distributions

James Barlow  maintains a repository for ssh patches at:

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."

7. Troubleshooting Secure Shell

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.

7.1. Common compiling problems

This section goes over compiling problems that may affect any platform.

7.1.1 Compiling fails with some error messages from the assembler.

For some operating systems, there are bugs in the gmp assembler routines. Try:

# make distclean
# configure --disable-asm
# make
# make install

to compile.

7.1.2 The configure process cannot find xauth!

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.

7.2. General troubleshooting tips

This section covers some of the problems with running SSH that are not operating system dependent.

7.2.1 SSH is doing wrong things for multi-homed hosts!

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).

7.2.2 Ssh asks me for passwords despite .rhosts!

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.

7.2.3 Why does ssh loop with "Secure connection refused'?

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.

7.2.4 ssh hangs when forwarding multiple TCP connections.

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.

7.2.5 I still see cleartext packages on the net when I run ssh!

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).

7.2.6 I have problems with RSAREF, something to do with too many bits!

This is a limitation in the RSAREF library. You should set a host key with at most 896 bits.

7.2.7 Connections are forwarded as root by ssh!

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.

7.3. X11 Forwarding problems

This section goes over some known problems with forwarding X traffic through SSH.

7.3.1 ssh otherhosh xclient & does not work

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.

7.3.2 ssh-agent does not work with rxvt!

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 for Timo Rinne's rxvt patch.

7.3.3 X authorization always fails.

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

7.3.4 What does Warning: remote host denied X11 forwarding mean?

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.

7.4. Linux

This section goes over some known problems with SSH on Linux systems.

7.4.1 X11 forwarding does not work for an SCO binary with the iBCS2 emulator under Linux.

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.

7.4.2 On Linux, compilation aborts with some error message about

This is an incorrectly configured Linux system; do a "cd /usr/lib; ln -s" as root to remedy this.

7.5. Solaris

This section goes over some known problems with SSH on Solaris systems.

7.5.1 Compiling with Solaris 2.5 fails!

Set the CPP environment variable to "cc -E -Xs" before running configure.

7.5.2 Ssh fails with "Resource temporarily unavailable" for Solaris

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.

7.5.3 Sshd hangs under Solaris 2.5!

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.

7.5.4 ssh-keygen dumps core on Solaris or SunOS

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.

7.6. Other operating systems

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.

7.6.1 ssh-keygen dumps core on Alpha OSF!

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.

7.6.2 On HP-UX 9, X authorization sometimes fails.

This is believed to be a bug in HP-UX 9 xauth, SR 5003209619. Patch PHSS_5568 is believed to fix this problem.

7.6.3 Userid swapping is broken under AIX!

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.

8. Getting support for Secure Shell

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.

8.1. Who provides support for SSH?

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

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.

8.1.1. What groups can help me with the "free" versions?

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. :-)

8.1.2. How can I get commercial support for UNIX SSH?

Contact Datafellows directly. They have the exclusive license to the commercial SSH releases.

8.2. So, I'm confused. If Datafellows sells Secure Shell, what does SSH Communications Security do?

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.

8.3. SSH Mailing list

If these resources don't help, you can post to the Usenet newsgroup or send mail to the gatewayed mailing list for ssh users at To subscribe, send mail to 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

8.4. Tutorials

There are at least (if you know of any others, let me know) two decent user level tutorials available on the web:

8.5. Web pages

There are some web pages on various aspects of SSH. Here are the ones I have:

8.6. Publications

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.. :-(

9. The ever-popular miscellaneous section

This section covers some miscellaneous things about Secure Shell.Click here for the contents of this section.

9.1. Should I turn encryption off, for performance reasons?

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.

9.2. Known security bugs with SSH

9.3 I don't like the commercial aspects of ssh.

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 for more information.

You will have to be aware of patents, like RSA and IDEA, and export control issues before writing a second implementation.

9.4 Making SSH more transparent to users

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.


# 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


function start_agent {
	echo "Initialising new SSH agent..."
	ssh-agent  ${SSH_ENV}
	chmod 600 ${SSH_ENV}
	. ${SSH_ENV}  /dev/null

# Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
	. ${SSH_ENV}  /dev/null
	ps ${SSH_AGENT_PID}  /dev/null || {

9.5 Alternatives to SSH

There are several other secure connection or authentication bits of software about.  You might want to check them out as well.

Last updated: 4 November 1999. Maintainers - and