ログイン成功後にLinuxが接続を閉じる

私はDebian 5.2.2のサーバーで作業しています。Linuxの管理知識をほとんど持っていないので、私は何かを台無しにしたと思います。apt-get updateとapt-get upgradeを使用してすべてを最新の状態にした後、Apache、PHP、およびMySQLをダウンロードしてインストールしました。これらのツールは正常に機能しているように見えますが、ローカルコンソールを介してサーバーにログインすることさえできなくなりました。GUI経由でログインしようとした場合、またはssh、scpなどを使用してリモートでログインしようとした場合、ログインが成功するとすぐに切断されます。つまり、最初の接続には問題ありませんが、正しいユーザー名とパスワード（rootまたは任意のユーザー）を入力すると、切断されます。GUIを使用すると、画面が一瞬黒くなり、ログインプロンプトに戻ります。sshでは、「[サーバー]への接続が閉じられました」というメッセージが表示されます。

どんな助けでも感謝します、そして、私がより多くの情報を与えることができる何らかの方法があったら、私に知らせてください。お時間をいただきありがとうございます。

編集：

-すべてのユーザーがローカルコンソールにログインできます

-現時点では、マシンにローカルでアクセスできないため、今できることは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/seawolf-list@redhat.com/msg04460.html

このような問題が発生したとき、/ var / log / messagesが開いている1つの接続がまだ表示されていました。

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_configOS Xで使用しています。DebianマシンではなくOSXで投稿しています。OSXでMacports（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が先ほど提案した方法でこれらの症状に正確に遭遇しました...解決策は非常に簡単でした。

解決するには、単純にvipwpasswdファイルを編集し、シェルを/ 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

機密性の高いアカウントを保護するためにこれが行われる場合があることを理解してください。他のアクセス制限がある場合があります。サーバーを保護することの重要性を理解し、このタイプのアクセスを許可することの意味に注意する必要があります。

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」という行をコメントアウトすると、デフォルトに戻り、問題が解決しました。:-)

何度も検索した結果、CenOS 7が特権のないコンテナで実行されている場合にようやく答えを見つけました。

session required pam_loginuid.so/etc/pam.d/sshdファイルの行をコメントアウトしてから、コンテナを再起動します。

このソリューションはhttps://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119で見つけました

これらはすべて素晴らしい提案です。私の場合、痛みを引き起こすのはPuTTY設定でした：

「SSH」構成でサーバーに送信するリモートコマンドを配置しました。これは99％の時間でうまく機能しますが、コマンドが失敗すると、セッションが終了するだけです。

コマンド？？？画面-rd

実際に再開するセッションがある場合に最適です。再起動後にひどく失敗します。

ソリューション：

それをbashrc / bash_profileに移動します。

私の場合、SSHサーバーにシェルのないユーザーが原因でした。非常に簡単な修正があり、-N（Open）SSHクライアントでスイッチを使用するだけです。

manページから：

-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または他のシェルに変更する必要があります。

PleskなどのWebホスティングコントロールパネルを使用している場合、ユーザーがサーバーにアクセスできることを確認してください。

LDAPの問題である可能性があります。LDAP、Kerberos、およびSMB設定を構成するauthconfigはなしで実行されましたが、

--enablemkhomedir