☰

부인 성명

tag-icon • tag-icon ssh gnu-screen session
부인 성명

불안정한 Wi-Fi 환경에서 SSH를 통해 서버에 연결해야 하는 경우가 많습니다. 서버에서는 스크린을 실행하므로 연결이 끊어지면 다시 연결하여 스크린 세션을 재개하고 중단한 부분부터 다시 시작할 수 있지만 연결 끊김은 여전히 ​​주요 시간 낭비입니다. 서버에 있는데 터미널 창이 멈추는 경향이 있습니다. 해당 탭을 종료하고 새 탭을 열고 서버에 다시 SSH를 통해 연결하고 스크린 세션을 다시 시작해야 합니다. 나는 서버에서 화면을 실행하고 로컬에서 화면을 실행하여 이것을 시도했습니다. 어느 쪽이든 연결이 끊어지면 정지되는 경향이 있습니다.

자동으로 다시 연결을 시도하고 세션을 계속 실행하여 수동으로 다시 연결할 필요가 없도록 화면과 유사한 기능이나 화면 자체를 가질 수 있는 방법이 있습니까? 종종 연결이 끊어지면 아주 짧은 시간 동안만 연결이 끊어진다고 생각합니다. 아마도 1초도 안 되는 시간일 것입니다.

저는 Ubuntu 14.04 LTS, MATE 에디션을 사용하고 있습니다. 감사해요

답변1

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

mosh연결하는 데 사용하는 안정적인 인터넷 연결을 사용하여 '점프' 서버를 설정한 다음 ssh관리하는 각 서버에 대한 세션을 가질 수 있습니다. 점프 서버 사용을 제안하는 이유는 mosh관리 중인 서버에 설치하고 싶지 않을 수도 있기 때문입니다 .

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

명확히 하기 위해 는 를 mosh대체하는 것이 아니라 screen입니다 ssh. 어떤 이유로든 클라이언트가 종료된 경우 자체적으로 세션에 다시 연결할 수 있는 방법을 제공하지 않기 screen때문에 함께 사용하는 것이 여전히 좋은 생각입니다 .mosh

답변2

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

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

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

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

ServerAliveInterval따라서 5로 설정하면 ssh네트워크가 15초 동안 끊어지면 자동으로 연결이 끊어집니다.

답변3

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

VPN을 통해 로컬 Arch 설치에서 다양한 원격 Ubuntu 서버에 연결합니다. 방금 리모컨에 연결되어 있는 동안 네트워크 케이블을 뽑아서 테스트했습니다. 세션이 중단되었지만 케이블을 다시 연결하자마자 원활하게 재개되었습니다.

그러나 라우터를 다시 시작하여 테스트했을 때 연결이 반환되지 않았습니다. 나는 그것이 네트워크가 다운된 시간과 관련이 있다고 가정하지만, 단 몇 초만 다운되면 다시 연결되는 것 같습니다.

관련이 있는 경우 다음을 사용하여 이 모든 작업을 수행합니다.terminator내 터미널 에뮬레이터로.

세 가지 모두 Ubuntu 리포지토리에서 사용할 수 있습니다.

sudo apt-get install tmux terminator byobu

tmux그러나 SSH 연결 끊김을 처리하는 데 더 byobu나은지 전혀 확신할 수 없습니다 . 내 경험상 짧은 연결 끊김으로 인해 다시 돌아오는 경우가 많다는 것만 알고 있습니다. 하지만 이는 내 구성의 다른 측면에 달려 있을 수 있습니다.

답변4

부인 성명

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 장치로 Wi-Fi에 연결하고 LAN의 다른 장치에 SSH 연결을 설정하고 ssh다른 쪽 끝에 연결이 작동하는지 확인한 다음(명령 실행 등) 클라이언트에서WiFi 연결을 끊었어요(인터페이스 구성 해제 원인: 더 이상 IP 주소 없음) SSH 세션에 더 많은 문자를 입력한 다음(물론 응답 없음) WiFi에 다시 연결했습니다. 실제로 재연결이 불량으로 인해 적어도 한 번은 실패했습니다. 신호 및 기타 요인을 확인하고 마침내 다시 연결되었습니다. 세션이 복구될 때까지 5초 정도 기다렸지만 ssh아무 일도 일어나지 않았기 때문에 키를 하나 더 눌렀고 세션이 ssh즉시 다시 활성화되었으며 연결 끊김 중에 입력했던 모든 키가 화면에 표시되었습니다. 명령줄.

보세요, sshOS가 뭔가 잘못되었다고 말할 때까지 TCP 네트워크 소켓에 쓰거나 읽습니다. 그리고 실제로 TCP는매우장기간의 연결 끊김을 견딜 수 있습니다.

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

내부적으로는 Linux TCP 스택이 점점 더 긴 지연 시간을 두고 메시지를 점진적으로 재시도합니다. 즉, 연결이 다시 돌아올 때 세션이 ssh다시 "활성화"되는 것처럼 보이기 전에 추가 지연이 발생할 수 있음을 의미합니다.

왜 가끔 깨지는가?

종종 무언가가 적극적으로 연결을 종료하는 원인이 됩니다.상당히 짧다TCP 스택이 허용할 수 있는 양보다 비활성 기간이 길어지고 해당 연결 상태를 클라이언트에 보고하지 못합니다 ssh.

유력한 후보자는 다음과 같습니다:

  1. 각 실시간 TCP 연결을 기억하기 위해 메모리를 사용해야 하는 방화벽 또는 NAT 라우터 - DOS 공격에 대한 최적화 및 일부 완화로 때로는잊다당신의 연결, 그리고조용히 무시하다기존 연결이 기억나지 않을 때 연결 도중에 있는 패킷은 유효하지 않게 보이기 때문입니다.

  2. 더 잘 작동하는 방화벽/라우터는 일반적으로 오류 메시지로 나타나는 TCP RST 패킷을 주입 connection reset by peer하지만 재설정 패킷은 실행 후 잊어버리므로 해당 순간 클라이언트에 대한 연결에 여전히 문제가 있어 연결이 끊어지는 경우 패킷도 재설정하면 클라이언트는 연결이 아직 살아 있다고 생각할 것입니다.

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

    Linux를 실행하고 있으므로 서버의 iptables/ ip6tables(또는 nft새로운 기능을 사용하는 경우)에서 허용하는 것과 삭제하는 것이 정확히 무엇인지 주의 깊게 확인하십시오. 허용하는 것이 매우 일반적입니다.새로운/확립된/관련된TCP SSH 포트의 패킷이지만~ 아니다"잘못된" 항목 - 허용되지 않는 모든 항목을 자동으로 삭제하는 경우 이 일반적인 설정으로 인해 잠시 연결 문제가 발생한 후 이러한 종류의 정지가 발생할 수 있습니다.

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

  5. ssh세션이 중단된 상태에 들어간 후 자체적으로 "정지 해제"할 충분한 시간을 주지 않을 수도 있습니다 .

관련 정보