- Вопрос или проблема
- Ответ или решение
- Как отладить входящие соединения SSH: Подробное руководство
- 1. Проверьте статус SSH-сервера
- 2. Проверьте настройки брандмауэра
- 3. Настройте уровень логирования SSH
- 4. Используйте "verbose" режим SSH
- 5. Проверка ARP-таблиц
- 6. Проверка прав доступа
- 7. Дополнительная диагностика
- Заключение
Вопрос или проблема
У меня возникли проблемы с подключением к серверу (Ubuntu 16.04) по ssh с моего компьютера (macOS 10.12), к которому у меня есть root-доступ. Ситуация странная: я проверил, что sshd работает на сервере и что порт 22 открыт (sudo netstat -anp | grep sshd), и трафик не блокируется (sudo iptables -L | grep ssh и sudo ufw verbose); hosts.deny также не содержит моего IP-адреса.
Самое странное – я могу войти с другого компьютера без проблем. Когда я запускаю nmap <server-ip> на своем компьютере, он показывает, что только порт 80 открыт; запуск той же команды на другом компьютере показывает только один открытый порт – 22. Я попробовал войти с третьего компьютера – снова не повезло. Не уверен, что происходит.
Мне нужен способ (tail -f логов, вероятно), чтобы я мог видеть, что на самом деле происходит на сервере, когда я пытаюсь подключиться с разных машин. Может быть, это поможет мне в устранении неполадок. Есть ли советы по отладке этой проблемы?
Команда man 5 sshd_config предоставит вам множество опций.
Настройка LogLevel VERBOSE в файле /etc/ssh/sshd_config вероятно, то, что вам нужно, хотя есть и более высокие уровни.
Сообщения по умолчанию будут записываться в /var/log/auth.log, поэтому вам нужно будет tail -f /var/log/auth.log в отдельном терминале, чтобы увидеть, что происходит.
Проблема оказалась в том, что другая машина имела тот же IP-адрес, что и сервер. Очень тривиально, но не очевидно (вздох). Спасибо за помощь тем, кто ответил.
Я был в отчаянии и собирался начать использовать Wireshark, когда проверил таблицы arp на клиентах и заметил, что клиенты, у которых время от времени возникают проблемы, иногда получают разные MAC-адреса для того же IP-адреса сервера. Это заставило меня подумать, что в сети может быть другая машина. Вот в чем была проблема.
Я полагаю, что сеть, из которой вы используете nmap, не имеет разрешения брандмауэра на доступ к порту 22 на сервере.
На другой машине, с которой вы видите только порт 22 на сервере, но не порт 80, правило брандмауэра разрешает подключение к порту 22, но не к порту 80 с этой машины к серверу.
Проверьте настройки брандмауэра для правила, разрешающего доступ к ssh и http на сервер с вашего компьютера и другого компьютера.
Если это не решит проблему, вы можете проверить журналы, как упомянуто в предыдущем ответе.
У меня был интересный случай
Аутентификация отказана: неправильное владение или режимы для директории /home/user
На стороне клиента (ssh —v) заметил, что rsa просто не принимается. Пришлось действительно отлаживать сторону sshd:
$ tail -f /var/log/auth.log
Нашел ошибку, упомянутую выше. Проверил разрешения на домашнюю папку – 777 по какой-то причине (папка ~/.ssh 700 и authorized_keys2 640 были в порядке). Поэтому chmod 750 /home/renard/ помогло. Таким образом, есть требования и к домашней папке.
Ответ или решение
Как отладить входящие соединения SSH: Подробное руководство
Отладка SSH-соединений может показаться сложной задачей, особенно когда возникают проблемы с доступом к серверу, как в вашем случае с Ubuntu 16.04. Ниже представлена подробная инструкция по шагам, которые вы можете предпринять, чтобы выявить и устранить проблемы с подключением.
1. Проверьте статус SSH-сервера
Убедитесь, что SSH-сервер (sshd) запущен:
sudo systemctl status sshТакже полезно проверить, слушает ли SSH-сервер нужный порт (по умолчанию это порт 22):
sudo netstat -tuln | grep ':22'2. Проверьте настройки брандмауэра
Убедитесь, что брандмауэр не блокирует порт SSH. Используйте следующие команды для проверки настроек:
sudo iptables -L -n
sudo ufw status verboseУбедитесь, что правилам в брандмауэре разрешены подключения к порту 22.
3. Настройте уровень логирования SSH
Для более детального отслеживания проблем измените уровень логирования в конфигурационном файле SSH:
- Откройте файл конфигурации SSH:
sudo nano /etc/ssh/sshd_config- Найдите строку
LogLevelи измените ее на:
LogLevel VERBOSE- После внесения изменений перезапустите SSH-сервер:
sudo systemctl restart ssh- Теперь откройте новый терминал и выполните команду, чтобы отслеживать логи:
tail -f /var/log/auth.logЭто позволит вам видеть все события, связанные с аутентификацией, в реальном времени.
4. Используйте "verbose" режим SSH
При выполнении подключения к серверу можно использовать параметр -v для повышения уровня подробности:
ssh -v user@server-ipВы также можете добавить больше v, например, -vvv, для еще более детализированных логов.
5. Проверка ARP-таблиц
Если вы подозреваете, что проблема может быть связана с сетевой конфигурацией, проверьте ARP-таблицы на машине-клиенте, чтобы убедиться, что вы не подключаетесь к другому устройству с тем же IP-адресом:
arp -aПри наличии множественного устройства с одним и тем же IP вы можете столкнуться с потерей соединения.
6. Проверка прав доступа
Иногда проблемы с доступом могут быть вызваны некорректными правами на файловой системе. Убедитесь в корректных правах доступа к домашнему каталогу пользователя и скрытой папке .ssh:
ls -ld /home/user
ls -ld /home/user/.sshПрава на домашний каталог пользователя должны быть не более 755, а для папки .ssh – не более 700.
7. Дополнительная диагностика
Если предыдущие шаги не помогли, подумайте о следующих вариантах:
- Проверка конфигураций межсетевого экрана на обоих концах (клиент и сервер).
- Проверка сетевых маршрутов, чтобы убедиться, что пакеты достигают сервера.
- Попробуйте воспользоваться другим инструментом, таким как
Wireshark, для анализа сетевой активности.
Заключение
Отладка SSH-соединений может быть непростой задачей, но с правильным подходом и пониманием процесса можно найти и устранить проблему. Следуя предложенным шагам и определяя возможные причины, вы значительно упростите диагностику и восстановление доступа к вашему серверу. Если вы обнаружите, что дело в конфликтующем IP-адресе или сетевых настройках, правильная корректировка поможет устранить проблему.