ログイン成功後にLinuxが接続を閉じる
私はDebian 5.2.2を搭載したサーバーで作業しています。 Linuxの管理知識はほとんど持っていないので、何かがおかしくなっていると思います。 apt-get updateとapt-get upgradeを使用してすべてを最新にしてから、Apache、PHP、およびMySQLをダウンロードしてインストールしました。これらのツールは正常に動作しているように見えますが、ローカルコンソール以外ではサーバーにログインすることもできません。 GUI経由でログインしようとした場合、またはssh、scpなどを使用してリモートでログインしようとした場合、ログインが成功するとすぐに切断されます。つまり、初期接続には問題ありませんが、正しいユーザー名とパスワード（rootまたは任意のユーザー用）を入力すると、切断されます。 GUIを使用すると、画面が一瞬真っ黒になり、ログインプロンプトに戻ります。 sshを使用すると、「[サーバー]への接続が閉じられました」と表示されます。 WinSCPを試したところ、「接続が予期せず閉じられました。サーバーがコマンドの終了ステータス254を送信しました。」と表示されます。
どんな助けでもありがたいです、そして、私がより多くの情報を与えることができる方法があったら、私に知らせてください。お時間をいただきありがとうございます。
編集：
-すべてのユーザーがローカルコンソールにログインできます
-現在のところ、マシンへのローカルアクセス権がないため、現在実行できるのはsshだけです。パスワードを入力した後のssh -vvv [server]の出力は次のとおりです。
Linux xxxxxxx.com 2.6.26.8+20091222+1056-debhawk-5.2.2-custom #1 SMP PREEMPT Tue Dec 22 10:58:57 EST 2009 i686
Last login: Mon Apr 30 14:48:07 2012 from xxxxxxx.com
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
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)
debug3: channel 0: close_fds r -1 w -1 e 6
Connection to xxx.x.xx.xx closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3845.3
debug1: Exit status 254
/etc/passwdのシェルパスの設定が正しくないため、これがシェルの生成に問題がある可能性があることを示唆する同様の投稿がいくつかあります
これを確認するには、ユーザーのシェルパスが存在し、実行可能であることを確認します。
# cat /etc/passwd | grep tomh
tomh:x:1000:1000:Tom H:/home/tomh:/bin/bash <-- check this exists
シェルが存在することを確認します。
# file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
また、シェルが/sbin/nologinまたは/bin/falseに設定されていないことも確認してください。認証が成功した場合でも、ログインがブロックされます。
http://www.linuxforums.org/forum/ubuntu-linux/173779-solved-ssh-issue.html
http://www.unix.com/hp-ux/169496-solved-ssh-debug1-exit-status-254-problem.html
http://www.mail-archive.com/[email protected]/msg04460.html
このような問題が発生したとき、1つの接続を開いたまま/ var/log/messagesを明らかにしました。
pam_loginuid(sshd:session): Cannot open /proc/self/loginuid: Read-only file system
Vi /etc/init.d/namedを編集すると、/ procのマウント方法を変更できるため、再起動後にエラーは発生しませんでした。
基本的にライン
if [ ! -e "${CHROOT_PREFIX}/proc/meminfo" ]; then
mkdir -p “${CHROOT_PREFIX}/proc”
mount -tproc -oro,nosuid,nodev,noexec proc ${CHROOT_PREFIX}/proc 2>/dev/null
fi;
に変更されました
if [ ! -e "${CHROOT_PREFIX}/proc/meminfo" ]; then
mkdir -p “${CHROOT_PREFIX}/proc”
mount –bind -o ro /proc “${CHROOT_PREFIX}/proc” 2>/dev/null
fi;
http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905 で見つけたヒント
ログインユーザー名のディレクトリが/homeディレクトリ。したがって、「testuser」というユーザーがいる場合は、/home/testuserディレクトリが利用可能です。 /var/log/messagesファイル。
debug3: channel 0: close_fds r -1 w -1 e 6 Connection to xxx.x.xx.xx closed. debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 0.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3845.3 debug1: Exit status 254
SSHサーバーのsshd_configファイルに次の行を追加します。
UsePAM no
以下はsshd_config OS Xで使用しています。（Debianではなく）Macportsを使用しているOS Xで同じ問題が発生したため、（Debianマシンではなく）投稿しています。
AddressFamily any
ListenAddress 0.0.0.0
Port 1522
# The default requires explicit activation of protocol 1
Protocol 2
# HostKeys for protocol version 2
HostKey /opt/local/etc/ssh/ssh_Host_ed25519_key
HostKey /opt/local/etc/ssh/ssh_Host_ecdsa_key
HostKey /opt/local/etc/ssh/ssh_Host_rsa_key
HostKey /opt/local/etc/ssh/ssh_Host_dsa_key
# Ciphers and keying
#RekeyLimit default none
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# User Authentication
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
UsePAM no
# 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
# Use sandbox on OS X
UsePrivilegeSeparation sandbox
# All user's environment
PermitUserEnvironment yes
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp /opt/local/libexec/sftp-server
LDAPを使用している場合は、次のものすべてを置き換えます。
pam_unix_*.so
/etc/pam.d/のすべてのファイルで：
pam_unix.so
これはlibpam-ldapパッケージのバグです（例pam.dファイル）。以下を参照してください http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825
システムが適切に解決できることを確認してください。sshはそれについて少し特別です。
/etc/secuiry/limits.confをチェックして、ログイン数にハード制限があるかどうかを確認し、それらを増やします。
* hard maxlogins 0
Bramが言及した/ var/log/messagesに加えて、/ var/log/auth.logも確認し、関連する出力を貼り付けてください。情報が多すぎると少なすぎるよりはましです。
私は確かに、@ tom-hが以前に提案した方法でこれらの症状に正確に遭遇しました...解決策は非常に簡単でした。
解決するには、vipwを実行してpasswdファイルを編集し、Shellを/ bin/falseから/ bin/bashに、または好みのオプションに調整します。
# cat /etc/passwd | grep adamjohn
adamjohn:x:1000:1000:Adam John:/home/adamjohn:/bin/false <-- check this exists
# vi /etc/passwd
adamjohn:x:1000:1000:Adam John:/home/adamjohn:/bin/bash <-- change this item
機密性の高いアカウントを保護するためにこれが行われる場合があることを理解してください。他のアクセス制限が設定されている可能性があります。サーバーを保護することの重要性を理解し、このタイプのサーバーへのアクセスを許可することの影響に注意する必要があります。
何度も検索した結果、CentOS 7が特権のないコンテナで実行されている場合の答えがようやく見つかりました。
/etc/pam.d/sshdファイルのsession required pam_loginuid.so行をコメント化してから、コンテナを再起動します。
私はこのソリューションを https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119 で見つけました
LDAPを使用するUbuntu 16.04でも同様の問題がありました。 「ssh -vv ...」は、パスワード認証が成功したことを示しましたが、「リモートホストによって...への接続が閉じられました」というメッセージが表示されました。
「bind_policy」の設定の/etc/ldap.confで修正されました。
/var/log/auth.logが示す：
sshd[19884]: Accepted password for xxxx from xx.xx.xx.xx port 48426 ssh2
sshd[19884]: pam_unix(sshd:session): session opened for user xxxx by (uid=0)
systemd-logind[577]: New session 22 of user xxxx.
systemd: pam_unix(systemd-user:session): session opened for user xxxx by (uid=0)
sshd[19884]: nss_ldap: could not search LDAP server - Server is unavailable
sshd[19884]: fatal: login_get_lastlog: Cannot find account for uid 1502
sshd[19884]: pam_unix(sshd:session): session closed for user xxxx
問題が/etc/ldap.confにあることがわかりました。 bind_policyを「soft」に変更したので、nss_ldapはサーバーに障害が発生するとすぐに戻ります。デフォルトは「hard_open」で、LDAPサーバーへの接続のオープンに失敗した場合に再接続します。 「bind_policy soft」という行をコメント化すると、デフォルトに戻り、問題が解決しました。 :-)
これらはすべて素晴らしい提案です。私の場合、痛みを引き起こしたのはPuTTYの設定でした。
「SSH」構成でサーバーに送信するリモートコマンドを配置しました。これは99％の確率で機能しますが、コマンドが失敗すると、セッションを閉じます。
コマンド？？？ screen -rd
再開するセッションが実際にあるときにうまく機能します。再起動後にひどく失敗します。
ソリューション：
それをbashrc/bash_profileに移動します。
私はこの問題に遭遇しました（特にsftpではなく、sshでは問題なく接続できました）。ここでの解決策はどれもうまくいきませんでした。私の場合、~/.ssh/に含まれているsshキー（IdentityFile's）が多すぎることが原因でした。正しいキーで接続しようとしているホストの~/.ssh/configにホストエントリがない場合、すべてのキーを1つずつ送信するだけです。私は6つ以上のキーを持っていましたが、確かに、デフォルトのMaxAuthTriesは6（少なくともUbuntuでは）です。
解決策は、サーバーの/etc/ssh/sshd_configを編集してMaxAuthTriesを増やすことでした。私は10に設定しました。
#MaxAuthTries 6
MaxAuthTries 10
（またはもちろん、適切なキーを使用してHostエントリを追加するだけです-この特定のケースでは、キーを使用せずにログインしようとしています）。
私の場合、SSHサーバーにシェルのないユーザーがを原因としていた。非常に簡単に修正できます。-N（Open）SSHクライアントで切り替えます。
man page から：
-Nリモートコマンドを実行しません。これはポートを転送するだけの場合に便利です。
私はここの答えのいくつかに同意できません。シェルを持つユーザー/bin/false、/bin/nologinは適切な構成です。通常、SSHサーバーでログインしてコマンドを実行することなく、SSHトンネルでのみ使用されるユーザーに使用されます。したがって、サーバーで「修正」しようとせず、-N SSHクライアントで切り替えます。
/etc/passwdにユーザーの正しいシェルがあることを確認してください。
たとえば、シェルが見つからないため、ユーザーahmadはサーバーにログインできませんでした。
ahmad:x:10000:1003::/home/ahmad:/bin/false
シェルは/bin/falseに設定されているため、ユーザーahmadにシェルがないため、これを修正するには、/bin/falseを/bin/bashに変更して、bashなどのシェル。
Webホスティングコントロールパネルを使用している場合Plesk、ユーザーがサーバーにアクセスできることを確認してください。