In this section, we cover a wide range of difficulties, organized by category. The sidebar "The Top 10 SSH Questions" lists what, in our experience, are the most frequently asked of the frequently asked questions. We focus on problems that may occur in many versions of the SSH software on diverse operating systems. We don't address the sorts of questions shown next that rapidly become obsolete.
Compilation problems specific to one operating system, such as
"HyperLinux beta 0.98 requires the --with-woozle flag"
Problems and bugs that are specific to one version of SSH, particularly older versions
In all questions, we will assume you have already used debug or verbose mode (e.g., ssh -v) to isolate the problem. (If you haven't, you should!)
Q: | The SSH server says "Permission denied" and exits. |
A: | This occurs if all authentication techniques have failed. Run your client in debug mode and read the diagnostic messages, looking for clues. Also read our solutions to specific authentication problems in the rest of this section. |
Q: | How do I authenticate without typing a password or passphrase? |
A: | The four available authentication methods for this are:
Automatic authentication has a number of important issues you should carefully consider before selecting from the preceding list. Read our case study on this topic. [11.1] |
Q: | I get prompted for my password or passphrase, but before I have time to respond, the SSH server closes the connection. |
A: | Your server's idle timeout value may be too short. If
you are a system administrator of a Tectia server machine, set
|
Q: | Password authentication isn't working. |
A: | Use ssh -v. If the connection is being refused altogether, the SSH server is probably not running, or you are connecting to the wrong port. Port 22 is the default, but the remote system administrator might have changed it. If you see "permission denied," password authentication might be disabled in the server. Make sure the server permits password authentication in
the serverwide configuration file ( If you are prompted for your password, but it is rejected, you might accidentally be connecting to the wrong account. Does your local username differ from the remote username? Then you must specify the remote username when connecting: $ ssh -l my_remote_username server.example.com
$ scp myfile my_remote_username@server.example.com:If this still doesn't work, check your local client
configuration file (~/.ssh/config or ~/.ssh2/ssh2_config) to make sure
you haven't accidentally set the wrong value for the One common problem on the server side involves OpenSSH and Pluggable Authentication Modules configuration. PAM is a general system for performing authentication, authorization, and accounting in an application-independent fashion. If your operating system supports PAM (as Linux and HPUX do, for example), OpenSSH will probably have been automatically compiled to use it. Unless you take the extra step of configuring PAM to support SSH, all password authentication will mysteriously fail. This is usually just a matter of copying the appropriate sshd.pam file from the contrib directory in the OpenSSH distribution, naming the copy "sshd," and placing it in the PAM configuration directory (usually /etc/pam.d). The contrib directory contains several example files for different flavors of Unix. For example, on a Red Hat Linux system: # cp contrib/redhat/sshd.pam /etc/pam.d/sshd
# chown root.root /etc/pam.d/sshd
# chmod 644 /etc/pam.d/sshdIf OpenSSH isn't using PAM, and password authentication
still isn't working, the compilation options # /etc/shadow, MD5 hash
test:$1$tEMXcnZB$rDEZbQXJzUz4g2J4qYkRh.:...
# /etc/shadow, crypt hash
test:JGQfZ8DeroV22:...Finally, you can try the compilation option |
Q: | The server won't let me use an empty password. |
A: | Empty passwords are insecure and should be avoided.
Nevertheless, you can set |
Q: | Hostbased authentication isn't working. |
A: | Use ssh -v. If everything looks right, check the following. Suppose the client user is orpheus@earth, and the target account is orpheus@hades--that is, on host earth, user orpheus invokes ssh hades. For OpenSSH:
For Tectia:
|
Q: | How do I install my public key file on the remote host the first time? |
A: | Here's the general method:
When editing the remote authorization file, make sure your text editor doesn't insert line breaks into the middle of a public key. OpenSSH public keys are very long and must be kept on a single line. |
Q: | I put my SSH public-key file, mykey.pub, into my remote SSH directory, but public-key authentication doesn't work. |
A: | Placing a valid public-key file (e.g., mykey.pub) in your SSH directory
isn't sufficient. For OpenSSH you must append the key (i.e.,
the contents of mykey.pub) to ~/.ssh/authorized_keys. For Tectia,
you must add a line of text to ~/.ssh2/authorization, |
Q: | Public-key authentication isn't working. |
A: | Invoke the client in debug mode (ssh -v). Make sure:
|
Q: | I'm being prompted for my login password instead of my public-key passphrase. Or, my connection is rejected with the error message "No further authentication methods available." (Tectia) |
A: | There are several possible causes for both of these problems:
|
Q: | I'm being prompted for the passphrase of the wrong key. |
A: | Make sure your desired public key is in your authorization file on the SSH server machine. Also check for typographical errors in any options specified for the key. [8.2] A mistyped option causes the associated key line to be skipped silently. Remember that options are separated by commas, not whitespace. |
Q: | I ran ssh-agent, but when I run ssh-add to add keys, it cannot find the agent. |
A: | ssh-add can communicate with
ssh-agent only if certain environment
variables are set. These variables-- In the shell where you're running the failed ssh-add, check for the presence of the appropriate environment variable: $ env | grep SSH
SSH_AGENT_PID=7206
SSH_AUTH_SOCK=/tmp/ssh-gckksA7161/agent.7161If you don't see it, then either you didn't run the
agent correctly, you ran this shell before you ran
ssh-agent, or you're not properly
exporting the |
Q: | I generated an OpenSSH key and tried using it with Tectia, but it didn't work. (Or vice versa.) |
A: | This is normal. OpenSSH and Tectia (SECSH) keys aren't compatible. However, you can convert one to the other with ssh-keygen. [6.2.1] |
Q: | Each time I run ssh-keygen, it overwrites my default identity file. |
A: | Tell ssh-keygen to write its output to a different file. For ssh-keygen in OpenSSH, use the -f option. For Tectia, specify the filename as the last argument on the command line; no option is needed. |
Q: | Can I change the passphrase for a key without regenerating the key? |
A: | Yes. For ssh-keygen in OpenSSH, use the -N option, and for Tectia use the -p option. |
Q: | How do I generate a host key? |
A: | Generate a key with an empty passphrase and install it in the correct location. The OpenSSH source distribution has a Makefile target to do this: # cd or you can do it manually: # ssh-keygen -t rsa1 -f /usr/local/etc/ssh_host_key -N ""
# ssh-keygen -t dsa -f /usr/local/etc/ssh_host_dsa_key -N ""
# ssh-keygen -t rsa -f /usr/local/etc/ssh_host_rsa_key -N ""Likewise, the Tectia source distribution has a Makefile target: # cd or you can do it manually: # ssh-keygen -P -t dsa -c "DSA hostkey" /etc/ssh2/hostkey |
Q: | Generating a key takes a long time. |
A: | Yes it may, depending on the speed of your CPU and the number of bits you have requested. DSA keys tend to take longer than RSA keys. |
Q: | How many bits should I make my keys? |
A: | We recommend at least 1024 bits for strong security. |
Q: | What does oOo.oOo.oOo.oOo mean, as printed by Tectia's ssh-keygen? |
A: | The manpage calls it a "progress indicator." We think it's an ASCII representation of a sine wave. Or the sound of a chattering gorilla. You can hide it with the -q flag. |
Q: | My ssh-agent isn't terminating after I log out. |
A: | If you use the single-shell method to start an agent, this is normal. You must terminate the agent yourself, either manually (bleah) or by including appropriate lines in your shell configuration files. [6.3.2.1] If you use the subshell method, the agent automatically terminates when you log out (actually, when you exit the subshell). [6.3.2.2] |
Q: | When I invoke ssh-add and type my passphrase, I get the error message "Could not open a connection to your authentication agent." |
A: | Follow this debugging process:
|
Q: | A feature of ssh or scp isn't working, but I'm sure I'm using it correctly. |
A: | The feature might have been disabled by a system administrator, either when the SSH software was compiled (Chapter 4) or during serverwide configuration (Chapter 5). Compile-time flags cannot be checked easily, but serverwide configurations are found in the files /etc/ssh/sshd_config (OpenSSH) or /etc/ssh2/sshd2_config (Tectia). Ask your system administrator for assistance. |
Q: | ssh or scp is behaving unexpectedly, using features I didn't request. |
A: | The program might be responding to keywords specified in
your client configuration file. [7.1.2] Remember that
multiple sections of the config file apply if multiple
|
Q: | My OpenSSH ~/.ssh/config file doesn't seem to work right. |
A: | Remember that after the first use of a # last Host block
Host server.example.com
User linda
# defaults
User smithYou intend that the username for logging into
server.example.com is "linda", and the
default username for hosts not explicitly listed earlier is
"smith". However, the line # last Host block
Host server.example.com
User linda
# defaults
Host *
User smith |
Q: | My Tectia ~/.ssh2/ssh2_config file doesn't seem to work right. |
A: | See our answer to the previous question for OpenSSH. However, Tectia has the opposite precedence rule: if multiple configurations match your target, then the last, not the first, prevails. Therefore, your defaults go at the beginning of the file. |
Q: | I want to suspend ssh with the escape sequence but I am running more than two levels of ssh (machine to machine to machine). How do I suspend an intermediate ssh? |
A: | One method is to start each ssh with a different escape character; otherwise, the earliest ssh client in the chain interprets the escape character and suspends. Or you can be clever. Remember that if you type the
escape character twice, that's the meta-escape: it allows you
to send the escape character itself, circumventing its usual
special function. So, if you have several chained
ssh sessions all using the default escape
character ~, you can suspend the |
Q: | I ran an ssh command in the background on the command line, and it suspended itself, not running unless I "fg" it. |
A: | Use the -n command-line option, which instructs ssh not to read from stdin (actually, it reopens stdin on /dev/null instead of your terminal). Otherwise, the shell's job-control facility suspends the program if it reads from stdin while in the background. Or better: use ssh -f (possibly with -N). [9.2.6] |
Q: | ssh prints "Compression level must be from 1 (fast) to 9 (slow, best)" and exits. |
A: | Your |
Q: | ssh prints "Cannot fork into background without a command to execute" and exits. |
A: | You used the -f flag of ssh, didn't you? This tells the client to put itself into the background as soon as authentication completes, and then execute whatever remote command you requested. But, you didn't provide a remote command. You typed something like: # This is wrong
$ ssh -f server.example.comThe -f flag makes sense only when you give ssh a command to run after it goes into the background: $ ssh -f server.example.com /bin/who |
Q: | ssh prints "No host key is known for <server name> and you have requested strict checking (or 'cannot confirm operation when running in batch mode')," and exits. |
A: | The client can't find the server's host key in its known-hosts list, and it is configured not to add it automatically (or is running in batch mode, so it can't prompt you about adding it). You must add it manually to your per-account or systemwide known-hosts files. |
Q: | ssh prints "Selected cipher type...not supported by server" and exits. |
A: | You requested that ssh use a
particular encryption cipher, but the SSH server doesn't
support it. Normally, the SSH client and server negotiate to
determine which cipher to use, so you probably forced a
particular cipher by providing the -c
flag on the ssh command line or by using
the |
Q: | ssh prints "channel_request_remote_forwarding: too many forwards" and exits. |
A: | ssh has a static limit of 100 forwardings per session, and you've requested more. |
Q: | scp printed an error message: "Write failed flushing stdout buffer. write stdout: Broken pipe." or "packet too long". |
A: | Your shell startup file (e.g., ~/.cshrc, ~/.bashrc), which is run when scp connects, might be writing a message on standard output. These interfere with the communication between the two scp programs. If you don't see any obvious output commands, look for stty or tset commands that might be printing something. Either remove the offending statement from the startup file, or suppress it for noninteractive sessions: if ($?prompt) then
echo 'Here is the message that screws up scp.'
endif |
Q: | scp printed an error message, "Not a regular file." |
A: | Are you trying to copy a directory? Use the
-r option for a recursive copy.
Otherwise, you may be trying to copy a special file that it
doesn't make sense to copy, such as a device node, socket, or
named pipe. If you do an ls -l of the
file in question and the first character in the file
description is something other than " |
Q: | Why don't wildcards or shell variables work on the scp command line? |
A: | Remember that wildcards and variables are expanded by the local shell first, not on the remote machine. This happens even before scp runs. So if you type: $ scp server.example.com:a* . the local shell attempts to find local files matching
the pattern Some shells, notably the C shell and its derivatives,
simply report "No match" and exit. The Bourne shell and its
derivatives (sh,
ksh, bash), finding
no match, will actually pass the string Similarly, if you want to copy your remote mail file to the local machine, the command: $ scp server.example.com:$MAIL . might not do what you intend. Don't rely on shell quirks and coincidences to get your work done. Instead, escape your wildcards and variables so that the local shell won't attempt to expand them: $ scp server.example.com:a\* .
$ scp 'server.example.com:$MAIL' . |
Q: | I used scp to copy a file from the local machine to a remote machine. It ran without errors. But when I logged into the remote machine, the file wasn't there! |
A: | By any chance, did you omit a colon? Suppose you want to copy the file myfile from the local machine to server.example.com. A correct command is: $ scp myfile server.example.com: but if you forget the final colon: # This is wrong!
$ scp myfile server.example.commyfile gets copied locally to a file called "server.example.com". Check for such a file on the local machine. |
Q: | How can I give somebody access to my account by scp to copy files, but not give full login permissions? |
A: | Bad idea. Even if you can limit the access to scp, this doesn't protect your account. Your friend could run: $ scp evil_authorized_keys you@your.host:.ssh/authorized_keys Oops, your friend has just replaced your authorized_keys file, giving himself full login permissions. Maybe you can accomplish what you want with a clever forced command, limiting the set of programs your friend may run in your account. [8.2.3.3] |
Q: | scp |
A: | No. Ownership of remote files is determined by SSH authentication. Suppose user smith has accounts on local computer L and remote computer R. If the local smith copies a file by scp to the remote smith account, authenticating by SSH, then the remote file is owned by the remote smith. If you want the file to be owned by a different remote user, scp must authenticate as that different user. scp has no other knowledge of users and uids, and besides, only root can change file ownership (on most modern Unix variants, anyway). |
Q: | OK, scp -p doesn't preserve file ownership information. But I am the superuser, and I'm trying to copy a directory hierarchy between machines (scp -r) and the files have a variety of owners. How can I preserve the ownership information in the copies? |
A: | Don't use scp for this purpose. There are better ways, with tar: # tar cpf - or rsync: # rsync -ra -e ssh local_dir remote_machine:/remote_dir The rsync method has the advantage of being interruptible and resumable without retransferring files. |
Q: | sftp reports "Cipher <name> is not supported. Connection lost." |
A: | Internally, sftp invokes an ssh command to contact sftp-server. [3.7.3] It searches the user's PATH to locate the ssh executable rather than a hardcoded location. If you have more than one SSH product installed on your system, sftp might invoke the wrong ssh program. This can produce the error message shown. |
Q: | sftp reports "ssh_packet_wrapper_input: invalid packet received." |
A: | Although this error appears mysterious, its cause is mundane. A command in the remote account's shell startup file is printing something to standard output, even though stdout isn't a terminal in this case, and sftp is trying to interpret this unexpected output as part of the SFTP packet protocol. It fails and dies. You see, sshd uses the shell to start the sftp-server subsystem. The user's shell startup file prints something, which the SFTP client tries to interpret as an SFTP protocol packet. This fails, and the client exits with the error message; the first field in a packet is the length field, which is why it's always that message. To fix this problem, be sure your shell startup file
doesn't print anything unless it's running interactively.
tcsh, for example, sets the variable
|
Q: | I'm trying to do port forwarding, but ssh complains: "bind: Address already in use." |
A: | The port you're trying to forward is already being used
by another program on the listening side (the local host if
it's a -L forwarding or the remote host
if it's a -R). Try using the
netstat -a command, available on most
Unix implementations and some Windows platforms. If you see an
entry for your port in the This problem can occur when there doesn't appear to be
any other program using your port, especially if you've been
experimenting with the forwarding feature and have repeatedly
used the same ssh to forward the same
port. If the last one of these died unexpectedly (you
interrupted it, or it crashed, or the connection was forcibly
closed from the other side, etc.), the local TCP socket may
have been left in the |
Q: | How do I secure FTP with port forwarding? |
A: | This is a complex topic. [11.2] FTP has two types of TCP connections: control and data. The control connection carries your login name, password, and FTP commands; it is on TCP port 21 and can be forwarded by the standard method. In two windows, run: $ ssh -L2001:name.of.server.com:21 name.of.server.com
$ ftp localhost 2001Your FTP client probably needs to run in passive mode
(execute the |
Q: | X forwarding isn't working. |
A: | Use ssh -v, and see if the output points out an obvious problem. If not, check the following:
|