ssh接続の開始には永遠に時間がかかり、「pledge：network」にとどまります

sshを使用して私のサーバーの1つに接続するのに20秒以上かかります。

これはLANまたはWANの状態とは関係ありません。それ自体への接続も同じ（ssh localhost）を使用するためです。接続が最終的に確立された後、サーバーとのインターラクトは非常に高速です。

-vvvを使用すると、「pledge：network」と言った後に接続が停止していることがわかります。この時点で、ここに表示されているように、認証（ここではキーを使用）は既に行われています：

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

（...ここで15〜25秒間スタックします...）

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

サーバーはUbuntu 16.04です。過去に別のサーバー（Ubuntu 12.04だった）で既に起こっていた、神経質な人が解決策を見つけ、しばらくして問題が消えてしまった...

sshd_configは、Ubuntuが提供するデフォルトの設定です。

これまで私は試しました：

• sshコマンドで-o GSSAPIAuthentication = noを使用
• キーの代わりにパスワードを使用する
• sshd_configで、yesではなくUsePrivilegeSeparation noを使用します。

これはおそらく問題ですD-Busとsystemd。dbus何らかの理由でサービスが再起動された場合は、再起動する必要もありますsystemd-logind。

これが問題であるかどうかを確認するには、sshデーモンログを開き（Ubuntuでは/var/log/auth.log）、次の行があるかどうかを確認します。

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

はいの場合、systemd-logindサービスを再起動します。

systemctl restart systemd-logind

CentOS 7でも同じ問題messagebusが発生しました（D-BusCentOSでサービスが呼び出される方法）。

答えを見つけました：

sshd_configファイルのUsePAMをyesからnoに変更

sshサービスを再起動すると、サーバーへの接続がすぐに開始されます。このサーバーでは、PAMはldapにリンクされているため、LDAPでなくサーバー自体で宣言されたユーザーと接続している場合でも、おそらくこれが理由です。

まあ、これは問題を回避するための方法であり、実際の解決策ではありません...この問題を抱えていない同じ方法で他のサーバーをセットアップしています。

これが誰かを助けることを願っています...

これは、Fedora 25サーバーのうち2台で発生しました。これは、SSHログインの試行が何度も失敗したためです。

（GSSAPIAuthentication=noand を使用するUseDNS=no、または再起動するという一般的な提案はsystemd-logind違いはありませんでした。）

これらのサーバーに/etc/pam.d/postloginは、次のものが含まれます。

session     optional      pam_lastlog.so silent noupdate showfailed

のmanページでpam_lastlogは、showfailedオプションが次のことを行うことが説明されています。

ログインに失敗した回数と、btmpから最後に失敗した試行の日付を表示します。

これらのサーバーでは、/var/log/btmp多くのログイン試行が失敗したため、ファイルは膨大でした。btmpログファイルは、どちらかに回転されていませんでした。

logrotateパッケージをインストールして、今後ログファイルがローテーションされるようにしました。（Fedoraでは、に付属する構成logrotateがの回転を処理し/var/log/btmpます。）

また、膨大なbtmpログファイルも削除しました。これを行うとすぐに、サーバーへの接続が再び瞬時になりました。

私の場合、理由はクラッシュしたrsyslogdでした。これは、たとえば/ var / log / syslogや/var/log/mail.logにログメッセージがなくなったために見つかりました。

そこでservice rsyslog restart問題を解決しました。

私にとって、この問題は大きなbtmpファイル（数百MB）が原因です。このファイルはログイン試行を記録します。人々がパスワードをブルートフォースしようとすると、このファイルは大きくなり、"pledge: network"フェーズが遅れる可能性があります。

ログファイルをクリアしてみてください

echo "" > /var/log/btmp

それが役立つかどうかを確認します。

私にとって解決策は

UseDNS no

/etc/ssh/sshd_configして、もちろんservice ssh restart（私たちはDebian /ジェシー・サーバ上）。他に何もない...

前：

ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

後：

ssh git@git.*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.574 total

デバッグフィードバックに次の行があることに気付きました。

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

これはroot:root私が所有しているファイルですjenkins。このファイルを削除すると問題が解決しました。