☰

SSH 7.4「Promise: Network」で長い一時停止

tag-icon • tag-icon ssh fedora systemd raspberry-pi sshd
SSH 7.4「Promise: Network」で長い一時停止

最近openSSH 7.4を実行しているFedora 25にアップデートされたシステムがあります。これからはsshでログインします。25～30秒程度かかりますLANでは通常1秒を超えません。

実行中のクライアントで-vvv公開鍵認証を使用すると、ここで一時停止が発生します。

debug1: Authentication succeeded (publickey).
Authenticated to crystalline.kodiak ([192.168.0.22]:127).
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

これは、同じネットワーク（Fedora 23、openSSH 7.2）内の他のシステムの出力とは問題なく同じように見えます。

ログイン中にサーバー側の上部を見ると、一時停止が始まるsystemdと短時間（数秒）バーストが発生します。これによりシステムは完全にアイドル状態になります。同様に、クライアント側でも異常な活動はありません。

ログイン後、すべてが正常です。

クライアントとWiresharkの交換を観察しましたが、一時停止中にパケットは交換されませんでした。クライアントとサーバーはルーターを介してイーサネット上にあるため、サーバーアドレスへのすべてのトラフィックも表示できます。何もしません。

これはsshd_config：

Port 127
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
IgnoreRhosts yes
SyslogFacility AUTHPRIV
LogLevel INFO
TCPKeepAlive yes
ClientAliveInterval 120
ClientAliveCountMax 15
PermitRootLogin yes
StrictModes yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM yes
X11Forwarding no
UsePrivilegeSeparation sandbox
AcceptEnv LANG LC_*
Subsystem   sftp    /usr/libexec/openssh/sftp-server

意見にある佐藤勝浦の提案に従って試してみましたが、UseDNS no違いはありませんでした。

答え1

知っていると、これは極端なケースです。

このマシンはデフォルトのPiカーネルを実行しますが、通常のarmhf Fedora 25ユーザーゾーンを持つRaspberry Piです。また、ヘッドレスに設定されており、他の方法では使用したことはありませんが、モニターとキーボードを接続する際に明らかな問題がありますsystemd-logind.service。私は追跡したこの問題、昨年はsystemdの中核部分がセキュリティコンピューティング、何らかの理由で既存のPiコアには含まれていませんが、そのように表示されるように設定が誤って発生する可能性があります。

回避策は非常に簡単です。 seccompが必要なサービスファイルオプションを削除する必要があります。/usr/lib/systemd/systemを含むこれらのいくつかがありますsystemd-logind.service。

また、プライマリシステムでネットワーキングを無効にすることもできますが、私はこの目的のために私のサービスを使用しており、影響を受けませんでした（つまり、他の人がこのようにこの問題を経験する可能性はありません）。

とにかく、私はそのすべての内容から次の行をコメントアウトしました。

MemoryDenyWriteExecute=yes
SystemCallFilter=...

再起動すると問題ありません。

答え2

私の場合、衝突が原因でしたrsyslogd。私はこれを見つけました/var/log/secure。

だからサービスを再起動しましたrsyslog。これは私たちの問題を解決しました。

答え3

私の場合、サーバーでDNSを無効にしました。sshd_config

UseDNS no

答え4

ESXi私の場合、長い停電後に再起動するとホストに過度の負荷がかかり、問題が発生しました。

電源が復元されると、複数（> 30）のLXCコンテナをホストするUbuntu VMが起動し、すべてのコンテナが同時に起動します。起動負荷が多すぎるため、ほとんどのコンテナは無効な状態です。問題を解決し、開発者が再作業できるようにするために、すべてのコンテナを30秒間隔で再起動するスクリプトを作成しました。

少し時間があり、静かな時間があるときに真実を理解できるかどうかを見てみましょう。デジャビュー現象が発生しました。以前に再起動しlogindて忘れたサービスを使用してこの問題を解決しました。

関連情報