☰

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 클라이언트에서 루트로 로그인하면 연결이 성공한 것으로 나타났습니다. 무엇이 빠졌는지 아시나요?

업데이트 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 변수에는 두 개의 서로 다른 값이 있어야 하므로 서로 다른 도트 파일 구성이 사용됩니다. 그것들을 비교해보세요.

업데이트 3:Oh My Zsh와 관련이 있는 것 같습니다. zshrc를 이동하고 새 세션을 열었을 때 작동하는 것을 발견했습니다. oh my zsh가 제거되었습니다. 작동했습니다. 다시 설치하고 기본 zshrc를 사용했지만 작동하지 않았습니다. ClearPlugin() - 작동하지 않습니다. oh-my-zsh.sh 소스를 주석 처리했습니다. 작동했습니다. oh my zsh는 여기서 어떤 역할을 합니까?

업데이트 4: 이렇게 하면 문제가 해결되었습니다. 여러 번 재부팅하고 Fedora 39로 업데이트하고 며칠 동안 실험한 후에도 오류가 지속됩니다. 이제 .zshrc를 조작한 후에는 오류가 사라졌지만 이유는 확실하지 않습니다.

답변1

임시 포트 44446이 연결을 시도하고 있음을 보여 주셨습니다. 루트인 경우 낮은 번호의 포트에서 시도하면 성공할 수 있습니다. 1024보다 작습니다.

두 가지 환경이 있습니다: {손상됨, 작동 중}

$ which ssh두 출력을 비교하여 동일한지 확인합니다.

$ ssh -v ...둘 사이의 출력을 비교하여 권한 없는 "깨짐"이 얼마나 멀리 있는지 확인하십시오.

$ type ssh우리를 오도하는 이상한 별칭이 여기에 있지 않다는 것을 스스로 확신시키기 위해서입니다 .

env | sort두 환경 간의 출력을 비교합니다 . PATH를 확인했으므로 매뉴얼 페이지에 언급된 대로 LD_LIBRARY_PATH 또는 SSH_USE_STRONG_RNG와 같은 것을 찾고 있습니다. 비교하다 $ ldd /usr/bin/ssh. 우리는 권한이 없는 사용자가 관련된 모든 공유 객체에 대한 읽기 액세스 권한을 갖고 있는지 확인하려고 합니다.

$HOME 변수에는 두 개의 서로 다른 값이 있어야 하므로 서로 다른 도트 파일 구성이 사용됩니다. 비교하다그것들.

답변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/컨테이너 네트워크 구성이 잘못되었을 가능성이 높습니다.

관련 정보