На AWS мне нужно открывать порты в брандмауэре экземпляра EC2, а также в группе безопасности?


8

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

Ответы:


12

Ваш экземпляр брандмауэра не имеет этот открытый порт. Попробуйте следующую команду:

iptables -I INPUT 3 -s 0.0.0.0/0 -d 0.0.0.0/0 -p tcp --dport 23453 -m state --state New -j ACCEPT

Обратите внимание, что правила iptables необходимо сохранить, чтобы сохранить их после перезагрузки. На RHEL это:

/sbin/service iptables save

Это сработало. Если бы кто-то мог сказать мне важное различие между правилом iptables @ melsayed и правилом iptables Фрэнка, я был бы очень благодарен. Кроме того, я предполагаю, что это означает, что ответ на мой главный вопрос: «Да, в AWS вы должны открывать порты в брандмауэрах экземпляров ec2, а также их группы безопасности». Спасибо всем.
Эндрю Мартин

Я попытался прокомментировать ответ Фрэнка, но у меня пока недостаточно репортеров :)
melsayed

2
По сути, команда Фрэнка iptables добавляет (-A) новое правило, которое разрешает подключение к этому порту. Проблема в том, что он добавляет правило в конец списка правил iptables. Последнее правило в списке iptables отклоняет все, что явно не разрешено до него. Так как правила iptables применяются по порядку, соединение сопоставляется и отклоняется до того, как оно попадет в новое правило.
melsayed

2
Я вставил новое правило в список на 3-й позиции (-I INPUT 3). Который сопоставляется перед правилом отклонения в конце, следовательно, разрешает соединение. Как упомянул Фрэнк, вы можете использовать iptables -nvL, чтобы увидеть количество пакетов, сопоставленных каждому правилу, что помогает при отладке такой конфигурации.
произнес

/sbin/service iptables saveне работает для меня, даже с sudo.
Huertanix

2

Добавить правило iptables

iptables -I INPUT 1 -p tcp --dport 23435 -j ACCEPT

который принимает трафик с любого хоста через порт 23435 и пытается ssh, если вы видите какие-либо пакеты или действия, то это означает, что пакеты достигают вашего сервера.

Если вы не видите пакетов, это означает, что в группе безопасности AWS нет правила, разрешающего ваш порт.

но если вы видите трафик по этому правилу (by iptables -nvL), то вам нужно запустить «netstat -ntlp» и проверить, запущен ли демон SSH на порту 2435. и включен 0.0.0.0/0.

надеюсь, что эти шаги позволят решить проблему. если все еще нет, то скажи мне.


1

Вы уверены, что группа безопасности установлена ​​правильно? Вы нажали "Применить изменения"? Многие забывают на самом деле применить свои изменения :)

«Плохой номер файла» обычно означает тайм-ауты соединения, и ваши настройки iptables выглядят правильно.


Однажды я не справился с ловушкой «применить изменения». Больше никогда. :)
Андрей Мартин

-1

В случае, если кто-то наткнется на эту тему, потому что он изменил порт ssh по умолчанию, вот решение, которое сработало для меня:

  1. Чтобы обойти корпоративный брандмауэр, я изменил порт на 80 вкл /etc/ssh/sshd_conf.
  2. К сожалению, Apache уже был установлен на этом экземпляре, поэтому я не мог больше ssh.
  3. Я отсоединил том от экземпляра.
  4. прикрепил его к другому экземпляру
  5. смонтировал его, изменил порт в конфигурационном файле
  6. отсоединил это, повторно прикрепил это на старом случае
  7. перезагрузил: все хорошо: D
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.