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.

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]

A:

Your server’s idle timeout value may be too short. If you are a system administrator of a Tectia server machine, set IdleTimeout to a larger value in the serverwide configuration file. [5.3.3.5] If you are an end user of OpenSSH, set an idle-timeout value in authorized_keys. [8.2.7]

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 (PasswordAuthentication yes for OpenSSH, AllowedAuthentications password for Tectia). Also check your client configuration file to make sure you don’t have PasswordAuthentication no.

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 [email protected]:

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 User keyword. In particular, if your configuration file contains Host values with wildcards, check that your current command line (the one that isn’t working) isn’t matching the wrong section in the file. [7.1.2.4]

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/sshd

If OpenSSH isn’t using PAM, and password authentication still isn’t working, the compilation options --with-md5-passwords or --without-shadow might be relevant. These make no difference if PAM support is enabled in OpenSSH, because they deal with how OpenSSH reads the Unix passwd map. When using PAM, the OpenSSH code doesn’t read the passwd map directly; the PAM libraries do it instead. Without PAM, though, if your system is using MD5-hashed passwords instead of the more traditional crypt (DES) hash, you must use --with-md5-passwords. You can tell which hash your system is using by inspecting the /etc/passwd and /etc/shadow files. The hashed password is the second field in each entry; if the password field in /etc/passwd is just “x”, then the real entry is in /etc/shadow instead. MD5 hashes are much longer and contain a wider range of characters:

    # /etc/shadow, MD5 hash
    test:$1$tEMXcnZB$rDEZbQXJzUz4g2J4qYkRh.:...

    # /etc/shadow, crypt hash
    test:JGQfZ8DeroV22:...

Finally, you can try the compilation option --without-shadow if you suspect OpenSSH is trying to use the shadow password file, but your system doesn’t use it.

A:

Empty passwords are insecure and should be avoided. Nevertheless, you can set PermitEmptyPasswords yes in the serverwide configuration file. [5.4.2.2]

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:

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.

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, Key mykey.pub.

A:

Invoke the client in debug mode (ssh -v). Make sure:

A:

There are several possible causes for both of these problems:

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.

A:

ssh-add can communicate with ssh-agent only if certain environment variables are set. These variables--SSH_AUTH_SOCK for OpenSSH and SSH2_AUTH_SOCK for Tectia—direct ssh-add to the socket used by ssh-agent. The environment variables are set automatically if you run the agent correctly. [6.3.2] This implies that any shells run before ssh-agent won’t know how to contact it.

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

If 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 SSH_AUTH_SOCK variable. If you do see the socket variable, then perhaps it has an old value (from a previously run and now-dead agent). Try opening a new shell and running ssh-add.

A:

If you get prompted for your PGP key, and then your password:

  Passphrase for pgp key "mykey": ********
  smith's password:

first make sure you’re typing your PGP passphrase correctly. (For instance, PGP-encrypt a file with that public key and decrypt it.) If so, then there might be an incompatibility between the PGP implementations on your client and server machines. We’ve seen this behavior when the PGP key (generated on the client machine) doesn’t have sufficient bits for the PGP implementation on the server machine. Generate a new key on the server machine.

A:

You probably forgot the leading “0x” on the key ID, and SSH is trying to interpret a hexadecimal number as a decimal. Use PgpKeyId 0x0276C297 instead.

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]

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.

A:

Yes. For ssh-keygen in OpenSSH, use the -N option, and for Tectia use the -p option.

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 directory_containing_source_code
    # make host-key            Will not overwrite existing keys
    # make host-key-force      Will overwrite existing keys

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 directory_containing_source_code
    # make generate-host-key    Will not overwrite existing key

or you can do it manually:

    # ssh-keygen -P -t dsa -c "DSA hostkey" /etc/ssh2/hostkey

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.

A:

We recommend at least 1024 bits for strong security.

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.

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]

A:

Follow this debugging process:

A:

Check the following:

A:

You can terminate and restart sshd, but there’s quicker way: send the “hangup” signal (SIGHUP) to sshd with kill -HUP.

A:

sshd may have been invoked with a command-line option that overrides that keyword. Command-line options remain in force and take precedence over configuration-file keywords. Try terminating and restarting sshd.

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.

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 Host lines match the remote machine name you specified on the command line.

A:

Remember that after the first use of a Host directive in the config file, all statements are inside some Host block (because one Host block is terminated only by the start of another). The ssh manpage suggests that you put defaults at the end of the config file, which is correct; when looking up a directive in the config file, ssh uses the first match it finds, so defaults should go after any Host blocks. But don’t let your own indentation or whitespace fool you. The end of your file might look like this:

    # last Host block
    Host server.example.com
     User linda

    # defaults
    User smith

You 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 User smith is still inside the Host server.example.com block. And since there’s an earlier User statement for server.example.com, User smith never matches anything, and ssh appears to ignore it. The right thing to do is this:

    # last Host block
    Host server.example.com
     User linda

    # defaults
    Host *
     User smith

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.

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 n th one by pressing the Return key, then n tildes, then Control-Z.

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]

A:

Your CompressionLevel is set to an illegal value for this host, probably in your ~/.ssh/config file. It must be an integer between 1 and 9, inclusive. [7.4.14]

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

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

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.

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 Cipher keyword in the configuration file. Either don’t specify a cipher and let the client and server work it out, or select a different cipher.

A:

ssh has a static limit of 100 forwardings per session, and you’ve requested more.

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

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 "-" (for a regular file) or “d” (for a directory), this is probably what’s happening. You didn’t really want to copy that file, did you?

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 server.example.com:a*. This is probably not what you intended. You probably wanted files matching a* on server.example.com to be copied to the local machine.

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 server.example.com:a* to the server as you’d hoped.

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. $MAIL is expanded locally before scp executes. Unless (by coincidence) $MAIL is the same on the local and remote machines, the command won’t behave as expected.

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

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

myfile gets copied locally to a file called "server.example.com“. Check for such a file on the local machine.

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 [email protected]:.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]

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

A:

Don’t use scp for this purpose. There are better ways, with tar:

    # tar cpf - local_dir | (ssh remote_machine "cd remote_dir; tar xpf -")

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.

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.

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 $interactive if stdin is a terminal.

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 LISTEN state, you know that something else is using that port. Check to see whether you’ve inadvertently left another ssh command running that’s forwarding the same port. Otherwise, just choose another, unused port to forward.

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 TIME_WAIT state (you may see this if you used the netstat program as described earlier). When this happens, you have to wait a few minutes for the socket to time out of this state and become free for use again. Of course, you can just choose another port number if you’re impatient.

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 2001

Your FTP client probably needs to run in passive mode (execute the passive command). FTP data connections carry the files being transferred. These connections occur on randomly selected TCP ports and can’t be forwarded in general, unless you enjoy pain. If firewalls or NAT (network address translation) are involved, you may need additional steps (or it may not be possible).

A:

Use ssh -v, and see if the output points out an obvious problem. If not, check the following: