Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm having difficulty setting up ssh for a laptop on my LAN. I think I have done all the obvious things. On the server:

ps -A | grep sshd
18278 ?       00:00:00  sshd

and

ss -lnp

shows sshd listening on port 22. I've checked hosts.deny and hosts.allow, both are empty. UFW show connections allowed on port 22 and the router firewall is turned off.

On the client:

ssh -v jane@192.168.2.12                                                                                                   martin@martin-UX21E  7:54PM
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.2.12 [192.168.2.12] port 22.
debug1: Connection established.
debug1: identity file /home/martin/.ssh/id_rsa type -1
debug1: identity file /home/martin/.ssh/id_rsa-cert type -1
debug1: identity file /home/martin/.ssh/id_dsa type -1
debug1: identity file /home/martin/.ssh/id_dsa-cert type -1
debug1: identity file /home/martin/.ssh/id_ecdsa type -1
debug1: identity file /home/martin/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 36:bf:c0:c6:d1:e0:16:bd:f0:8c:88:fe:1b:4b:12:74
debug1: Host '192.168.2.12' is known and matches the ECDSA host key.
debug1: Found key in /home/martin/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Connection closed by 192.168.2.12

On the server,

ssh localhost

works fine, but

ssh 192.168.2.12

doesn't. For some reason it is happy to accept connections using the hostname, but not the IP address.

Can anybody suggest the next troubleshooting step?


In response to victorcete83:

ssh -vvv jane@192.168.2.12                                                                                                 martin@martin-UX21E  8:00PM
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.2.12 [192.168.2.12] port 22.
debug1: Connection established.
debug1: identity file /home/martin/.ssh/id_rsa type -1
debug1: identity file /home/martin/.ssh/id_rsa-cert type -1
debug1: identity file /home/martin/.ssh/id_dsa type -1
debug1: identity file /home/martin/.ssh/id_dsa-cert type -1
debug1: identity file /home/martin/.ssh/id_ecdsa type -1
debug1: identity file /home/martin/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.2.12" from file "/home/martin/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/martin/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 36:bf:c0:c6:d1:e0:16:bd:f0:8c:88:fe:1b:4b:12:74
debug3: load_hostkeys: loading entries for host "192.168.2.12" from file "/home/martin/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/martin/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.2.12' is known and matches the ECDSA host key.
debug1: Found key in /home/martin/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/martin/.ssh/id_rsa ((nil))
debug2: key: /home/martin/.ssh/id_dsa ((nil))
debug2: key: /home/martin/.ssh/id_ecdsa ((nil))
Connection closed by 192.168.2.12
share|improve this question
1  
You should check the log files at the server side. Make sure you check /var/log/auth.log and /var/log/daemon.log for any entries appearing at the time you tried to log in from the client machine. –  Cedric Feb 21 '13 at 20:11
    
How long does it take from pressing Enter after ssh -v jane@192.168.2.12 to Connection closed by 192.168.2.12? 10 second? Maybe 30? –  slimsuperhero Feb 21 '13 at 20:18
    
Can you try connecting with more verbosity and take a look? ssh -vvv jane@192.168.2.12 –  victorcete83 Feb 21 '13 at 20:19
    
two minutes exactly (measured using time()) –  mojones Feb 21 '13 at 20:39
    
running tail on /var/log/auth.log doesn't show anything when I try to log in. I don't have a /var/log/daemon.log. –  mojones Feb 21 '13 at 20:44
show 1 more comment

4 Answers

Two minutes is too long. I am sure your sshd closes connection because of settings in sshd_config. Check LoginGraceTime in sshd_config. It is exactly 120 seconds by default. Try to set 300 seconds and then try to connect. To fasten the authentication, turn off unused authentication methods. In case you want only Password and Pubkey auth, set ChallengeResponseAuthentication to no.

share|improve this answer
add comment

If the ssh connection works pointing to localhost, means that it's going to 127.0.0.1. If it fails with pointing to 192.168.2.12 should be because your ssh is listening on 127.0.0.1 (localhost).

Check your ListenAddress on sshd configuration file.

share|improve this answer
    
Connection to 192.168.2.12:22 establishes, it is clear from debug messages. Localhost connection succeeds because of faster local authentication - it fits the LoginGraceTime period. –  slimsuperhero Feb 22 '13 at 9:58
add comment

Try ssh'ing from another lan host to your laptop. My guess is your .ssh directory has some mangled or mismatched keys in it. Starting on another host eliminates the .ssh directory contents other than authorized_keys from being the problem.

share|improve this answer
add comment

Another idea is to run the sshd deamon manually on the server with the -d flag to generate more debug output on the server. it will stay in the foreground and output debut information on the console.

You can run this second sshd deamon in parallel on another port using the -p <portnumber> option when you start the second deamon.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.