SSH는 퍼티에서 작동하지만 터미널에서는 작동하지 않습니다.

24

터미널에서 이것을 ssh하려고 ssh username@sub.domain.com하면 다음 오류가 발생합니다.
Connection closed by 69.163.227.82

퍼티를 사용하면 서버에 연결할 수 있습니다. 왜 이런 일이 발생하며 어떻게 터미널에서 작동하게 할 수 있습니까?

ssh -v username@sub.domain.com

OpenSSH_6.0p1 (CentrifyDC build 5.1.0-472) (CentrifyDC build 5.1.0-472), OpenSSL 0.9.8w 23 Apr 2012
debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to sub.domain.com [69.163.227.82] port 22.
debug1: Connection established.
debug1: identity file /home/ryannaddy/.ssh/id_rsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_rsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 69.163.227.82
linux  ssh  terminal  putty 
— 내 마당에서 나가
소스
무엇을 ssh -v username@sub.domain.com보여줍니까?
— James Sneeringer
주요 질문을 업데이트했습니다. 또한 서버는 암호를 요청해야하며 로그인하는 데 필요한 ssh 키가 없습니다.
— 내 잔디밭
PuTTY에서 기본 설정을 변경 했습니까?
— Kruug
또한 시도 user@domain.com했습니까? 를 제외하십시오 sub.
— Kruug
1
Centrify의 OpenSSH 빌드를 사용하고 있습니다. 이는 시스템이 AD 통합되었음을 의미합니다. Active Directory는 Kerberos를 사용하고 있으며 OpenSSH는 Kerberos KDC를 찾을 수 없다고 불평하고 있습니다. 당신은 /etc/krb5.conf어떻게 생겼습니까?
— James Sneeringer

답변:

23

다음 URL을 통해 해결책을 찾았습니다. http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

심지어 무슨 일이 일어나고 있는지 잘 설명해줍니다.

궁극적으로 / etc / ssh / ssh_config에 다음을 추가했습니다.

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

암호 또는 HostKeyAlgorithms는 자체적으로 작동하지 않았으므로 MAC 이이 작업을 수행하기 위해 나를 맨 위에 올려 놓았지만 확실하지는 않습니다.이 문제를 해결하는 데 많은 시간을 투자했습니다. 나는 이것이 적어도 다른 누군가를 도울 수 있기를 바랍니다.

편집 : 이것은 (때로는) 문제를 해결하지만 원하는 방식으로 해결하지 못할 수도 있습니다. --jcwenger

이 설정은 ssh 클라이언트가 패킷을 내보내는 방식을 변경하여 부작용으로 나타나고 더 작은 패킷을 내보내도록합니다. 이것은 문제를 해결하지 않습니다. 때로는 실제 문제 (어리석은 방화벽 규칙 구현과 상호 작용하는 MTU 조각화)가 발생하지 않도록하기도합니다.

올바른 해결책은 끝까지 작동하는 MTU를 설정하는 것입니다.

조각화가 발생하지 않도록 MTU를 수동으로 더 작은 숫자로 설정 해야하는 것은 그리 깔끔 하지 않습니다 (사용자는 네트워크 팀으로 인한 문제를 해결하기 위해 수동으로 조치를 취할 필요가 없기 때문에). 그러나 최소한 직접 처리하는 것은 아닙니다 별이 정렬되면 부작용으로 인해 큰 패킷을 만들지 않도록 SSH의 암호 설정을 강화하는 대신 신뢰할 수 있고 입증 가능한 방식으로 실제 원인.

또한 SSH가 큰 패킷을 만드는 유일한 것은 아닙니다. MTU를 설정하면 같은 일이 다른 프로토콜에서도 발생하지 않습니다.

