SSH Automatically Disconnects After Login

Question

I'm trying to set up an ssh server using OpenSSH on Windows 10. On one of my computers, I've been able to set up the server and successfully login from the same machine.

On the other computer, the SSH session seems to be terminating immediately, despite having the same default settings in a similar Windows 10 system.

After logging in from the command prompt with ssh -vvv localhost, here is the information displayed after the password has been entered:

debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to localhost ([::1]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IPV6_TCLASS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
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
debug3: receive packet: type 96
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
debug3: receive packet: type 97
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
debug3: send packet: type 97
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)

debug3: send packet: type 1
Connection to localhost closed.
Transferred: sent 2168, received 4052 bytes, in 0.9 seconds
Bytes per second: sent 2501.0, received 4674.3
debug1: Exit status 255

Here are the sshd_config settings:

#   $OpenBSD: sshd_config,v 1.98 2016/02/17 05:29:04 djm Exp $
# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/bin:/usr/sbin:/sbin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
# Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh_host_rsa_key
#HostKey /etc/ssh_host_dsa_key
#HostKey /etc/ssh_host_ecdsa_key
#HostKey /etc/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
#RekeyLimit default none

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
LogLevel DEBUG3

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
#AuthorizedKeysFile .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts yes
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

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

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

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of 'PermitRootLogin without-password'.
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# default banner path
Banner /etc/banner.txt

# override default of no subsystems
Subsystem   sftp    /usr/sbin/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

I've seen a few posts suggesting that I turn on logging to get more information. However, I can't figure out how to accomplish this. None of the log files that appear in C:\Program Files\OpenSSH\var\log have any information, and I can't figure out where the logs might be, or how else to enable them.

Let me know if you have any suggestions how to solve my problem or at least to enable logging. Thanks!

Answer 1

Configure OpenSSH to log to a file

1. Navigate to C:\ProgramData\ssh and edit sshd_config file.

2. Under logging section do as follows:

    # Logging
    SyslogFacility LOCAL0
    LogLevel DEBUG3
   

3. Restart the "OpenSSH SSH Server" service.

Now, you will see log messages in the "C:\ProgramData\ssh\logs\sshd.log" file.

My Solution to the problem

I was facing exactly the same error while setting up the OpenSSH on Windows Server 2012R2. After wasting so much time, I found the solution by adding "C:\Program Files\OpenSSH" to the PATH environment variable and restarting the ssh service. It worked like a charm :)

Hope this helps someone.

Answer 2

Given the "authentication successful" message, we know that the SSH server can positively identify the user, which narrows the issue down somewhat.

After that point it would attempt to set up the shell, and that's where it's failing (I think).

So as a very broad matter, I would look at other possibilities beyond an issue with the SSH service per se.

This could be a lot of things, but some ideas are:

1. A user or system level security setting that prohibits the user (or any user) from creating a remote session. In other words even if the user has the right password, if the system doesn't want to let them in it doesn't matter.

2. Some error in the user's initialization scripts. I don't know how this works in Windows, but in Linux there are special files in the user's home directory (the name depends on the shell) which are immediately invoked on login. If one of them has a command to close the shell, it will have the effect of preventing the user from ever logging in, without displaying an error.

One idea to narrow the issue down is to just log in to the target machine and then try ssh'ing to localhost as that account. If that works then you can surmise it has something to do w/ connecting from a remote box.

Unfortunately though, as you can see from googling, there are many possible issues here. So the above might not be on the mark...