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
Сойди с моей лужайки
источник
Что ssh -v username@sub.domain.comпоказывает?
Джеймс Снерингер
Я обновил основной вопрос. Также сервер должен запросить пароль, для входа в систему не нужны ssh-ключи.
Сойди с моей лужайки
Вы изменили какие-либо настройки по умолчанию в PuTTY?
Крууг
Кроме того, вы пробовали user@domain.com? Оставь в покое sub.
Крууг
1
Вы используете сборку CentSSY OpenSSH, которая подразумевает, что ваша система интегрирована в AD. Active Directory использует Kerberos, и OpenSSH жалуется, что не может найти Kerberos KDC, поэтому он выручает. Как ты /etc/krb5.confвыглядишь?
Джеймс Снерингер

Ответы:

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

Ни Ciphers, ни HostKeyAlgorithms не работали сами по себе, почти наверняка MAC поставили меня в тупик, чтобы заставить это работать, но я не уверен, что потратил много часов на решение этой проблемы. Я надеюсь, что это может, по крайней мере, помочь кому-то еще.


Изменить: Это (иногда) решает проблему, но, вероятно, не так, как вы хотите. --jcwenger

Эти настройки, по-видимому, (как побочный эффект) изменяют способ, которым ssh-клиент испускает пакеты, и могут вызывать его выделение меньших пакетов. Это не решает проблему; это просто иногда делает так, что реальная проблема (фрагментация MTU, взаимодействующая с глупыми реализациями правил брандмауэра) не возникает.

Правильное решение - установить MTU, который работает от начала до конца.

Необходимость вручную установить меньшее значение MTU, чтобы гарантировать отсутствие фрагментации, не является чем-то более чистым (нам, как пользователям, не нужно вручную предпринимать шаги для противодействия проблемам, вызванным нашими сетевыми командами) ... но это по крайней мере напрямую фактическая причина надежным и доказуемым способом, а не испорченные настройки шифра SSH таким образом, что, как побочный эффект, когда звезды совпадают, случается, что это не делает большие пакеты.

Кроме того, SSH не единственное, что делает большие пакеты. Установка MTU предотвращает то же самое от других протоколов.

mattw
источник
5
спасибо, в моем случае только последняя строка MACs hmac-md5,hmac-sha1,hmac-ripemd160была достаточно
Tombart
У меня была проблема с github - git pull / git push - ничего не произошло. Попробовал ssh -T -v git@github.com и получил такую ​​же ошибку. Использовал это, чтобы решить это. Спасибо!
Джейсон
У меня была похожая проблема, и я попробовал это решение. Одним из побочных эффектов является то, что любое соединение с известным хостом будет обвинять в смене ключа хоста.
lfagundes
Все эти патчи лечат симптом, а не причину. Уменьшение размера шифра может предотвратить фрагментацию MTU ... что является настоящей проблемой, о которой рассказано в @jagguli ниже.
jcwenger
Добавление строки "HostKeyAlgorithms ssh-rsa, ssh-dss" в / etc / ssh / ssh_config устранило мою проблему с невозможностью SSH подключиться к модему Zyxel. Все остальные строки в вышеупомянутом tetbox уже были на моей машине. Спасибо за совет!
Джефф Райт
6

Это исправило проблему MTU без необходимости жесткого кодирования какого-либо значения, это исправит его для ssh и любого другого протокола, на который это влияет. От имени пользователя root запустите следующее:

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

Вы можете прочитать больше о проблеме и решении здесь и здесь .

Марван Алсаббах
источник
Объяснение: «Получается, что файловая система ядра / proc предоставляет простой способ включить и отключить TCP MTU Probing, изменив значение в« file »/ proc / sys / net / ipv4 / tcp_mtu_probing. Значение 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 имя пакета.

LawrenceC
источник
Это не исправило это :(
Сойди с моей лужайки
1

Я смог решить эту проблему, заставив использовать IPv4 с

ssh -4 username@host.xyz

Так как я на Mac, я не знаю, какие здесь настройки MTU или как их изменить, но подумал, что другие могут извлечь из этого пользу.

Бруно Ким
источник
Эта опция заставляет ssh использовать только IP4. Я тоже на Mac, и это не решило мою проблему.
Jorj
0

У меня появилась эта проблема сегодня, в Windows (ssh распространяется вместе с Git) и Ubuntu.

Похоже, это ошибка в OpenSSH, есть проблема в LauchPad .

У меня это работало на Windows, форсируя шифр 3des-cbc и ключ на Ubuntu.

LawfulHacker
источник
0

Немного некро, но я столкнулся с этим в 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

Kachunkachunk
источник
-2

ssh -c aes256-ctr работает нормально;

Удара
источник
Почему вы считаете, что эта команда решит проблему?
Скотт