4

I had SSH working on my Raspberry but suddenly it's not working anymore and I get the follwing output.

Any help is really appreciated.

Thanks,

ssh -vvv [email protected]
OpenSSH_6.9p1, LibreSSL 2.1.7
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 3: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.151 [192.168.1.151] port 22.
debug1: Connection established.
debug1: identity file /Users/moli/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/moli/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/moli/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/moli/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/moli/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/moli/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/moli/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/moli/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.151:22 as 'pi'
debug3: hostkeys_foreach: reading file "/Users/moli/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/moli/.ssh/known_hosts:14
debug3: load_hostkeys: loaded 1 keys from 192.168.1.151
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: [email protected],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: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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,[email protected]
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,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+O4WT2JMAm3xSHsd1mDK6aCN9yNTNnS/KH30aSS5jh8
debug3: hostkeys_foreach: reading file "/Users/moli/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/moli/.ssh/known_hosts:14
debug3: load_hostkeys: loaded 1 keys from 192.168.1.151
debug1: Host '192.168.1.151' is known and matches the ECDSA host key.
debug1: Found key in /Users/moli/.ssh/known_hosts:14
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: /Users/moli/.ssh/id_rsa (0x7ff1eb41c210),
debug2: key: /Users/moli/.ssh/id_dsa (0x0),
debug2: key: /Users/moli/.ssh/id_ecdsa (0x0),
debug2: key: /Users/moli/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/moli/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:XWw4Y5KQF2I0mEKCqQefak1rmTu65pQs+Rm2PkTwLLI
debug3: sign_and_send_pubkey: RSA SHA256:XWw4Y5KQF2I0mEKCqQefak1rmTu65pQs+Rm2PkTwLLI
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.151 ([192.168.1.151]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Linux raspberrypi 4.1.4+ #808 PREEMPT Thu Aug 6 15:51:03 BST 2015 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
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 cc -1)

Connection to 192.168.1.151 closed.
Transferred: sent 3632, received 2320 bytes, in 121.0 seconds
Bytes per second: sent 30.0, received 19.2
debug1: Exit status -1

Server log (auth.log): 

Oct 11 09:43:41 raspberrypi sshd[26122]: Accepted password for pi from 192.168.1.220 port 57617 ssh2
Oct 11 09:45:29 raspberrypi sshd[26128]: Received disconnect from 192.168.1.220: 11: disconnected by user

SSH ID: 

$ ssh [email protected] id
[email protected]'s password: 
uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),105(netdev),999(input),1002(spi),1003(gpio)
Improve this question
5
  • 2
    Perhaps your users shell is set to something that doesn't work? Commented Oct 10, 2015 at 22:38
  • please, see server logs Commented Oct 11, 2015 at 7:57
  • I included the server logs Commented Oct 11, 2015 at 8:10
  • The client debug shows it receiving eof from the server. So there's an invalid shell, or you've got the equivalent of "logout" in your shell's profile file. Can you ssh [email protected] id? If not then this points the finger at your shell. grep '^pi:' /etc/passwd Commented Oct 11, 2015 at 8:31
  • Yes @roaima I can ssh [email protected] id Commented Oct 12, 2015 at 7:04

2 Answers 2

Reset to default
1

As Steve Wills said, most likely the pi user has a wrong (or no) shell on the server.

You might try the following:

$ ssh [email protected] /bin/sh

And try a simple ls. If this works, that will probably confirm it is a shell issue. From there, as @roaima told you in the comments, checkout what is pi's shell on the server:

$ ssh [email protected] grep ^pi: /etc/passwd

And if it is actually wrong, change it, for example like this:

$ ssh [email protected] perl -pi -e 's,/bin/wrongshell,/bin/sh,' /etc/passwd
Improve this answer
1

You've demonstrated that it's not the login shell or ssh at fault, because if it was the ssh [email protected] id would have failed.

Next things to try are temporarily moving your .profile out of the way. Don't worry about errors from mv not finding the file:

ssh [email protected] mv .bash_profile .bash_profile.SAVE
ssh [email protected] mv .profile .profile.SAVE

Now try logging in again. If that fails then try this to identify the point at which the shell set-up fails:

ssh [email protected] /bin/bash -xi

You'll get lots of lines starting with + showing the commands that bash runs during its set-up. The few lines immediately before the point it terminates unexpectedly are the most relevant. You will either be able to diagnose the issue from those lines or you'll need to add them to your question.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.