다음을 사용하여 볼 수 있습니다 mosh.https://mosh.org/

안정적인 인터넷 연결을 통해 "점프" 서버를 설정하여 mosh연결한 다음 ssh관리하는 각 서버와 세션을 설정할 수 있습니다. 점프 서버 사용을 권장하는 이유는 아마도 mosh관리 중인 서버에 점프 서버를 설치하고 싶지 않을 것이기 때문입니다 .

또 다른 장점 mosh은 TCP가 아닌 UDP를 기반으로 하고, WiFi 연결에서 모바일 인터넷 연결로 등 IP 주소가 변경되어도 세션이 유지된다는 점입니다.

분명히 말하면 대체품 mosh이 아닙니다 screen. 어떤 이유로 클라이언트가 종료된 경우 기본적으로 세션에 다시 연결하는 방법을 제공하지 않기 때문에 ssh이를 사용하는 것이 좋습니다 .screenmosh

SSH의 ServerAlive옵션을 사용하여 연결 실패 시기를 감지하세요.

ServerAliveCountMax
ssh(1)가 서버로부터 메시지를 다시 받지 못하는 경우 보낼 수 있는 서버 활성 메시지 수(아래 참조)를 설정합니다. 서버 활동 메시지를 보내는 동안 이 임계값에 도달하면 ssh는 서버와의 연결을 끊고 세션을 종료합니다. 서버 활동 메시지의 사용은 TCPKeepAlive(아래)와 매우 다르다는 점에 유의하는 것이 중요합니다. 서버 활동 메시지는 스푸핑될 수 없도록 암호화된 채널을 통해 전송됩니다. TCPKeepAlive 활성화된 TCP keepalive 옵션은 스푸핑 가능합니다. 서버 활동성 메커니즘은 클라이언트나 서버가 연결이 비활성화되는 시기를 알아야 하는 경우에 유용합니다.

기본값은 3입니다. 예를 들어, ServerAliveInterval(아래 참조)이 15로 설정되고 ServerAliveCountMax가 기본값으로 남아 있는 경우 서버가 응답하지 않으면 약 45초 후에 ssh의 연결이 끊어집니다.

ServerAliveInterval
서버로부터 데이터가 수신되지 않는 경우 ssh(1)가 암호화된 채널을 통해 메시지를 보내 서버에 응답을 요청하는 시간 초과 간격(초)을 설정합니다. 기본값은 0이며, 이는 이러한 메시지가 서버로 전송되지 않음을 의미합니다.

ServerAliveInterval그래서 5로 설정하면 ssh15초 동안 네트워크가 다운되면 연결이 자동으로 끊어집니다.

나는 사용해왔다tmux내 경험에 따르면 몇 년 동안 자동으로 다시 연결됩니다. 적어도 상대적으로 짧은 시간 동안만 연결이 실패하는 경우입니다. 참고로 제가 실제로 사용하는 것은byobutmux를 백엔드로 사용하세요. 이 견고함이 둘 다의 특징인지 tmux아니면 byobu둘의 조합인지는 모르겠지만 두 가지를 모두 시도해 보는 것이 좋습니다.

VPN을 통해 로컬 Arch 설치에서 다양한 원격 Ubuntu 서버로 연결합니다. 방금 리모컨에 연결된 상태에서 네트워크 케이블을 뽑아서 테스트해봤습니다. 세션이 중단되었지만 케이블을 다시 연결하면 원활하게 재개됩니다.

그런데 테스트를 위해 라우터를 다시 시작했는데 연결이 복원되지 않았습니다. 네트워크가 얼마나 오래 끊겼는지와 관련이 있는 것 같은데, 몇 초만 끊어지면 다시 연결되는 것 같습니다.

관련이 있다면 나는 사용할 것이다terminator내 터미널 에뮬레이터로.

세 가지 모두 Ubuntu 저장소에서 찾을 수 있습니다.

sudo apt-get install tmux terminator byobu

그러나 나는 ssh 연결 끊김을 처리하는 데 전혀 확신이 없거나 더 나은 것이 없습니다 tmux. byobu내가 아는 것은 내 경험상 짧은 연결 끊김에서 종종 복구된다는 것입니다. 하지만 이는 내 구성의 다른 측면에 따라 달라질 수 있습니다.

부인 성명

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다시 연결하는 동안 사람이 감지할 수 없는 순간에 충돌이 발생하면 클라이언트에 스크립트를 전달하는 대신 스크립트를 종료하게 될 수 있으므로 ^C연결이 중단된 것으로 의심되면 그러지 마십시오. ^C너무 열심히 으깬다.

가장 간단한 추가 소프트웨어 솔루션

이 프로그램을 사용해 볼 수 있습니다자동 SSH, Ubuntu 패키지 저장소에서 사용할 수 있어야 합니다.

소스에서 빌드하거나 감사해야 하는 경우 종속성으로 추가 라이브러리 없이 컴파일하고 위의 해킹보다 더 지능적으로 연결 활성 상태를 확인하는 것으로 보이는 별도의 C 프로그램입니다.그리고rscreen또한 자동으로 추가되는 편리한 스크립트 명령도 함께 제공됩니다 screen.

