Назад | Перейти на главную страницу

ssh внезапно перестал работать на Mac

Каждый день я просыпаюсь и проверяю, что мои серверы работают нормально, я использую свой Mac для подключения к некоторым машинам Ubuntu и некоторым машинам freebsd.

Но сегодня, когда я попробовал, произошло нечто странное:

$ ssh -v -p 41900 someserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to someserver.com [95.166.12.75] port 41900.
debug1: Connection established.
debug1: identity file /Users/someuser/.ssh/identity type -1
debug1: identity file /Users/someuser/.ssh/id_rsa type -1
debug1: identity file /Users/someuser/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503
debug1: match: OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[someserver.com]:41900' is known and matches the RSA host key.
debug1: Found key in /Users/someuser/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/someuser/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /Users/someuser/.ssh/identity
debug1: Trying private key: /Users/someuser/.ssh/id_rsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.

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

[ОБНОВИТЬ]

Попробовав положить ноутбук в сумку и перейти к другой сети, я пришел к выводу, что это проблема сети, и мои инстинкты подтвердились, когда я узнал, что мой интернет-провайдер обанкротился.

Однако возникает новый вопрос, поскольку я пробовал войти в другую сеть с помощью vpn, но возникла та же проблема, может ли кто-нибудь объяснить, как проблема маршрутизации в одной сети может повлиять на соединение vpn - иначе все работает нормально?

Может ли кто-нибудь сказать мне, что случилось с моим ssh-клиентом? И, возможно, даже как я это исправлю?

Это скорее проблема сервера, чем клиента. Соединение установлено и аутентифицировано, и теперь клиент ждет, пока сервер начнет сеанс (что, как мне кажется, означает разветвление sshd процесс для пользователя и запуск оболочки пользователя). Это может быть вызвано некоторой нагрузкой на сервер (например, памятью и дисковым вводом-выводом).

Убедитесь, что другие службы, предоставляемые сервером, работают - это может подтвердить наличие проблем на сервере. Также попробуйте подключиться из другого сетевого местоположения, чтобы исключить странные проблемы с сетью.

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

Проверь это http://www.openssh.com/txt/release-5.1

  • Добавлено глобальное расширение запроса no-more-sessions@openssh.com, которое отправляется из ssh (1) в sshd (8), когда клиент знает, что он никогда не запросит другой сеанс (т. Е. Когда мультиплексирование сеансов отключено). Это позволяет серверу запрещать дальнейшие запросы сеанса и прекращать сеанс в случаях, когда клиент был захвачен.