Не могу подключиться к SSH, но могу проверить связь
Я использую Ubuntu 16.04. Проблема в том, что я могу подключаться по SSH к другим машинам из моей системы, но я не могу подключиться по SSH к моей системе с другой машины. Однако я могу проверить связь с моей системой с других компьютеров.
Например, IP-адрес моей системы - 192.168.103.32 , а другая машина, на которой работает CentOS, имеет IP-адрес 192.168.170.52 . Таким образом, я могу использовать SSH на 192.168.170.52 из 192.168.103.32, но наоборот не работает. Кроме того, я могу пинговать 192.168.103.32 с 192.168.170.52.
Вывод ssh из 192.168.170.52:
ssh -v bhavya@192.168.103.32
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.103.32 [192.168.103.32] port 22.
Вывод для:
sudo service ssh status
:
ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: ena
Active: active (running) since Thu 2017-06-29 11:39:00 IST; 39min ago
Process: 3064 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCE
Main PID: 1142 (sshd)
CGroup: /system.slice/ssh.service
└─1142 /usr/sbin/sshd -D
Jun 29 11:39:37 bhavya systemd[1]: Reloading OpenBSD Secure Shell server.
Jun 29 11:39:37 bhavya sshd[1142]: Received SIGHUP; restarting.
Jun 29 11:39:37 bhavya systemd[1]: Reloaded OpenBSD Secure Shell server.
Jun 29 11:39:37 bhavya sshd[1142]: Server listening on 0.0.0.0 port 22.
Jun 29 11:39:37 bhavya sshd[1142]: Server listening on :: port 22.
Jun 29 11:39:37 bhavya systemd[1]: Reloading OpenBSD Secure Shell server.
Jun 29 11:39:37 bhavya sshd[1142]: Received SIGHUP; restarting.
Jun 29 11:39:37 bhavya sshd[1142]: Server listening on 0.0.0.0 port 22.
Jun 29 11:39:37 bhavya sshd[1142]: Server listening on :: port 22.
Jun 29 11:39:37 bhavya systemd[1]: Reloaded OpenBSD Secure Shell server.
Выполнение
sudo ufw allow 22
сработало для меня.
Пояснение:--
UFW, или простой брандмауэр, представляет собой -переднюю часть iptables. Его основная цель состоит в том, чтобы максимально упростить управление вашим брандмауэром -и предоставить простой -в -интерфейс использования. Он хорошо -поддерживается и популярен в сообществе Linux — даже установлен по умолчанию во многих дистрибутивах.
Одна из вещей, которая упростит настройку любого брандмауэра, — это определение некоторых правил по умолчанию для разрешения и запрета подключений. По умолчанию UFW запрещает все входящие подключения и разрешает все исходящие. Это означает, что любой, кто пытается получить доступ к вашему облачному серверу, не сможет подключиться, в то время как любое приложение на сервере сможет получить доступ к внешнему миру.
На самом деле, вчера у меня были проблемы с настройкой nfs, поэтому я пытался настроить свой брандмауэр. А сегодня, когда я загружал свой компьютер, настройки брандмауэра могли быть установлены по умолчанию. Так что проблема может заключаться в этом.
Я бы провел стандартную проверку подключения к сети.
Если предполагается, что ssh-сервер находится в той же сети, что и вы, попробуйте пропинговать его. Однако если проверка связи прошла успешно, это не обязательно означает, что у вас есть полное IP-подключение. Убедитесь, особенно если сервер является виртуальной машиной, что MAC-адрес сетевого интерфейса (виртуального или реального )находится в той же vLAN, что и клиент. Если вы используете какую-либо форму тегирования пакетов, а не тегирование порта коммутатора, то в некоторых случаях коммутатор будет правильно передавать пакеты ICMP, но не пакеты TCP/UDP. Тот сводил меня с ума весь день.