[SOLVED] Dropbear disconnects after successful auth

I upgraded to 18.06 on my Buffalo WZR-HP-AG300H. All seems fine except that I cannot SSH in to the box as before. The system log indicates:

Password auth succeeded for root from <...>

followed by

Exit (root): Disconnect received

A Wireshark trace shows that the auth succeeded but the router immediately set the FIN flag.

Any clues? I've tried changing from dropbear to openssh with the exact same results.

From the remote host try

ssh -v you@your.router

Multiple -v options increase the verbosity. The maximum is 3.

-vvv is very chatty, but occasionally needed to see some low-level problems.

and see if there were any hints given to the client

1 Like

One potential reason for this behaviour would be if you had switched root's shell (e.g. to bash) before, as sysupgrading will (and must) remove additionally installed binaries during the upgrade, leaving you with your old configuration override to use /bin/bash as root's shell, without bash being installed.

7 Likes

Thanks Jeff. Here is a chattier output (I used vv):
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:E06nUtOvMJGwL5crSVCcY08NwVxwsgjVvrIqpCe6K2s /home/me/.ssh/id_rsa
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:E06nUtOvMJGwL5crSVCcY08NwVxwsgjVvrIqpCe6K2s
debug1: Authentication succeeded (publickey).
Authenticated to buffalo-dual ([10.238.134.1]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug1: pledge: network
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 24576 rmax 32759
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
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-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
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
Connection to buffalo-dual closed.
Transferred: sent 2960, received 1456 bytes, in 0.0 seconds

Ah - you nailed it 100%!!!

And I think I've run across this once or twice, but I forgot that caveat altogether!

Many thanks.

1 Like

Looks like the shell isn't starting properly. Up until that point nothing looks "strange" to me.

2 Likes

Jeff, you're perfectly right - see above.

1 Like

Feel free to mark @slh's post as solved by clicking the checkbox under the post. Also consider editing the title of the thread and appending [SOLVED] to the beginning.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.