A: Maybe they are SSH2 programs when you are expecting SSH1, or vice versa. Locate the executables and do an ls -l. If they are plain files, they are most likely from SSH1 or OpenSSH. If they are symbolic links, check whether they point to SSH1 or SSH2 files. (SSH2 files have names ending in "2".)

Q: When I try to connect to an SSH server, I get the error "Connection refused."

A: No SSH server is running where you tried to connect. Double-check the hostname and TCP port number: perhaps the server is running on a port different from the default?

Q: When I log in, the message of the day (/etc/motd) prints twice.

Q: When I log in, I see two messages about email, such as "No mail" or "You have mail."

Q: The SSH1 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:

• Public-key with ssh-agent

• Public-key with an unencrypted key on disk (empty passphrase)

• Trusted-host

• Kerberos (SSH1 and OpenSSH/1 only)

Automatic authentication has a number of important issues you should carefully consider before selecting from the preceding list.

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 the server machine, set IdleTimeout to a larger value in the serverwide configuration file. If you are an end user of SSH1 or OpenSSH, set an idle-timeout value in authorized_keys.

Q: RequiredAuthentications doesn't work.

A: This feature was broken in SSH2 2.0.13, causing authentication always to fail. This problem was fixed in 2.1.0.

Q: SilentDeny doesn't seem to work for any authentication method.

A: SilentDeny has nothing to do with authentication. It applies only to access control using AllowHosts and DenyHosts. If a connection is denied access by an AllowHosts or DenyHosts value, SilentDeny controls whether the client sees an informative failure message or not.

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 (PasswordAuthentication yes for SSH1 and OpenSSH, AllowedAuthentications password for SSH2). 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? If so, 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 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.

# 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 switches --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", 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 --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.

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.

Q: For SSH1 and OpenSSH/1

A: The SSH client program must be setuid root.

RhostsRSAAuthentication yes belongs in the server and client configurations.

The client's public host key must be in the server's known hosts list. In this case, hades:/etc/ssh_known_hosts must contain an entry associating the name "earth" with earth's public host key, like this:

earth 1024 37 71641647885140363140390131934...

The entry may be in the target account's known hosts file instead, i.e., in hades:~orpheus/.ssh/known_hosts. Take care that "earth" is the canonical name of the client host from the server's point of view. That is, if the SSH connection is coming from the address 192.168.10.1, gethostbyname(192.168.10.1) on hades must return "earth", not a nickname or alias for the host (e.g., if the hostname is river.earth.net, the lookup must not return just "river"). Note that this can involve multiple naming services, since gethostbyname can be configured to consult multiple sources to determine a translation (e.g., DNS, NIS, /etc/hosts). See /etc/nsswitch.conf. If your systems don't agree on canonical hostnames, you'll have no end of trouble with RhostsRSA. You can work around such problems to an extent by manually adding extra host nicknames to the known hosts file, like this:

earth,gaia,terra 1024 37 71641647885140363140390131934...

Edit hades:/etc/shosts.equiv or hades:~orpheus/.shosts to allow the login. Adding earth to shosts.equiv allows any nonroot user on earth to access the account by the same name on hades. Adding earth to .shosts allows orpheus@earth to access orpheus@hades.

Some firewalls reject outbound connections from privileged ports. This prevents RhostsRSA authentication from working, since it relies on privileged source ports. You can use ssh -P to get a connection to the SSH server via a nonprivileged port, but you will have to use a different kind of authentication.

Q: For SSH2

A: AllowedAuthentications hostbased in the server and client configurations.

ssh2 doesn't need to be setuid root, but ssh-signer2 does. More precisely, it needs to be able to read the private host key, which in the normal installation means it must be setuid root.

A copy of earth's public host key in hades:/etc/ssh2/knownhosts/earth.ssh-dss.pub (or hades:~orpheus:/.ssh2/knownhosts/earth.ssh-dss.pub, if you specified "UserKnownHosts yes" on the server).

Regarding canonical hostnames, the same comments as for RhostsRSA apply.

Q: For OpenSSH/2

A: DSAAuthentication yes belongs in the server and client configurations.

ssh must be setuid root (or otherwise able to read the client hosts's private host key in /etc/ssh_host_dsa_key ; it doesn't require a privileged source port).

A copy of earth's public host key in hades:/etc/ssh_known_hosts2 (or hades:~orpheus:/.ssh/known_hosts2).

The same comments as for RhostsRSA apply, regarding canonical hostnames.

A: Here's the general method:

1. Generate a key pair.

2. Copy the text of the public key into your computer's clipboard or other cut/paste buffer.

3. Log into the remote host via SSH with password authentication, which doesn't require any special files in your remote account.

4. Edit the appropriate authorization and key files on the remote host:

   a. For SSH1 and OpenSSH/1, append the public key to ~/.ssh/authorized_keys.

   b. For OpenSSH/2, append the public key to ~/.ssh/authorized_keys2.

   c. For SSH2, paste the public key into a new .pub file in ~/.ssh2 (say, newkey.pub), and append the line "Key newkey.pub" to ~/.ssh2/authorization.

When editing the remote authorization file, make sure your text editor doesn't insert line breaks into the middle of a public key. SSH1 and 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 SSH1 and OpenSSH/1, you must append the key (i.e., the contents of mykey.pub) to ~/.ssh/authorized_keys. For OpenSSH/2, append the key to ~/.ssh/authorized_keys2. For SSH2, you must add a line of text to ~/.ssh2/authorization, Key mykey.pub.

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

• Your local client is using the expected identity file.

• The correct public key is on the remote host in the right location.

• Your remote home directory, SSH directory, and other SSH-related files have the correct permissions.

A: There are several possible causes for both of these problems.

Public-key authentication must be enabled in both the client and server (SSH1/OpenSSH RSAAuthentication yes, SSH2 AllowedAuthentications publickey).

Specify your remote username with -l (lowercase L) if it differs from your local username, or else the SSH server will examine the wrong remote account:

$ ssh -l jones server.example.com

Check the file permissions in your server account. If certain files or directories have the wrong owner or careless access permissions, the SSH server refuses to perform public-key authentication. This is a security feature. Run ssh in verbose mode to reveal the problem:

$ ssh -v server.example.com
...
server.example.com: Remote: Bad file modes for /u/smith/.ssh

In your server account, make sure that the following files and directories are owned by you and aren't world writable: ~, ~/.ssh, ~/.ssh/authorized_keys, ~/.ssh2, ~/.rhosts, and ~/.shosts.

For SSH2, if you use the -i option to specify an identification file:

$ ssh2 -i my-identity server.example.com

check that my-identity is an identification file, not a private key file. (In contrast, ssh -i for SSH1 and OpenSSH expects a private key file.) Remember that SSH2 identification files are text files containing the names of private keys.

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.

Check for SSH agent problems. Are you running an agent and trying to specify another key with ssh -i or the IdentityFile keyword? The presence of an agent prevents -i and IdentityFile from working. Terminate your agent and try again.

For SSH1 and OpenSSH, if any options are specified in ~/.ssh/authorized_keys, check for typographical errors. A mistyped option causes the associated key line to be skipped silently. Remember that options are separated by commas, not whitespace.

Q: After the PGP passphrase prompt, I am being prompted for my login password.

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

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

and you know you're typing your passphrase correctly, first make sure you're typing your PGP passphrase correctly. (For instance, 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.

Q: I get "Invalid pgp key id number `0276C297'".

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.