이 빌어먹을 실수로 인해 내 두통이 매일 더 심해졌습니다. 나는 이런 상황에 처한 적이 없습니다.
글쎄요, SSH로 성공적으로 인증한 후 몇 가지 작업을 수행했는데 갑자기 SSH 연결이 끊어졌습니다! ! ?
내 오류 메시지는 다음과 같습니다.packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe
나는 내 오류 메시지를 다음과 같이 표시하고 싶습니다. Write Failed: broken pipe많이, 저를 믿으세요!
나는 ServerAliveInterval, ServerAliveCountMax, ClientAlive를 추가하는 등 인터넷에서 많은 솔루션을 시도했습니다...
어떤 사람들은 다음과 같이 말합니다. TCPKeepAlive를 no로 변경하고 ServerAlive를 추가하는 등의 바보. 나도 이렇게 했지만 여전히 같은 오류가 발생했습니다.
지금까지 나는 운이 좋았던 적이 없었다.
어떤 도움이라도 대단히 감사하겠습니다.
답변1
2018년 이후 독자 여러분,
MelBurslan의 리뷰를 보여드리겠습니다.
기업 환경에 있는 경우 방화벽 관리자에게 문의하여 이런 일이 발생하면 규칙을 업데이트하는지 확인하거나 변경 사항을 적용한 후 방화벽을 다시 시작하십시오. 개인 서버에 이런 일이 발생하면 이 문제가 발생했을 때 sshd 서버 측에서 수행한 작업에 대한 추가 정보를 제공해야 합니다. 손상된 파이프는 일반적으로 어떤 이유로 인해 네트워크가 다운되었음을 의미합니다.
기본적으로 VPN(기업 환경)을 통해 사용하려는 경우입니다. 그러면 이 실수는 계속해서 당신에게 남을 것입니다.ssh [email protected]
유일한 해결책내가 지금까지 찾은 것은핸드폰 케이스. 그것을 만든 사람에게 감사드립니다.
mosh-server대상(ssh로 연결하려는 서버)과 호스트에 mosh-client설치 해야 합니다 .
패킷이 손실되면 자동으로 다시 연결되는데, 이는 매우 멋지고 우리의 모든 요구 사항에 적합하다고 생각합니다.
2020년 3월 업데이트:
mosh-server서버에 설치할 수 없는 경우 여기에서 내 스크립트를 사용할 수 있습니다.https://github.com/ohmybash/oh-my-bash/blob/master/tools/autossh.sh
SSH 세션이 만료되면 자동으로 SSH에 다시 연결됩니다.
즐거운 시간 보내세요!
답변2
이것이 VMware 게스트 설정의 IPQoS 옵션에 문제가 있는 것으로 나타났습니다. VM에서 IPQoS에 대한 ~/.ssh/config 값을 기본값인 "IPQoS af21 cs1"로 설정했습니다. 첫 번째는 대기 시간이 짧은 대화형 데이터에 대해, 두 번째는 비대화형 낮은 워크로드에 대해 설정했습니다. af21에 대한 새로운 가치를 설정하는 것이 내 솔루션이었습니다.
Host *
IPQoS throughput
나에게 적합합니다. 그렇지 않으면 MoSH도 작동하지만 mosh는 프록시 설정을 편리한 방식으로 처리하지 않으므로 ProxyJump 명령을 사용합니다.
답변3
먼저 귀하의 질문이 다음과 관련이 없는지 확인하십시오.이것.
그렇지 않은 경우에도 문제가 지속되면 계속 읽으십시오.
나 역시 이 문제에 직면해 이를 해결하기 위해 며칠을 보냈다.
지정된 대로 SSH KeepAlive 매개변수 또는 커널 TCP 매개변수(TCPKeepAlive 켜기/끄기)를 사용해도 문제가 해결되지 않습니다.
USB-이더넷 드라이버와 TCP 덤프를 사용한 후 문제가 커널 4.8에 의한 것임을 깨달았습니다. 소스(발신자)를 4.4 LTS로 전환했는데 문제가 사라졌습니다(rsync, scp가 다시 잘 작동했습니다). 원하는 경우 대상을 4.8에 그대로 둘 수 있습니다. 제 사용 사례에서는 이것이 작동했습니다(테스트됨).
기술적인 측면에서는 제가 만든 Wireshark 덤프를 사용하여 문제의 범위를 조금 좁힐 수 있습니다. SSHv2 프로토콜의 TCP 채널이 재설정되고(TCP의 RST 플래그가 1로 설정됨) 연결이 중단되는 것을 볼 수 있습니다. 아직 RST의 이유를 모르겠습니다. 이렇게 하려면 4.8.1에서 4.8.11까지 몇 가지 이분법을 수행해야 합니다.
귀하의 문제가 특별히 커널 4.8 때문이라고 말하는 것은 아니지만, wrt. 질문/메시지를 게시한 날짜에 실제로 버그가 있는 커널 버전을 사용하고 있었을 수도 있습니다.
원래 답변 :스택 오버플로.
답변4
실제로 내 문제에 대한 해결책을 찾았습니다. Linux 사용자가 SELinux 사용자에 매핑되어 있는지 확인하세요.
설명하자면, 기본적으로 Linux에서 생성된 모든 사용자는 동일한 unconfined_u SElinux 사용자 컨텍스트를 갖습니다. 이는 일반 Linux 사용자가 루트가 수행하는 작업을 수행할 수 있음을 의미합니다.Linux 사용자와 SElinux 사용자 간의 명시적인 변경 또는 매핑으로 인해 ssh가 제대로 작동하지 않을 수 있습니다.
시나리오: 여기에서 일반 Linux 사용자를 생성합니다. 사용자 추가 -m USER1
USER1은 이제 일반 Linux 사용자입니다. 기본적으로 이 Linux 사용자 USER1은 SElinux unconfined_u USER1에 매핑되며 기본적으로 생성된 모든 사용자는 SElinux unconfined_u 아래에 있게 됩니다. 루트 사용자도 이 명령으로 확인합니다. 관리자 로그인 -l
일반 Linux USER1을 SElinux sysadm_u 사용자에 매핑하기로 결정하면 USER1에 ssh를 사용할 수 없습니다. Semanage 로그인 -m -s sysadm_u -r s0 USER1
USER1은 이제 SELinux sysadm_u 사용자에 매핑되어 SSH 유틸리티를 사용할 수 없습니다.
이 문제를 어떻게 해결하나요? 글쎄, Linux 사용자 "USER1"을 SELinux 사용자 "user_u"에 매핑해 보면 실제로 문제가 해결됩니다.
사용자를 SElinux sysadm_u에 매핑하지 마십시오.