SSH работает в замазке, но не в терминале

Когда я пытаюсь 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

Решение найдено для меня по следующему 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

Ни Ciphers, ни 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 (НЕ sshd_config) НЕ закомментирована:

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

Вы также можете попытаться вернуть этот файл к значению по умолчанию и повторить попытку, то есть удалить и переустановить openssh-clientIIRC имя пакета.

Измените сетевой интерфейс 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 работает нормально;