Вопрос или проблема
Месяц назад я мог подключаться к удаленному серверу через ssh, но вот уже неделю не могу. В данный момент у меня есть доступ к серверу локально, и когда я пытаюсь подключиться к localhost, чтобы проверить, работает ли это, я могу подключиться.
ssh username@localhost
Всё нормально на локальном уровне.
Но с удаленной машины:
ssh username@ip-address-of-server
Я получаю такое сообщение:
ssh: connect to host ip-address-of-server port 22: Connection timed out
На этом сервере работает также веб-страница, конечно же, на порту 80. Веб-страница работает.
Примечание: я могу пинговать сервер с 0% потерь пакетов, так что я получил все переданные пакеты.
Я уже пытался перезапустить ssh на сервере, но по-прежнему не работает. Только локально на localhost, но не удаленно.
Я пробовал с разных удаленных машин без успеха.
Так почему я мог подключаться раньше, а сейчас нет? В чем проблема?
Я уже задавал этот вопрос на [stackoverflow.com][1], но сейчас его поставили на паузу как вне темы.
Сделайте следующее на вашем удаленном сервере, пытаясь подключиться через ssh:
tail -f /var/log/auth.log
Есть ли какие-либо ошибки, зафиксированные в журналах?
Если вы не видите никаких логов, созданных вашей попыткой входа, вероятно, это проблема с сетью (фаервол, ACL переключателя и т.д.).
Как вы описываете ситуацию, вы хотите выполнить “внутренний доступ” и “внешний доступ”. В вашем случае я понимаю, что внутренний доступ осуществляется с хоста к SSH-серверу, оба находятся в одной подсети IP. С другой стороны, вы упоминаете “удаленный доступ”, который, как я полагаю, вы имеете в виду доступ к SSH-серверу с хоста, находящегося на другой подсети IP (внешний доступ). Единственный способ сделать последнее – через маршрутизатор, и, кроме того, маршрутизатор должен быть способен выполнять очень базовую функцию, называемую перенаправлением портов. Сказав это, по какой-то причине ваш маршрутизатор потерял возможность перенаправления портов. Есть две возможности: перезапустить маршрутизатор, так как он стал “неисправным”, или пересмотреть конфигурацию перенаправления портов на маршрутизаторе, который перенаправляет внешний вызов к SSH-порту маршрутизатора на SSH-порт внутреннего SSH-сервера. Обратите внимание, что могут применяться многие другие факторы, но описание не предоставляет достаточной информации для дальнейшей поддержки случая. В любом случае, усилия по устранению неполадок должны быть сосредоточены на анализе маршрутизатора, чтобы выяснить, получает ли маршрутизатор SSH-звонки/попытки на внешнем интерфейсе, и если да, то анализировать, почему маршрутизатор не перенаправляет SSH-трафик к внутреннему SSH-серверу. Если вам удалось сделать решение рабочим в прошлом как “по волшебству” без “что-либо”, пожалуйста, проверьте активацию/возможности UPnP как на маршрутизаторе, так и на сервере.
Ответ или решение
К сожалению, возникли проблемы с подключением к удаленному серверу через SSH. Давайте подробно рассмотрим возможные причины этой ситуации и шаги, которые помогут её решить.
1. Проверка локального доступа
Вы уже проверили локальное подключение к серверу, используя команду:
ssh username@localhostПоскольку локальное соединение работает, мы можем исключить проблемы с конфигурацией SSH-сервера и убедиться в том, что служба SSH на сервере работает корректно.
2. Проверка удаленного доступа
Когда вы пытаетесь подключиться к серверу с удалённой машины с помощью:
ssh username@ip-address-of-serverи получаете ошибку Connection timed out, это указывает на то, что клиент не может установить соединение с сервером через порт 22, который является стандартным портом для SSH.
3. Анализ сетевого подключения
Так как вы можете пинговать сервер с удалённой машины и получаете 0% потерь пакетов, это говорит о том, что сервер доступен по сети. Однако, это не гарантирует, что порт 22 открыт для SSH-контроля. Вам необходимо проверить следующие аспекты:
-
Брандмауэр: Убедитесь, что на сервере не активен брандмауэр, который блокирует входящие подключения на порт 22. Вы можете использовать команды, такие как
ufwилиiptables, для проверки статуса брандмауэра. Например:sudo ufw statusЕсли брандмауэр активен, убедитесь, что SSH разрешен.
-
Настройки маршрутизатора: Если ваш сервер находится за маршрутизатором, проверьте настройки маршрутизатора, чтобы убедиться, что порт 22 правильно переадресуется (Port Forwarding) на внутренний IP-адрес вашего сервера. Если маршрутизатор конфликтует с другими устройствами в сети или произошла ошибка, это может привести к тому, что соединение не осуществляется.
4. Логи проверки
Для большей информативности, вам стоит проверить логи авторизации на сервере. Используйте следующую команду:
tail -f /var/log/auth.logСледите за сообщениями, которые появляются в логах при попытке подключения. Если сообщений нет, это подтверждает, что соединение не достигает сервера, и проблема аномальна на уровне сети.
5. Возможные конфликты
Убедитесь, что нет конфликтов в IP-адресах и что ваш сервер имеет статический IP-адрес в сети. Проверьте настройки DHCP на маршрутизаторе, если они используются.
Заключение
С обрисованной информацией можно выделить несколько ключевых направлений для диагностирования и устранения проблемы с подключением по SSH. Начните с проверки брандмауэра и маршрутизатора, а затем исследуйте возможные конфликты в сети. При необходимости, обратитесь за помощью к администратору сети, который может предоставить доступ к дополнительной диагностике и управлению сетевыми настройками. Так вы сможете восстановить доступ к вашему серверу в кратчайшие сроки.