세부 사항

ssh일반적으로 복원하는 방법

확인을 위해 확인하지 않고 말하고 싶지 않기 때문에 답변하기 전에 몇 가지 테스트를 수행했습니다.

Linux 장치를 사용하여 WiFi에 연결하고, LAN의 다른 장치에 SSH 연결을 설정하고, ssh다른 쪽 끝에 작동하는 연결을 확인한 다음(명령 실행 등) 클라이언트에서WiFi 연결 끊기(인터페이스 구성 해제 원인: 더 이상 IP 주소 없음) SSH 세션에 더 많은 문자를 입력한 다음(물론 응답 없음) WiFi에 다시 연결합니다. 실제로 신호 버그 및 기타 요인으로 인해 다시 연결이 한 번 이상 실패했습니다. 그리고 마침내 다시 연결되었습니다. 세션이 ssh재개될 때까지 5초 정도 기다렸는데 아무 일도 일어나지 않았기 때문에 다른 키를 눌렀더니 세션이 ssh즉시 다시 활성화되었고 연결이 끊어진 동안 입력한 모든 키가 명령줄에 나타났습니다.

sshOS가 뭔가 잘못되었다고 말할 때까지 TCP 네트워크 소켓에서 쓰기/읽기만 하는 반면 TCP는 실제로매우장기간의 연결 중단을 견딜 수 있습니다.

기본 커널 설정을 사용하여 자체 장치에 남겨두면 Linux의 TCP 스택은 연결이 끊어졌다고 선언하고 오류를 보고하기 전에 몇 분 동안 완전히 침묵하는 연결을 기꺼이 허용합니다. ssh마침내 포기하면 우리는 이야기하고 있습니다. 대략 30분 정도, 또는 최소한 1초 또는 1분 동안 지속되는 연결 중단을 극복할 수 있을 만큼 충분히 긴 시간입니다.

그러나 그 뒤에서 Linux TCP 스택은 점점 더 긴 지연을 사용하여 메시지를 점차적으로 재시도합니다. 즉, 연결이 다시 복구되면 ssh세션이 다시 "활성"으로 나타나기 전에 추가 지연이 나타날 수 있습니다.

가끔 왜 이런 일이 일어나는지

종종 어떤 이유로 인해 잠시 후 연결이 끊어지는 경우가 있습니다.대폭 단축연결 상태가 클라이언트에 보고되기 전에 TCP 스택이 허용할 수 있는 것보다 더 많은 비활성 시간이 있습니다 ssh.

가능한 후보는 다음과 같습니다.

1. 방화벽이나 NAT 라우터는 각각의 실시간 TCP 연결을 기억하기 위해 메모리를 사용해야 합니다. DOS 공격에 대한 최적화와 완화를 위해 때로는잊다그럼 네 연결조용히 무시후속 패킷은 기존 연결을 기억하지 못하는 경우 연결 중간에 있는 패킷이 유효하지 않은 것처럼 보이기 때문입니다.

2. 더 나은 성능의 방화벽/라우터는 일반적으로 오류 메시지로 나타나는 TCP RST 패킷을 삽입 connection reset by peer하지만 재설정 패킷은 설정되고 잊어버리므로 해당 시점에 클라이언트 연결에 여전히 문제가 있고 재설정 패킷도 삭제하는 경우 클라이언트는 연결이 여전히 존재한다고 생각할 것입니다.

3. 섬기는 사람그 자체예기치 않은 패킷을 자동으로 삭제하는 방화벽 정책이 있을 수 있습니다. 서버는 연결이 닫혔다고 생각하지만 클라이언트는 그렇지 않을 때마다 클라이언트의 연결 복구 시도가 중단됩니다. 클라이언트는 계속 연결을 시도하지만 서버는 이를 무시합니다. 서버의 방화벽 상태에서는 이러한 패킷이 속한 라이브 연결이 존재하지 않기 때문입니다.

   Linux를 실행하고 있으므로 서버의 iptables/ ip6tables(또는 nft새로운 것을 사용하는 경우)를 다시 확인하여 정확히 무엇을 허용하거나 생략하는지 확인하십시오. 허용하는 것이 일반적이다새로운/확립된/관련된TCP SSH 포트의 패킷이지만아니요"잘못됨" - 이 일반적인 설정은 허용되지 않는 모든 콘텐츠를 자동으로 제거하는 경우 잠시 연결 문제가 발생한 후 정지를 유발할 수 있습니다.

4. TCP 또는 SSH 클라이언트 연결 유지 패킷의 OpenSSH 옵션 중 하나를 사용하여 일정 기간 동안 활동이 없으면 연결을 닫도록 SSH 서버 자체를 구성할 수 있습니다. 그 자체로는 무기한 정지가 발생하지 않지만 위의 상태 중 하나에 빠질 수 있습니다.

5. ssh일시 중단된 상태로 들어간 후 세션 자체를 "일시 중단 해제"할 충분한 시간을 제공하지 않았을 수 있습니다.