SSH працює в шпаклівці, але не в терміналі

Коли я намагаюся сша це в терміналі: ssh username@sub.domain.comя отримую таку помилку:
Connection closed by 69.163.227.82

Коли я використовую шпаклівку, я можу підключитися до сервера. Чому це відбувається, і як я можу змусити це працювати в терміналі?

ssh -v ім'я користувача@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

Для мене знайдено рішення за такою 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, те ж саме відбувається і з іншими протоколами.

Це працювало для мене ...

ifconfig eth0 mtu 576

http://fred-web.blogspot.com.au/2012/10/ssh-hang-on-expecting.html

Це виправило проблему MTU, не потребуючи жорсткого кодування якогось значення, воно виправить її за ssh та будь-яким іншим протоколом, виконаним цим. Як root виконайте такі дії:

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

Більше про проблему та рішення ви можете прочитати тут і тут .

Зробив деякі дивлячись і знайшов таку пропозицію тут :

Спробуйте переконатися, що наступний рядок у вашому / etc / ssh / ssh_config (NOT sshd_config) НЕ коментується:

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

Ви також можете спробувати повернути цей файл до типового і повторити спробу, тобто видалити та перевстановити openssh-clientназву пакета IIRC.

Змініть мережевий інтерфейс MTU, щоб вирішити його. Це помилка для ubuntu 14.04.

Це працювало для мене:

sudo ip li set mtu 1200 dev wlan0

Або:

sudo ifconfig wlan0 mtu 1200

ssh не вдається підключитися до хоста VPN - зависає при "очікуванні SSH2_MSG_KEX_ECDH_REPLY"

Мені вдалося вирішити цю проблему, змусивши використовувати IPv4 з

ssh -4 username@host.xyz

Оскільки я на Mac, я не знаю, які тут налаштування MTU або як їх змінити, але я вважав, що від цього можуть отримати користь інші.

Я почав мати цю проблему сьогодні, в Windows (ssh поширюється разом з Git) та Ubuntu.

Схоже, це помилка на OpenSSH, на LauchPad є проблема .

Він працював для мене в Windows, примушуючи шифр 3des-cbc і ключ на Ubuntu.

Тут трохи некро, але я стикався з цим на OpenSSH_7.8p1, в Linux. Впровадження маркування DSCP в останніх випусках OpenSSH, схоже, активізується у 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

ssh -c aes256-ctr працює чудово;