SSH-сервер не отвечает на запросы подключения
Аппаратный ключ вероятен не работать, если включено непосредственно в пи - USB-порты пи обеспечивают очень мало питания, и необходимо использовать приводимый в действие концентратор USB высокого качества - я нашел, что должен сделать это даже для использования беспроводной клавиатуры и флеш-накопителя одновременно (использующий один из них одних и хорошо хотя). Посмотрите здесь для списка проверенных концентраторов ту работу. Верьте мне, дешевые не работают.
Очень разочаровывающий самоответ
Отложив на день эту проблему и вернувшись к ней, я испытал одновременно облегчение и смятение (еще больше встревожено чем с облегчением), обнаружив, что все загадочным образом работает должным образом.
Итак, в чем была проблема?
Никакие настройки не были изменены или скорректированы - ни на маршрутизаторе, ни на сервере SSH, ни на машине клиента SSH.Можно с уверенностью сказать, что маршрутизатор не обрабатывает входящий трафик должным образом, несмотря на правильные настройки. Учитывая, что программное обеспечение изящного домашнего маршрутизатора на самом деле не предназначено для работы с переадресацией портов, бедняге потребовалось время, чтобы внести необходимые изменения.
Но прошло уже шесть часов !!
Да, чувак, я знаю. Я потратил весь день, пытаясь выяснить, что не так - и так и не нашел, потому что там не было ничего плохого. Очевидно, что настройки роутера вступят в силу через 6 часов, а то и больше.
Итак, как мне узнать, что это моя проблема?
Отличный инструмент, с которым я столкнулся во время этой выходки, - tcpdump . Этот худощавый маленький парень вынюхивает трафик для вас, предлагая ценную информацию о том, что на самом деле происходит. Кроме того, у него есть несколько функций суперфильтрации, которые позволяют вам сузить область поиска. Например, команда:
tcpdump -i wlan1 port 22 -n -Q inout
Указывает tcpdump искать трафик через интерфейс wlan1 ( -i = 'interface'), только через порт 22, игнорировать разрешение имен DNS ( -n = 'без разрешения имени'), и мы хотим видеть как входящий, так и исходящий трафик ( -Q принимает в , из ] или inout ; inout по умолчанию).
Запустив эту команду на своем SSH-сервере при попытке подключения через удаленный компьютер, быстро становится ясно, в чем именно заключается проблема.По сути, есть 3 возможности:
- Если вы видите входящий трафик с удаленного компьютера, но нет исходящего трафика с вашего локального сервера, проблема заключается в сервере. : вероятно, необходимо изменить правило брандмауэра и т. д.
- Если вы видите как входящие, так и исходящие , но ваш удаленный компьютер не получает ответа, скорее всего, это маршрутизатор: он разрешает входящий трафик, но отбрасывает исходящие пакеты.
- Если нет трафика вообще , это, вероятно, тоже проблема маршрутизатора: пакеты
SYNудаленной машины игнорируются и отбрасываются маршрутизатором еще до того, как достигают вашего сервера.
И как только вы обнаружите, в чем проблема, исправить (обычно) тривиально.
Просто для других:
Мне пришлось использовать опцию -P в tcpdump вместо -Q
tcpdump -i wlan1 port 22 -n -P inout
Если вы, как и я, включили UFW (в Linux, в моем случае Ubuntu ), попробуйте это:
sudo ufw enable OpenSSH
Это позволит использовать OpenSSH в брандмауэре.
В большинстве случаев виноват брандмауэр. Выполните service iptables stopи service ip6tables stop.
Если остановка службы не работает, выполните сброс iptable.
iptables --flush.
Если это виртуальная машина, сделайте то же самое и на хосте
Я использую Mint (Ubuntu ).
Я сделал все... открытый ключ в правильном формате в авторизованных _ключах, chmodding, chowning, перезапуск ssh и sshd и т. д. Все это было задокументировано повсюду.
Для меня это был брандмауэр ufw. Отсутствие какого-либо ответа ssh вообще подсказало мне это, но я без проблем мог пинговать в обе стороны в локальной сети.
Я тестировал:
sudo ufw service stop
...и это сработало отлично, т.е. я получил ответ от вызова ssh.
Итак, запустите ufw снова:
sudo ufw service start
...и добавить правило:
sudo ufw allow openssh
Теперь все работает нормально.