SSH автоматически отключается после входа в систему

Question

Я пытаюсь настроить сервер SSH с использованием OpenSSH на Windows 10. На одном из моих компьютеров я смог настроить сервер и успешно войти в систему с того же компьютера.

На другом компьютере сеанс SSH, кажется, немедленно завершается, несмотря на то, что он имеет те же настройки по умолчанию в аналогичной системе Windows 10.

После входа в систему из командной строки с помощью ssh -vvv localhost , вот информация, отображаемая после ввода пароля:

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 no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com 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 eow@openssh.com 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

Вот настройки sshd_config:

#   $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

Я видел несколько постов, предлагающих включить ведение журнала, чтобы получить больше информации. Тем не менее, я не могу понять, как это сделать. Ни один из файлов журналов, которые появляются в C:\Program Files\OpenSSH\var\log содержит никакой информации, и я не могу понять, где журналы могут быть, или как еще их включить.

Дайте мне знать, если у вас есть предложения, как решить мою проблему или хотя бы включить ведение журнала. Спасибо!

Answer 1

Учитывая сообщение "проверка подлинности успешна", мы знаем, что сервер SSH может точно идентифицировать пользователя, что несколько сужает проблему.

После этого он попытается настроить оболочку, и вот где она терпит неудачу (я думаю).

Так что, как очень широкий вопрос, я хотел бы рассмотреть другие возможности, помимо проблемы со службой SSH как таковой.

Это может быть много вещей, но некоторые идеи:

1. Параметр безопасности на уровне пользователя или системы, который запрещает пользователю (или любому пользователю) создавать удаленный сеанс. Другими словами, даже если пользователь имеет правильный пароль, если система не хочет его вводить, это не имеет значения.

2. Некоторая ошибка в скриптах инициализации пользователя. Я не знаю, как это работает в Windows, но в Linux в домашнем каталоге пользователя есть специальные файлы (имя зависит от оболочки), которые сразу же запускаются при входе в систему. Если у одного из них есть команда на закрытие оболочки, это будет препятствовать тому, чтобы пользователь когда-либо входил в систему, без отображения ошибки.

Одна идея, чтобы сузить проблему, это просто войти на целевой компьютер и затем попробовать ssh'ing к localhost в качестве этой учетной записи. Если это работает, то вы можете предположить, что у него есть что-то, что можно сделать с подключением из удаленного блока.

К сожалению, хотя, как вы можете видеть из поиска в Google, здесь есть много возможных проблем. Таким образом, вышеупомянутое не может быть на отметке ...