Не может SSH в сервер Linux
Если бы Вы ищете хорошее решение SAN iSCSI начинающего, я настоятельно рекомендовал бы использованию Intel или Broadcom базирующиеся NICs, которые поддерживают HBA и iSOE и устройство iSCSI (хотя это - больше вопрос предпочтения).
Я очень колебался бы об использовании SSD в решении SAN. Они не были протестированы в такой конфигурации экстенсивно, и время работы является главным в большинстве SAN.
На основе моего опыта люди ловушки № 1 входят, "это слишком дорого", прежде чем они тщательно оценят возможности времени простоя (который неизбежен), и как их решение смягчает отказы. Устройство iSCSI как HP MSA2000i или Dell MD3000i имеет высокую эффективность и превосходные гарантии включая 4-часовой ответ. Если стоимость не выравнивается по ширине, необходимо тщательно рассмотреть то, что извлекает выгоду, SAN обеспечивает во-первых.
Кроме того, наличие хорошего торгового представителя от торгового посредника может помочь много при попытке найти, что продукты оценивают. Лично мой торговый представитель в CDW был превосходен при слушании моих требований и обеспечении выбора создать решение.
Если можно перечислить несколько требований (чему SAN будет служить, например), он мог бы помочь в предоставлении рекомендации. Вы не перечислили то, для чего это будет использоваться, таким образом, будет очень трудно сказать, является ли это хорошая идея или нет.
Try logging in to the console then:
ssh localhost
That will test the ssh daemon on the host without regard to the firewall or other filtering.
Вы используете сервер или кто-то другой? У вас есть root-доступ на сервере? Похоже, вы можете быть заблокированы на стороне сервера. Со стороны клиента мало что можно сделать. Прежде всего, попробуйте использовать параметры '-v', '-vv' или '-vvv', чтобы получить отладочную информацию о том, что происходит:
ssh -vv server.name.org
Если это бесполезно, вы можете выполнить traceroute , ping , nmap на хосте, чтобы проверить, видите ли вы машину в сети:
traceroute server.name.org
ping server.name.org
nmap -v -A server.name.org
Вероятно, вы заблокированы брандмауэром на server.name .org и не исправляется на стороне клиента.
У вас есть доступ к серверу? Если это так, вы можете исключить брандмауэр как потенциальную проблему на сервере, отключив его, попытавшись использовать ssh, а затем снова включив его (все с сервера):
sudo servce iptables stop; ssh -v localhost; sudo service iptables start
Вы уверены, что процесс sshd запущен? Попробуйте проверить, работает ли он:
sudo service sshd status
Если он не запущен, вам нужно запустить его:
sudo service sshd start
Вы можете включить его навсегда с помощью:
sudo chkconfig sshd on
Не знаю, слишком ли поздно, но я исправил эту проблему в Linux Lite, открыв порт на брандмауэре (UFW).
sudo ufw allow 22 #replace 22 with whatever port
источник: https://www.linuxliteos.com/forums/network/sshd-or-openssh/msg19245/#msg19245
У меня была такая же проблема, когда сервер реагировал на команду ping и приглашение входа в систему, но не принимал соединения.
Просмотр всех связанных sshd ] config. Я заметил, что отсутствует конфигурационный файл /etc/pam.d/sshd .
Поскольку у меня был доступ к консоли виртуальной машины, я использовал scp через консоль для копирования этот файл конфигурации с другого сервера, который решил проблему.
Команда для копирования файла с удаленного сервера:
scp -r root@remoteserver:/etc/pam.d/sshd /etc/pam.d/
Перезапустите службу ssh с помощью этой команды:
service sshd restart
Теперь вы должны быть может войти в систему.