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

Another option is to ./configure --without-x.
7.1.3 The configure process cannot find nm"

Under Solaris, the directory /usr/ccs/bin should be in your PATH.

7.2. General troubleshooting tips

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

7.2.1 Secure Shell 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

The remote hosts's /etc/ssh_known_hosts is not world readable.
The client host key is not stored in the known_hosts file. Note that this has to be the canonical (usually, the fully qualified) domain name.
The client host does not have a reverse mapping in the name servers. Note that ssh requires that it has both a reverse mapping, and a forward mapping that contains the original IP address.
A multi-homed client or host does not have all of its IP addresses listed in the DNS entry. Note that versions prior to 1.2.12 have bugs in handling multi-homed hosts.
User's home directory or ~/.rhosts is world or group-writable (see StrictModes server configuration option).
On some machines, if the home directory is on an NFS volume, ~/.rhosts and your home directory may need to be world-readable.
The root account has to use ~/.rhosts or ~/.shosts; /etc/shosts.equiv and /etc/hosts.equiv are disregarded for root.
Confusion between RhostsRSAAuthentication and RSAAuthentication.

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:

You probably have installed ssh as rsh, and forgotten to give the --with-rsh=PATH option to configure the second time. When ssh is looking for rsh, it keeps executing itself (or an older version of itself). To solve this, recompile ssh with the correct place for rsh.
You moved the old rsh and rlogin into a different directory and correctly are calling the old rsh. The old rsh has a hard-coded path to the old rlogin program, so you wind up execing the old rsh which in turn execs the new replacement (ssh)rlogin.

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.2.8 Why do I get a connection refused message?

Your ssh daemon is likely not running (or unreachable through a firewall). try telnet hostname 22 and see if Secure Shell answers. Also, make sure that the ssh daemon is started by your system's startup scripts, or else the daemon will not automatically start when the system is rebooted.

7.3. X11 Forwarding problems

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

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 http://www.cs.hut.fi/ssh/ssh-archive/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 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.

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 Secure Shell 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 libc.so.4

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

7.5. Solaris

This section goes over some known problems with Secure Shell 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.5.5 I can't get TCP wrappers to work under Solaris

Some known bugs in Secure Shell and Solaris:

Hostbased authentication does not work under Solaris is TCP wrappers are used with an Secure Shell implementation before 2.1.0.pl2 (the connection hangs)
TCP wrappers do not work at all wtih SSH2 under Solaris 2.5.1 (the connection hangs)

7.6. Other operating systems

This section goes over some known problems with Secure Shell 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.

| Previous Chapter | | Next Chapter |