☰

Fedora SSH 클라이언트는 3방향 핸드셰이크 후 RST를 보냅니다.

tag-icon • tag-icon debian ssh fedora openssh oh-my-zsh
Fedora SSH 클라이언트는 3방향 핸드셰이크 후 RST를 보냅니다.

2023年5月30日に、Fedora 38およびOpenSSH_9.0p1、OpenSSL 3.0.9を実行するクライアントがあります。サーバーは、Debian 11.8 Bulleyeを実行する古いBuffalo NASであり、2023年9月11日現在、OpenSSH_8.4p1 Debian-5+deb11u3とOpenSSL 1.1.1wを備えています。

中断後にSSH接続がタイムアウトします debug3: set_sock_tos: set socket 3 IP_TOS 0x48。 Wiresharkでは、クライアントはSYNを起動し、サーバーはSYN-ACKを送信し、サーバーはACKを送信してすぐにRSTを送信することがわかります。

74446   6348.950713461  192.168.8.198   192.168.8.174   TCP 74  44446 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=3749347152 TSecr=0 WS=128
74447   6348.952546002  192.168.8.174   192.168.8.198   TCP 74  22 → 44446 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2278029303 TSecr=3749347152 WS=16
74448   6348.952595078  192.168.8.198   192.168.8.174   TCP 66  44446 → 22 [ACK] Seq=1 Ack=1 Win=32128 Len=0 TSval=3749347154 TSecr=2278029303
74449   6348.952616726  192.168.8.198   192.168.8.174   TCP 66  44446 → 22 [RST, ACK] Seq=1 Ack=1 Win=32128 Len=0 TSval=3749347154 TSecr=2278029303
74453   6353.268747244  192.168.8.198   198.168.8.174   TCP 74  38366 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=4212327032 TSecr=0 WS=128
74459   6354.283146552  192.168.8.198   198.168.8.174   TCP 74  [TCP Retransmission] 38366 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=4212328047 TSecr=0 WS=128
74460   6355.307183990  192.168.8.198   198.168.8.174   TCP 74  [TCP Retransmission] 38366 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=4212329071 TSecr=0 WS=128

バージョンが互換性がないと推測して、他のクライアントから接続できます。

私が成功せずに試したことは設定 update-crypto-policies --set LEGACY と update-crypto-policies --set DEFAULT:FEDORA32

ただし、暗号化の非互換の問題がある場合は、より明確なエラーメッセージが必要です。クライアントがプロトコルバージョンを送信するのではなく、接続をリセットする原因は何ですか？この問題をどのように解決できますか？

PS Fedoraクライアントからrootとしてログインすると、接続が成功したことがわかりました。何が欠けているのか知っていますか？

アップデート1：これはルートを使用することです...そうする必要があるようです。

123 49.011405139    192.168.8.198   192.168.8.174   TCP 74  58228 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=3787055761 TSecr=0 WS=128
124 49.014421022    192.168.8.174   192.168.8.198   TCP 74  22 → 58228 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2362587143 TSecr=3787055761 WS=16
125 49.014450365    192.168.8.198   192.168.8.174   TCP 66  58228 → 22 [ACK] Seq=1 Ack=1 Win=32128 Len=0 TSval=3787055767 TSecr=2362587143
126 49.014630252    192.168.8.198   192.168.8.174   SSHv2   87  Client: Protocol (SSH-2.0-OpenSSH_9.0)
127 49.016417357    192.168.8.174   192.168.8.198   TCP 66  22 → 58228 [ACK] Seq=1 Ack=22 Win=65152 Len=0 TSval=2362587145 TSecr=3787055767
128 49.616114970    192.168.8.174   192.168.8.198   SSHv2   106 Server: Protocol (SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3)
129 49.616195199    192.168.8.198   192.168.8.174   TCP 66  58228 → 22 [ACK] Seq=22 Ack=41 Win=32128 Len=0 TSval=3787056369 TSecr=2362587700
130 49.617586438    192.168.8.198   192.168.8.174   SSHv2   1426    Client: Key Exchange Init
131 49.618658862    192.168.8.174   192.168.8.198   SSHv2   1146    Server: Key Exchange Init
...

アップデート2：私は通常のユーザーを除くすべてのユーザーに機能することがわかりました。また、このユーザーにはsudo sshは機能しません。テストのためにユーザーの.sshフォルダ全体を移動しましたが、何の効果もありませんでした。特定のユーザーのSSHにはどのような影響がありますか？ $HOME変数には2つの異なる値が必要であるため、異なるドットファイル構成が使用されます。それらを比較してみてください。

アップデート3：Oh My Zshと関連があるようです。 zshrcを移動し、新しいセッションを開いたときに動作することがわかりました。 oh my zshが削除されました。働いた。再インストールしてデフォルトのzshrcを使用しましたが、うまくいきませんでした。 ClearPlugin() - 動作しません。 oh-my-zsh.shソースをコメントアウトしました。働いた。 oh my zshはここでどのような役割を果たしますか？

アップデート4：これで問題が解決しました。何度も再起動し、Fedora 39にアップデートし、数日間実験してもエラーは続く。 .zshrcを操作した後、エラーは消えましたが、理由はわかりません。

答え1

一時ポート44446が接続しようとしていることを示しました。ルートの場合、低い番号のポートで試すと成功する可能性があります。 1024未満です。

2つの環境があります：{破損、動作中}

$ which ssh両方の出力を比較して同じであることを確認してください。

$ ssh -v ...2つの間の出力を比較して、不正な「壊れ」がどれだけ離れているかを確認します。

$ type ssh私たちを誤解する奇妙なエイリアスがここにないことを自分で確信させるためです。

env | sort2つの環境間の出力を比較します。 PATHを確認したので、マニュアルページに記載されているように、LD_LIBRARY_PATHやSSH_USE_STRONG_RNGなどを探しています。比較する$ ldd /usr/bin/ssh。許可されていないユーザーが、関連するすべての共有オブジェクトに対する読み取りアクセス権を持っていることを確認します。

$HOME変数には2つの異なる値が必要であるため、異なるドットファイル構成が使用されます。比較するそれら。

答え2

サーバーが SYN-ACK を送信した後、クライアントが ACK を送信する順番です。実際にそのようなことが起こります。顧客明らかに、RST-ACKも送信されます。

クライアントにIPアドレスの競合がないことは確実ですか？つまり、Fedoraクライアント192.168.8.198が接続を開始してサーバーが応答しますが、クライアントがACKでTCP 3ウェイハンドシェイクを完了した場合他のシステムまたは仮想マシンIP 192.168.8.198もRST応答を生成するように設定されていますか？

この初期段階では、SSH プロトコルのネゴシエーションの問題にはなりません。아직 어느 방향으로든 데이터가 교환되지 않았습니다..

첫 번째 덤프에서 ACK와 RST-ACK 패킷의 MAC 주소를 비교해야 합니다. 서로 다르다면 클라이언트 시스템에 분명히 IP 주소 충돌이 있는 것입니다. 동일하다면 클라이언트 내에서 일종의 VM/컨테이너 네트워크 구성이 잘못되었을 가능성이 높습니다.

関連情報