SSH connection closed after username

matcal · 10-19-2005, 07:41 AM

Desperately need some help. I have built a LFS system recently but I'm experiencing issues with logging in via SSH from a Windows XP machine. I am using puTTY as my SSH client and have previously had no issues with the connection.

Recently this has developed an issue, whereby I can establish a connection and enter a username, but as soon as I press [enter] the connection closes.

I has resolved the issue once before by recompiling SSL and SSH, but this is not fixing the issue now. I can see nothing in the dmesg log on in any of the /var/log files

Any ideas??

Quigi · 10-20-2005, 05:04 PM

First check /var/log/secure for any messages by sshd (need to be root to read that).

If there's no clue, I've found it helpful to run a another sshd in debug mode (-d). It will not fork; it will handle the first connection then exit. Additional -d options increase verbosity (just like -v for ssh). I'd run it on a high port to stay out of the way of the normal sshd, the daemon.

It is possible to run sshd as a normal user, but there are a few things to watch out for.
* Many people make /etc/ssh/sshd.config unreadable for normal users (I don't know why). You can supply another config file with -f; e.g., /dev/null works if you don't want to write one.
* Non-root cannot read the default host key. You can supply your user key (made with ssh-keygen) for a host key.
* Authentication (typically PAM) cannot read /etc/shadow to do password check. That's what I'd worry about most in your case because it happens right after you enter the user name. But maybe it tells you what's wrong before this is an issue. If not, run as root.
* Of course a non-root sshd will only start a shell with the identity of the user running the debug sshd. That shouldn't be a problem.

Good luck!

matcal · 10-22-2005, 07:01 AM

Thanks Quigi

I changed permissions for all files in /etc/ssh to a non-root user with 'chown {username} /etc/ssh/*'

I then did a 'killall sshd' to make sure there no confusion on which version of the service was writing log entries. I ran the '/usr/sbin/sshd -d' as a non-root and a root user and the following was displayed:-

non-root
debug1: sshd version OpenSSH_4.1p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
socket: Address family not supported by protocol
Cannot bind any address

root
debug1: sshd version OpenSSH_4.1p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
socket: Address family not supported by protocol
Generating 768 bit RSA key
RSA key generation complete

The second seemed to have worked. When the startup part has finished the program seems to hang (awaiting more output from sshd), so I try and ssh into the box again and after pressing [enter] on the client machine screen shows:-

debug1: Server will not fork when running in debugging mode
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: initd sockets after dupping: 3, 3
Connection from 192.168.1.* port 2605
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.58
debug1: no match: PuTTY_Release_0.58
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_4.1
debug1: permanently_set_uid:1002/1002
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-cbc hmac-sha1 none
debug1: kex: server->client aes256-cbc hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
* all well and good up to here!
debug1: userauth-request for user [username] service ssh-connection method none
debug1: attempt 0 failures 0
Failed none for [username] from 192.168.1.8 port 2605 ssh2
Failed none for [username] from 192.168.1.8 port 2605 ssh2
debug1: userauth-request for user [username] service ssh-connection method keyboard-interactive
debug1: attempt 1 failures 1
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=[username] devs=
debug1: kbdint_alloc: devices ''
Failed keyboard-interactive for [username] from 192.168.1.* port 2605 ssh2
debug1: do_cleanup

So now I know it's the ssh-connection method that's causing the failures. From what I understand it's because I tried to log in with PAM and failed. Now what do I do?!

Thanks

Quigi · 10-22-2005, 06:37 PM

The normal user failed because only root can bind to ports below 1024. Using a high port (>= 1024) would have taken care of that. To show you what you could expect, I ran (as root)

Code:

/usr/sbin/sshd -dd -p 2222

The user trying to log in must specify "ssh -p 2222 ...". Below is the output I get, starting with the "KEX done" that you got too. Note my double d, which gives me debug2 messages in addition to the debug1.

One more interesting thing: keyboard-interactive fails for me just as for you. Only after that method fails, ssh tries method password (using PAM), which then succeeds and gives me an interactive session. My biggest question now: Why does your sshd not attempt password authentication? In my sshd.config, the relevant sections are commented out, i.e., falling back on defaults:

Code:

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

#...

# Set this to 'yes' to enable PAM keyboard-interactive authentication 
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt no

How does the "Authentication:" section from your sshd.config look like?

So, here goes the promised lengthy sshd output:

Code:

debug1: KEX done
debug1: userauth-request for user brech service ssh-connection method none
debug1: attempt 0 failures 0
debug2: monitor_read: 6 used once, disabling now
debug2: input_userauth_request: setting up authctxt for brech
debug2: input_userauth_request: try method none
Failed none for brech from ::ffff:127.0.0.1 port 56836 ssh2
debug1: Starting up PAM with username "brech"
debug1: userauth-request for user brech service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: PAM setting rhost to "localhost.localdomain"
debug2: monitor_read: 41 used once, disabling now
debug2: monitor_read: 3 used once, disabling now
debug1: temporarily_use_uid: 502/100 (e=0/0)
debug1: trying public key file /home/brech/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 502/100 (e=0/0)
debug1: trying public key file /home/brech/.ssh/authorized_keys2
debug1: restore_uid: 0/0
debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
Failed publickey for brech from ::ffff:127.0.0.1 port 56836 ssh2
debug1: userauth-request for user brech service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs 
debug1: auth2_challenge: user=brech devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices 
Failed keyboard-interactive for brech from ::ffff:127.0.0.1 port 56836 ssh2
* At this point the correponding ssh asks for brech's password
debug1: userauth-request for user brech service ssh-connection method password
debug1: attempt 3 failures 3
debug2: input_userauth_request: try method password
debug1: PAM password authentication accepted for brech
debug2: pam_acct_mgmt() = 0
Accepted password for brech from ::ffff:127.0.0.1 port 56836 ssh2
debug1: monitor_child_preauth: brech has been authenticated by privileged process
Accepted password for brech from ::ffff:127.0.0.1 port 56836 ssh2
debug2: mac_init: found hmac-md5
debug2: mac_init: found hmac-md5
debug1: PAM establishing creds
debug1: permanently_set_uid: 502/100
debug2: set_newkeys: mode 0
debug2: set_newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug1: fd 8 setting O_NONBLOCK
debug1: fd 9 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug2: User child is on pid 17710
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: lastlog_openseek: Couldn't open /var/log/lastlog: Permission denied
debug1: Allocating pty.
debug1: session_new: init
debug1: session_new: session 0
debug1: session_pty_req: session 0 alloc /dev/pts/7
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: fd 12 setting O_NONBLOCK
debug2: fd 12 is O_NONBLOCK
debug1: channel 1: new [X11 inet listener]
debug1: fd 13 setting O_NONBLOCK
debug2: fd 13 is O_NONBLOCK
debug1: channel 2: new [X11 inet listener]
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: PAM setting tty to "/dev/pts/7"
debug1: PAM establishing creds
debug1: Setting controlling tty using TIOCSCTTY.
debug1: channel 0: rfd 3 isatty
debug1: fd 3 setting O_NONBLOCK
debug2: fd 10 is O_NONBLOCK
debug1: X11 connection requested.
debug2: fd 14 setting TCP_NODELAY
debug1: fd 14 setting O_NONBLOCK
debug2: fd 14 is O_NONBLOCK

Quigi · 10-24-2005, 11:04 AM

It could be that the ssh client just doesn't try password authentication. When I run

Code:

ssh -v -o " PasswordAuthentication no" localhost

It fails without asking for a password. (Messge: Permission denied (publickey,password,keyboard-interactive).)

You could try to ssh from your LFS box to itself (localhost or 127.0.0.1) to sort out if the server (sshd) or the client (ssh/putty) is to blame. That said, I never had such problems with putty; I pretty much trust it.