— 매트
소스
5
고마워, 내 경우에는 마지막 줄 MACs hmac-md5,hmac-sha1,hmac-ripemd160만으로 충분
— Tombart
github에 문제가있었습니다-git pull / git push-아무 일도 일어나지 않았습니다. ssh -T -v git@github.com을 시도했지만 동일한 오류가 발생했습니다. 이것을 해결하는 데 사용했습니다. 고맙습니다!
— Jason
나는 비슷한 문제가 있었고이 해결책을 시도했다. 한 가지 부작용은 알려진 호스트에 대한 모든 연결이 호스트 키 변경을 초래한다는 것입니다.
— lfagundes
이 모든 패치는 증상이 아닌 원인을 치료합니다. 암호 크기를 줄이면 MTU 조각화를 막을 수 있습니다. 이것은 아래의 @jagguli에 의해 야기되는 실제 문제입니다.
— jcwenger
"HostKeyAlgorithms ssh-rsa, ssh-dss"라인을 / etc / ssh / ssh_config에 추가하면 Zyxel 모뎀에 SSH를 연결할 수없는 문제가 해결되었습니다. 위의 tetbox의 다른 모든 줄은 이미 내 컴퓨터에 있습니다. 팁 주셔서 감사합니다!
— Jeff Wright
6

이로 인해 일부 값을 하드 코딩하지 않고도 MTU 문제가 해결되었으며 ssh 및 이로 인해 영향을받는 다른 프로토콜에 대해 MTU 문제가 해결되었습니다. 루트로 다음을 실행하십시오.

echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

여기 및 여기 에서 문제 및 해결 방법에 대한 자세한 내용을 읽을 수 있습니다 .

— 마르 완 알 사바 그
소스
설명 : "커널 / proc 파일 시스템은 'file'/ proc / sys / net / ipv4 / tcp_mtu_probing의 값을 변경하여 TCP MTU 프로빙을 쉽게 활성화 및 비활성화 할 수있는 방법을 제공합니다. 값 0은 비활성화 됨 ; 1 = 블랙홀 라우터가 감지되면 활성화되고 2 = 항상 활성화됩니다. "
— Jorj
1

일부는 여기 에서 다음 제안을 찾았습니다 .

/ etc / ssh / ssh_config (sshd_config 아님)에서 다음 줄이 주석 처리되지 않았는지 확인하십시오.

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

또한 해당 파일을 기본값으로 되돌리고 다시 시도 할 수 있습니다. 즉, openssh-clientIIRC를 제거하고 패키지 이름을 다시 설치 하십시오.

— 로렌스 C
소스
그것은 해결되지 않았다 :(
— 내 잔디밭
1

IPv4를 강제로 사용 하여이 문제를 해결할 수있었습니다.

ssh -4 username@host.xyz

Mac을 사용하고 있기 때문에 여기 MTU 설정이 무엇인지 또는 변경 방법을 모르지만 다른 사람들이이 혜택을 볼 수 있다고 생각했습니다.

— 브루노 킴
소스
이 옵션은 ssh가 IP4 만 사용하도록합니다. 나는 Mac에도 있고 내 문제를 해결하지 못했습니다.
— Jorj
0

여기에 약간의 괴로움이 있지만 Linux의 OpenSSH_7.8p1 에서이 문제가 발생했습니다. 최근 OpenSSH 릴리스에서 DSCP 마킹이 VMware NAT에서 트립되고있는 것으로 보입니다 (아래 링크에서 브리지 네트워킹이 양호 함).

/ etc / ssh / ssh_config에 다음을 추가 / 설정하여이 문제를 해결할 수 있습니다 .

IPQoS lowdelay throughput

PuTTY (또는 다른 별개의 SSH 클라이언트)에 동일한 호스트에서 문제가 발생하지 않았으며 지금까지 MTU가 체크 아웃했다는 추가 요인이 있습니다. 즉 :

ping -M do -s 1472 your-ssh-server

이 게시물은 특히 도움이되었고 내가 필요한 곳에 도착했습니다.

https://groups.google.com/forum/#!topic/opensshunixdev/5FK67SCpPg8 https://groups.google.com/forum/#!topic/opensshunixdev/uNd48nGOe7A

— 카춘 카춘
소스
-2

ssh -c aes256-ctr은 잘 작동합니다.

— 우 다라
소스
이 명령으로 문제가 해결 될 것이라고 생각하는 이유는 무엇입니까?
— Scott
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.