기권
SSH 연결이 짧은 네트워크 중단에서 살아남지 않으면ssh TCP가 정상적인 작업을 수행하지 못하게하는 다른 일이 발생합니다.
자세한 내용은 아래를 참조하십시오. 어쨌든:
가장 빠르고 독립적 인 무 종속 솔루션
다음과 같은 쉘 스크립트를 작성하십시오.
#!/bin/sh -
# Tune these numbers depending on how aggressively
# you want your SSH session to get reconnected.
timeout_options='-o ServerAliveInterval=4 -o ServerAliveCountMax=2'
# 255 is the status OpenSSH uses to signal SSH errors, which
# means we want to connect. All other exit statuses suggest
# an intentional exit.
status=255
# Keep opening the SSH connection and immediately dropping into
# `screen` until an intentional exit happens.
while [ "$status" = 255 ]
do
ssh $timeout_options -t "$@" screen -dR
status=$?
# You can add a `sleep` command here or a counter or whatever
# you might need as far as rate/retry limiting.
done
exit "$status"
이것은 연결 ssh하고 연결을 계속 시도하는 어리 석고 단순한 루프를 실행합니다 screen. 호스트 또는 일반적으로 ssh호출에 명령 행 인수로 전달할 다른 것을 전달하십시오 .
재 연결은 SSH가 연결에 오류를보고하는지 여부를 기반으로합니다. 즉, "당신은 문자 그대로 WiFI가 켜져 있지 않습니다"와 같은 SSH 이외의 오류를 감지 할 수있는 지능이 없습니다. 당신.
나는 당신이 ssh-agent암호를 입력하지 않은 SSH 키 를 가지고 있다고 가정 하고 있습니다.
^C다시 연결하는 동안 사람이 인식 할 수없는 순간의 1 초 동안 적중 ^C하면 클라이언트 터미널로 연결하는 대신 스크립트를 종료시킬 수있는 작은 경합 조건이 생길 수 있습니다. ^C너무 열심히 으 깨지 마십시오 .
가장 간단한 추가 소프트웨어 솔루션
autossh 프로그램을 사용해보십시오.이 프로그램 은 Ubuntu 패키지 저장소에서 사용할 수 있습니다.
당신은 소스 또는 감사 그것에서 구축해야하는 경우 종속 등의 추가 라이브러리없이 컴파일은, 위의 내 해킹보다 연결 생기 확인에 대한 자세한 정보를 갖고있는 것 같아요 것을 하나의 C 프로그램입니다, 그리고 그것은 또한 편리와 함께 제공 rscreen되는 자동 스크립트 명령 에 첨부합니다 screen.
세부
ssh정상적으로 복구 하는 방법
확인하기 위해, 나는 스스로 확인하지 않고 말을 좋아하지 않기 때문에 대답하기 전에 약간의 테스트를 실시했습니다.
Linux 장치로 WiFi를 사용하고 LAN의 다른 장치에 SSH로 연결하고 다른 ssh쪽 끝 으로 작업 연결이 있는지 확인한 후 (명령을 실행할 수 있음 등) 클라이언트 에서 WiFi 연결을 끊었습니다 (인터페이스를 유발 함). 구성 해제 : 더 이상 IP 주소 없음), 더 많은 문자를 ssh 세션에 입력 한 다음 (응답 없음) WiFi에 다시 연결했습니다. 나쁜 신호 및 기타 요인으로 인해 연결이 실제로 한 번 이상 실패했습니다. 그런 다음 마침내 다시 연결되었습니다. ssh세션이 복구 될 때까지 약 5 초 동안 기다렸는데 아무 일도 일어나지 않아 하나 더 많은 키를 누르고 ssh세션 중에 즉시 연결이 끊어졌습니다. 연결을 끊는 동안 입력 한 모든 키가 명령 줄에 나타납니다.
참조 ssh만 / 기록하는 OS가 뭔가 잘못을 이야기하고, TCP 실제로 때까지 TCP 네트워크 소켓에 읽고 아주 장시간 연결 방울의 허용.
기본 커널 설정을 가진 자체 장치를 남겨두고 Linux의 TCP 스택은 연결이 끊어 졌다고 선언하고 오류를보고하기 전에 몇 분 동안 완전히 침묵하는 연결을 행복하게 허용합니다. ssh결국 포기할 때까지 ~ 30 분 또는 적어도 1 분 또는 1 분 동안 지속되는 연결 딸꾹질을 견딜 수있을만큼 충분히 길어야합니다.
덮개 아래에서 Linux TCP 스택은 점점 더 길고 지연된 메시지를 점차 재 시도합니다. 즉, 연결이 다시 시작될 때 ssh세션이 다시 "작동" 하기 전에 추가 지연이 발생할 수 있습니다 .
왜 이것이 깨지는가
TCP 스택이 허용 할 수있는 양보다 비 활동 기간이 상당히 짧은 후에 연결이 닫히는 원인이 있을 수 있습니다 ssh. 그런 다음 해당 연결 상태를 클라이언트 에보고하지 않습니다 .
후보는 다음과 같습니다.
방화벽 또는 NAT 라우터는 메모리를 사용하여 각 라이브 TCP 연결을 기억해야합니다. 도스 공격에 대한 최적화 및 일부 완화 방법으로 때로는 연결을 잊어 버린 다음 후속 패킷을 자동으로 무시 합니다. 기존 연결이 기억 나지 않을 때 연결 중간에 잘못된 것으로 보입니다.
더 잘 작동하는 방화벽 / 라우터는 일반적으로 connection reset by peer오류 메시지 로 나타나는 TCP RST 패킷을 주입 하지만 재설정 패킷은 화재와 잊어 버리기 때문에 클라이언트와의 연결에 여전히 문제가있는 경우 패킷도 재설정하면 클라이언트가 연결이 여전히 유효하다고 생각합니다.
서버 자체에 예기치 않은 패킷을 자동으로 삭제하는 방화벽 정책이있을 수 있습니다. 이로 인해 서버는 연결이 닫힌 것으로 생각하지만 클라이언트는 그렇지 않을 때마다 클라이언트의 연결 재개 시도가 중단됩니다. 클라이언트는 계속 연결을 시도하지만 서버는 단지 이러한 패킷이 서버의 방화벽 상태에 속하는 라이브 연결이 없기 때문에 무시합니다.
Linux를 실행하고 있으므로 서버의 iptables/ ip6tables(또는 nft새로운 것을 사용하는 경우) 허용하고 떨어지는 것을 정확히 확인하십시오. 그것은 수 있도록하는 것은 매우 흔한 일 새 / 설정 / 관련 하는 TCP SSH 포트에 패킷을하지만, 하지 "무효"사람은 - 당신이 허용되지 않습니다 자동으로 모든 것을 포기하는 경우,이 일반적인 설치는 간단한 연결 문제 후 정지 이러한 종류의 원인이 될 수 .
TCP 또는 SSH 클라이언트 연결 유지 패킷에 대한 OpenSSH 옵션 중 하나를 사용하여 일정 기간 동안 활동이 없으면 연결을 닫도록 SSH 서버 자체가 구성 될 수 있습니다. 그 자체만으로도 무한 정지가 발생하지는 않지만 위에서 설명한 상태 중 하나에 놓일 수 있습니다.
ssh세션이 중단 된 상태가 된 후 자체적으로 "충분한"시간을 갖지 못할 수도 있습니다.
<Enter>하고 누르~.십시오. 마지막 ssh 명령을 반복하여 다시 연결하면됩니다 (예 : 위쪽 화살표 또는!!).