Когда я пытаюсь 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
показывает?user@domain.com
? Оставь в покоеsub
./etc/krb5.conf
выглядишь?Ответы:
Решение найдено для меня по следующему URL: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/
Он даже довольно хорошо объясняет, что происходит.
В конечном итоге я добавил следующее в / etc / ssh / ssh_config:
Ни Ciphers, ни HostKeyAlgorithms не работали сами по себе, почти наверняка MAC поставили меня в тупик, чтобы заставить это работать, но я не уверен, что потратил много часов на решение этой проблемы. Я надеюсь, что это может, по крайней мере, помочь кому-то еще.
Изменить: Это (иногда) решает проблему, но, вероятно, не так, как вы хотите. --jcwenger
Эти настройки, по-видимому, (как побочный эффект) изменяют способ, которым ssh-клиент испускает пакеты, и могут вызывать его выделение меньших пакетов. Это не решает проблему; это просто иногда делает так, что реальная проблема (фрагментация MTU, взаимодействующая с глупыми реализациями правил брандмауэра) не возникает.
Правильное решение - установить MTU, который работает от начала до конца.
Необходимость вручную установить меньшее значение MTU, чтобы гарантировать отсутствие фрагментации, не является чем-то более чистым (нам, как пользователям, не нужно вручную предпринимать шаги для противодействия проблемам, вызванным нашими сетевыми командами) ... но это по крайней мере напрямую фактическая причина надежным и доказуемым способом, а не испорченные настройки шифра SSH таким образом, что, как побочный эффект, когда звезды совпадают, случается, что это не делает большие пакеты.
Кроме того, SSH не единственное, что делает большие пакеты. Установка MTU предотвращает то же самое от других протоколов.
источник
MACs hmac-md5,hmac-sha1,hmac-ripemd160
была достаточноЭто сработало для меня ...
http://fred-web.blogspot.com.au/2012/10/ssh-hang-on-expecting.html
источник
Это исправило проблему MTU без необходимости жесткого кодирования какого-либо значения, это исправит его для ssh и любого другого протокола, на который это влияет. От имени пользователя root запустите следующее:
Вы можете прочитать больше о проблеме и решении здесь и здесь .
источник
Сделал некоторые глядя и нашел следующее предложение здесь :
Убедитесь, что следующая строка в вашем / etc / ssh / ssh_config (НЕ sshd_config) НЕ закомментирована:
Вы также можете попытаться вернуть этот файл к значению по умолчанию и повторить попытку, то есть удалить и переустановить
openssh-client
IIRC имя пакета.источник
Измените сетевой интерфейс MTU, чтобы решить его. Это ошибка для Ubuntu 14.04.
Это сработало для меня:
Или:
ssh не может подключиться к VPN-хосту - зависает при ожидании SSH2_MSG_KEX_ECDH_REPLY
источник
Я смог решить эту проблему, заставив использовать IPv4 с
Так как я на Mac, я не знаю, какие здесь настройки MTU или как их изменить, но подумал, что другие могут извлечь из этого пользу.
источник
У меня появилась эта проблема сегодня, в Windows (ssh распространяется вместе с Git) и Ubuntu.
Похоже, это ошибка в OpenSSH, есть проблема в LauchPad .
У меня это работало на Windows, форсируя шифр 3des-cbc и ключ на Ubuntu.
источник
Немного некро, но я столкнулся с этим в OpenSSH_7.8p1, в Linux. Внедрение маркировки DSCP в последних выпусках OpenSSH, похоже, срабатывает в VMware NAT (упомянуто, что в следующих ссылках хорошо работает мостовая сеть).
Вы можете обойти это сейчас, добавив / установив следующее в / etc / ssh / ssh_config :
Дополнительные факторы могут заключаться в том, что PuTTY (или другие отдельные клиенты SSH), возможно, не сталкиваются с проблемой с того же хоста, и ваш MTU пока что проверяет. то есть:
Эти сообщения были особенно полезны и привели меня туда, где я должен был быть:
https://groups.google.com/forum/#!topic/opensshunixdev/5FK67SCpPg8 https://groups.google.com/forum/#!topic/opensshunixdev/uNd48nGOe7A
источник
ssh -c aes256-ctr работает нормально;
источник