Если я изменю свой порт 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" . Третий набор правил имеет запись ПРИНЯТЬ выше и, следовательно, ранее, ОТКАЗАТЬ.