ssh 시간 초과가 네트워크 위치에 따라 다른 이유는 무엇입니까?

15

집에서 회사 서버 (Fedora 10을 실행) 중 하나에 ssh 's 할 때 상당히 짧은 활동 기간 (5 분 정도) 후에 세션 시간이 초과됩니다. 나는 TcpKeepAlive클라이언트 측에서 사용하려고 시도했지만 아무런 효과가 없습니다.

내가 이해하지 못하는 것은 회사 LAN의 사무실에 있으면 시간 초과없이 하루 종일 세션을 비활성 상태로 둘 수 있으므로 동작이 내 위치에 의존하는 것 같습니다.

왜 이런 일이 일어나고 LAN에 있지 않을 때 시간 초과를 방지하는 방법이 있습니까? 도움이된다면 Mac OSX에서 터미널 클라이언트를 사용하고 있습니다.

업데이트 -Dave Drager가 ServerAliveInterval0이 아닌 세트를 사용하겠다는 제안이 TcpKeepAlive=no저에게 효과적 이었습니다. 다른 답변 중 일부와 관련 ClientAlive하여 Mac OSX SSH 클라이언트 는 ... 설정을 허용하지 않습니다.

— gareth_bowles
소스

6

이 문제에 대한 좋은 글이 여기 있습니다 .

그들은 추천한다 :

ssh -o TCPKeepAlive=yes

또는:

ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

그러나 직장 세션에서 세션과의 연결이 끊어지고 집에서 문제가없는 문제가 있습니다. 내 방화벽 (SonicWall)이 아마도 NAT로 인해 TCPKeepAlive를 사용하고 있다고 생각합니다.

내 SSH 클라이언트 인 SecureCRT에는 운 좋게도 "NO-OP"프로토콜에 대한 옵션이 있습니다. 기본적으로 서버에 아무 것도하지 않는 명령을 보냅니다. 이것을 수동으로 활성화하면 연결 상태를 유지할 수 있습니다. MacOSX 터미널 클라이언트의 그것과 비슷한 것이 확실하지 않습니다. 이 작성자 명령 행에 "NO-OP"를 구현하는 방법에 대한이.

마지막으로, Wireshark 또는 다른 스니퍼를 사용하여 실제 TCP 연결을보고 무슨 일이 일어나고 있는지 확인할 수 있습니다. 이것이 왜 가끔씩 연결이 끊어 지는지 알 수있는 마지막 방법입니다.

— 데이브 드래 거
소스

고마워, Dave-ServerAliveInterval 옵션이 훌륭하게 작동했습니다.

— gareth_bowles

@Dave 필자는 일부 서버 관리자가 (a) 보안 위험 또는 (b) 보증되지 않은 서버로드 일 수 있으므로이 관행에 눈살을 찌푸렸다 고 들었습니다. 이러한 우려 중 하나가 유효합니까, IYHO?

— Jonathan Day

이것은 클라이언트 엔드 포인트의 설정이므로 적대적인 환경에있는 경우 누군가를 스푸핑하는 데 추가 될 수 있지만 연결 보안에 영향을 미치지 않을 가능성이 큽니다. 나는 이것이 추가로드를 일으키는 것을 실제로 볼 수 없습니다.

— Dave Drager

@Dave :이 명령을 입력했지만 다음과 같은 사용법을 얻습니다. ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address :] 포트] [-e escape_char] [-F 구성 파일] [-F I pkcs11] [-i identity_file] [-L [bind_address :] port : host : hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o 옵션] [-p 포트] [-R [ bind_address :] 포트 : 호스트 : 호스트 포트] [-S ctl_path] [-W 호스트 : 포트] [-w local_tun [: remote_tun]] [user @] 호스트 이름 [명령]

— user1050619

이 수정은 PuTTY에도 적용되었습니다. 내가 설정 해야하는 유일한 옵션은 Keepalive : 15의 Connection-> Seconds에 있습니다. SSH 세션은 8 시간 이상 지속되어 (Comcast) 일반적으로 <30 분 안에 연결이 끊어졌습니다.

— Dan Dascalescu

2

아마도 집에서 연결할 때 짧은 시간 후에 TCP 세션을 닫는 방화벽을 통과하기 때문일 수 있습니다. 그러나 TcpKeepAlive는이를 피해야합니다. 클라이언트 쪽 또는 서버 쪽에서 TcpKeepAlive를 활성화 했습니까?

— 반지름
소스

클라이언트 쪽에서 ~ / .ssh / config의 TcpKeepAlive를 수행했습니다. 로컬 방화벽 문제를 해결할 것이라고 생각했지만 여전히 시간이 초과되었습니다.

— gareth_bowles

기본적으로 서버 측에서는 "on"이지만 sshd_config가 비활성화되어 있지 않은지 확인하십시오.

— 반경

일부 방화벽은 일정 시간 동안 유휴 상태가 아닌 경우에도 TCP 연결을 끊습니다.

— TomOnTime 2016 년

일부 방화벽은 일정 시간 동안 유휴 상태가 아닌 경우에도 TCP 연결을 끊습니다. 이를 감지하는 방법은 일관되게 연결이 끊어 졌는지 확인하는 것입니다.

— TomOnTime 2016 년

TCPKeepAlive no, ClientAliveInterval 300, ClientAliveCountMax 3

— Matt Simmons

2

내 Comcast 연결에서 항상 이것을 얻습니다. 문제는 SSH 클라이언트의 연결 유지 간격이 네트워크 경로에 구성된 시간 초과에 비해 너무 길다는 것입니다. Linux를 사용하는 경우 ServerAliveInterval및 ServerAliveCounter값을 기본값보다 낮게 수정할 수 있습니다 . 이 값은 초 단위로 설정됩니다. 시스템 전체 구성 파일은 (일반적으로)에 /etc/ssh/ssh_config있습니다. 이 두 AND를 설정하면 TcpKeepAlive연결을 유지하는 데 도움이됩니다.

— sysadmin1138
소스

1

반경이 말했듯이 일부 상태 전체 방화벽은 특정 (일반적으로 구성 가능한) 시간이 지나면 연결을 '잊어'연결에 대한 추가 통신을 허용하지 않습니다. 그들은 TCP SYN으로 연결이 시작될 것으로 예상합니다 (여기서는 SSH 통신을 참조하십시오).

또 다른 가능성이 있습니다. 집과 사무실 사이의 네트워크 경로에 손실이있을 수 있습니다 (패킷 종류). SSH 클라이언트에서 입력하려고 할 때 링크가 잠시 정지 된 경우 클라이언트가 포기하고 실패 할 수 있습니다.

클라이언트의 Keepalive 구성은 여기서 첫 번째 경우를 처리하지만 두 번째 경우에는 도움이되지 않습니다. 방화벽은 일반적으로 사무실 주변에 있으므로 구성 할 수 있습니다. 그것은 또한 첫 번째 포인트에 도움이 될 것입니다.

간헐적 인 링크 손실이 있는지 확인하기 위해 클라이언트 시스템의 백그라운드에서 'ping'을 활성 상태로 유지할 수 있습니다.

— 니크
소스

0

~/.ssh/config파일 에서 다른 사람이 제안한 설정을 기본값으로 추가 할 수도 있으므로 ssh연결을 시작할 때마다 해당 설정 을 전달하지 않아도됩니다 .

nano ~/.ssh/config 그리고 추가하십시오 :

TCPKeepAlive=no
ServerAliveInterval=15

— 댄 다 스케 스쿠
소스