Если я изменю свой порт SSH с 22 на 23453, я больше не смогу войти в ssh.
Более подробно, я использую экземпляр Red Hat EC2 в Amazon Web Services. Это второе изменение, которое я получил при новой установке (первое изменение заключалось в добавлении пользователя без полномочий root).
Я могу ssh в порядке, используя Git Bash и локальный файл .ssh / config, я редактирую строку в / etc / ssh / sshd_config, которая в настоящее время говорит
#Port 23453
сказать
Port 23453
затем перезапустите sshd с
sudo service sshd restart
Затем я добавляю строку «Порт 23453» в мой файл .ssh / config
Host foo
Hostname my-ec2-public-DNS
Port 23453
IdentityFile my ssl key
Если я открою другую оболочку Git Bash (без закрытия моего существующего соединения) и попытаюсь подключить ssh к своему экземпляру (с помощью ssh foo), я вижу следующую ошибку:
ssh: connect to host my-ec2-public-DNS port 23453: Bad file number
Группа безопасности, прикрепленная к этому экземпляру, имеет две записи, обе TCP
22 (SSH) 0.0.0.0/0
23453 0.0.0.0/0
Я думаю, что порт все еще заблокирован моим брандмауэром.
Вывод sudo iptables -Lвыглядит следующим образом
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Который выглядит довольно открытым для меня.
ОБНОВИТЬ
После добавления правила iptables
iptables -A INPUT -p tcp --dport 23453 -j ACCEPT
и пытаясь снова, все еще не повезло.
Выход из iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT tcp -- anywhere anywhere tcp dpt:23453
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Который выглядит достаточно открытым. Я не совсем уверен, как искать входящие пакеты или активность на порту. Но вывод netstat -ntlp(как корень)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:56137 0.0.0.0:* LISTEN 948/rpc.statd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 930/rpcbind
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1012/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1224/master
tcp 0 0 0.0.0.0:23453 0.0.0.0:* LISTEN 32638/sshd
tcp 0 0 :::36139 :::* LISTEN 948/rpc.statd
tcp 0 0 :::111 :::* LISTEN 930/rpcbind
tcp 0 0 ::1:631 :::* LISTEN 1012/cupsd
tcp 0 0 :::23453 :::* LISTEN 32638/sshd
Который мне кажется, чтобы показать sshd на 23453.
Я снова проверил, что у экземпляра открыт порт в группе безопасности (Порт: 23453, Протокол: tcp, Источник: 0.0.0.0/0)
Что еще может быть причиной сбоя подключения через SSH?
ура
POSTMORTEM
Теперь я могу подключиться. Это было отсутствующее правило в iptables. Вывод iptables -Lтеперь выглядит так:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:23453 state NEW
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
источник
iptables -L(ssh работает) и вторымiptables -L(ssh заблокирован). Посмотрите на порядок правил в цепочке INPUT (6 строк под первой «целью»), они читаются сверху вниз, поэтому во втором наборе правил «REJECT all» выполняется перед «ACCEPT tcp». ЦСТ: 23453" . Третий набор правил имеет запись ПРИНЯТЬ выше и, следовательно, ранее, ОТКАЗАТЬ.Ответы:
Ваш экземпляр брандмауэра не имеет этот открытый порт. Попробуйте следующую команду:
Обратите внимание, что правила iptables необходимо сохранить, чтобы сохранить их после перезагрузки. На RHEL это:
источник
/sbin/service iptables saveне работает для меня, даже с sudo.Добавить правило iptables
который принимает трафик с любого хоста через порт 23435 и пытается ssh, если вы видите какие-либо пакеты или действия, то это означает, что пакеты достигают вашего сервера.
Если вы не видите пакетов, это означает, что в группе безопасности AWS нет правила, разрешающего ваш порт.
но если вы видите трафик по этому правилу (by
iptables -nvL), то вам нужно запустить «netstat -ntlp» и проверить, запущен ли демон SSH на порту 2435. и включен0.0.0.0/0.надеюсь, что эти шаги позволят решить проблему. если все еще нет, то скажи мне.
источник
Вы уверены, что группа безопасности установлена правильно? Вы нажали "Применить изменения"? Многие забывают на самом деле применить свои изменения :)
«Плохой номер файла» обычно означает тайм-ауты соединения, и ваши настройки iptables выглядят правильно.
источник
В случае, если кто-то наткнется на эту тему, потому что он изменил порт ssh по умолчанию, вот решение, которое сработало для меня:
/etc/ssh/sshd_conf.источник