У меня проблемы с подключением к удаленному хосту через SSH. Я сузил проблему до моего локального хоста только поскольку другие клиенты каждый раз устанавливают номинальные (быстрые и стабильные) подключения.
Попытка подключиться к remotehost.example.net из localhost через SSH будет время ожидания для всех, кроме примерно 1 из 10 попыток (здесь он зависает, а затем время ожидания):
515 chris@localhost ~ $ ssh -vvv remotehost-root
OpenSSH_6.4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/chris/.ssh/config
debug1: /home/chris/.ssh/config line 43: Applying options for remotehost-root
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotehost.example.net [123.123.123.123] port 12345.
^C
localhost это современная система Arch:
517 chris@localhost ~ $ uname -a
Linux localhost 3.12.1-1-ARCH #1 SMP PREEMPT Thu Nov 21 08:18:42 CET 2013 x86_64 GNU/Linux
И я использую файл конфигурации SSH для псевдонима remotehost следующим образом:
521 chris@localhost .ssh $ cat ~/.ssh/config
...
host remotehost-root
HostName remotehost.example.net
User root
Port 12345
IdentityFile ~/.ssh/remotehost-root.id_rsa
...
Это недавняя проблема, но, к сожалению, я не припомню, чтобы вносил изменения во что-либо важное. Я не уверен, что проверять.
Может стоит отметить, что это влияет все SSH-соединения (например, git over ssh и SFTP), а не только SSH-инструмент командной строки.
У меня нет проблем с доступом remotehost.example.net по любому другому протоколу (например, HTTP, HTTPS, BitTorrent и т. Д.).
Единственная активная / раскомментированная строка в /etc/ssh/ssh_config является:
ServerAliveInterval 120
Где еще я могу посмотреть? Какие еще инструменты отладки я могу использовать (все, что я могу придумать, это запустить ssh -vvv)?
Я пробовал бежать tcpdump на удаленном хосте при попытке подключения, но не мог понять, как фильтровать пакеты из оболочки Бег tcpdump таким образом, бесконечный цикл лишает себя всякой полезной диагностики.
ОБНОВЛЕНИЕ 1: Стоит отметить, что мне удалось воспроизвести это поведение на втором SSH-хосте, а также на IRC-сервере, тем самым доказав (на мой взгляд), что это проблема полностью в некоторой конфигурации на моем локальном хосте.
ОБНОВЛЕНИЕ 2: Также стоит отметить, что хотя у моего локального хоста проблемы с этими исходящими соединениями, у других клиентов (в том числе на одном и одном в моей локальной сети) нет никаких проблем ни с одним из тех же удаленных хостов или с любыми другими хостами. Опять же, заставляя меня поверить, что это исключительно проблема с конфигурацией в localhost (но, может быть, я ошибаюсь?).
ОБНОВЛЕНИЕ 3: Я удалил пакет openssh (и конфигурации) с localhost и переустановил, но безрезультатно.
1) Включена ли у вас аутентификация GSSAPIA? Попробуйте установить для него значение «нет» в / etc / ssh / sshd_config
2) Вы проверили, является ли это проблемой поиска DNS? Попробуйте добавить целевой хост и его IP-адрес в / etc / hosts и повторите попытку подключения по ssh.
3) Чтобы сделать свой tcpdump, вы можете использовать следующее:
tcpdump -n "port 22 and dst <ip address of destination host>"
4) Можете ли вы опубликовать полный вывод отладки -vvv? Или это было? Можете показать, что там написано после тайм-аута?
В любом случае, где он зависает, вы также можете просто сделать netstat -an | grep <ip of remote host> и если в поле «Состояние» указано «SYN_SENT», то вы знаете, что оно заблокировано на каком-то уровне.
Тайм-аут может произойти, если у вас высокая загрузка процессора на вашем локальном компьютере, у меня иногда возникала эта проблема несколько лет назад. Мой процесс резервного копирования тогда съел мой IO + CPU.
Поскольку сервер, к которому я подключился, был GPRS и, следовательно, медленным по дизайну, я не сразу подумал о локальном хосте как о проблеме.
Кроме того, вы можете, как вы сказали, иметь ограничение на количество подключений, которые вы можете использовать.
лично я бы проверял пакеты чем-то вроде wirehark.
Вы пробовали изменить IP-адрес клиента? Может быть, брандмауэр локальной сети блокирует или ограничивает часть трафика SSH, поступающего с этого конкретного адреса?