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 install
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.
This section covers some of the problems with running Secure Shell 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
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
~/.ssh/authorized_keys on the server side.
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/rshwhich 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
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 Secure Shell.
No, it doesn't. Use "ssh -f otherhost xclient" instead, or "ssh
-n otherhost xclient &" if you want a script to be compatible
rxvt closes all file descriptors when starting up, including the one used
by ssh-agent. Use xterm, or look at the mailing list archives
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 Secure Shell 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 section goes over some known problems with Secure Shell on Solaris systems.
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.
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 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.
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.
| Table of contents of this chapter | | General table of contents | | Beginning of this section |