Several things can go wrong when setting up an SSH server and client. If you cannot login to the SSH server, you should set the debug level to DEBUG (see SSH Configuration) on the server and use the -vvv option on the SSH client command line to troubleshoot the problem. Let's troubleshoot a couple of common issues.
$ ssh -vvv user@192.168.0.102
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.102 [192.168.0.102] port 22.
debug1: Connection established.
[...]
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3The client SSH version is 4.3p2, the server version is 4.3. The client was able to reach the server:
debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 [...] debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c tr,aes192-ctr,aes256-ctr [...] debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 128/256 debug2: bits set: 503/1024
The client and the server successfully negotiated the protocol version, the ciphers to use for the session key, the compression algorithm, and the data integrity algorithms:
debug3: check_host_in_hostfile: filename /cygdrive/c/Documents and Settings/jsob rier/.ssh/known_hosts debug3: check_host_in_hostfile: match line 30 debug1: Host '192.168.0.102' is known and matches the RSA host key. debug1: Found key in /cygdrive/c/Documents and Settings/jsobrier/.ssh/known_host s:30 debug1: ssh_rsa_verify: signature correct
The host was found in known_hosts, and the public key matches what was recorded the first time:
debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive [...] debug3: authmethod_is_enabled password debug1: Next authentication method: password user@192.168.0.102's password:
The authentication through public key and password were dismissed; the authentication through keyboard-interactive (using PAM) was accepted. I enter my password:
debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password).
The password was accepted by the server; I am authenticated:
[...]
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd −1/-1 cfd −1)
debug3: channel 0: close_fds r −1 w −1 e 6 c −1
Connection to 192.168.0.102 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 37 bytes in 0.5 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 72.7
debug1: Exit status 1But the channel is closed. The reason does not appear in the logs on the client side.
On the server side, the same information is logged (protocol negotiation, cipher negotiation, and authentication). We should focus on the authentication part and follow:
[root@asus ˜]# less /var/log/auth.log
[...]
Sep 1 17:56:00 asus sshd[17804]: debug1: Entering interactive session for SSH2.
[...]
Sep 1 17:56:01 asus sshd[17804]: debug1: Received SIGCHLD.The SSH server opened a new session for the user, but then received a SIGCHLD signal. This signal is sent when a child process has stopped. So, the problem is apparently not in SSH itself, but in a child process started by SSH. What is the first thing that happens when a user logs into a system? The user's environment is set up after basic information, such as the home directory and shell, are read from /etc/passwd:
user:x:501:501:emoret:/home/emoret:/bin/false
Here the shell specified for user is /bin/false, which is not a real shell. It is actually used to make sure users cannot have shell access. Often, users who have a local account to access services such as FTP, POP3, IMAP, and SMTP have a bash set to /bin/false to ensure they can never do anything on the server. This program exits instantly, hence the SIGCHLD signal received by SSH. The shell must be a real shell, such as /bin/bash.
It is very common to have the wrong file permissions on the server or on the client. In strict mode (see SSH Configuration), the permissions are verified with each new connection. If permissions are wrong before the SSH server is started, it will not start:
[root@asus ssh]# service sshd start
Starting sshd:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_key Could not load host key:
/etc/ssh/ssh_host_keyIf file permissions are changed while the server is running, this can prevent users from logging in:
$ssh -vvvjulien@192.168.0.102OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.0.102 [192.168.0.102] port 22. debug1: Connection established. [...] ssh_exchange_identification: Connection closed by remote host
The server closes the communication very early, before sending its public key. On the server, the error message indicates clearly the problem:
Sep 4 10:42:09 asus sshd[11636]: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Sep 4 10:42:09 asus sshd[11636]: error: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ Sep 4 10:42:09 asus sshd[11636]: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@ Sep 4 10:42:09 asus sshd[11636]: error: Permissions 0644 for '/etc/ssh/ssh_host _dsa_key' are too open. Sep 4 10:42:09 asus sshd[11636]: error: It is recommended that your private key files are NOT accessible by others. Sep 4 10:42:09 asus sshd[11636]: error: This private key will be ignored. Sep 4 10:42:09 asus sshd[11636]: error: bad permissions: ignore key: /etc/ssh/ssh_host_dsa_key Sep 4 10:42:09 asus sshd[11636]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key Sep 4 10:42:09 asus sshd[11636]: Disabling protocol version 2. Could not load h ost key Sep 4 10:42:09 asus sshd[11636]: sshd: no hostkeys available -- exiting.
Access to the SSH servers can be restricted to specific users or groups (see SSH Configuration). If an unauthorized user tries to connect to the server, it looks like their password is wrong, or that they do not have a local account on the server:
$sshnot-allowed@192.168.0.102not-allowed@192.168.0.102's password: Permission denied, please try again. not-allowed@192.168.0.102's password: Permission denied, please try again. not-allowed@192.168.0.102's password: Permission denied (publickey,password,keyboard-interactive).
In the server logfile, the important line is:
type 11 Sep 4 11:36:17 asus sshd[12238]: Failed password for invalid user not-allowed from 1
For SSH, invalid user means that the user does not exist on the server, or that it is not part of the list of users allowed to connect to the service. To know which one applies, look at /etc/passwd to see whether the user not-allowed exists.
If the user enters the wrong password, the SSH server logs the message Failed password for user julien from 1 (note that here the user is not invalid).