Muss ich unter AWS Ports in der Firewall einer EC2-Instanz sowie in der Sicherheitsgruppe öffnen?

8

Wenn ich meinen SSH-Port von 22 auf 23453 ändere, kann ich nicht mehr ssh.

Im Detail verwende ich eine Red Hat EC2-Instanz in Amazon Web Services. Dies ist die zweite Änderung, die ich bei einer Neuinstallation vorgenommen habe (die erste Änderung bestand darin, einen Benutzer hinzuzufügen, der kein Root ist).

Ich kann mit Git Bash und einer lokalen .ssh / config-Datei gut ssh, ich bearbeite die Zeile in / etc / ssh / sshd_config, die aktuell sagt

#Port 23453

sagen

Port 23453

dann sshd mit neu starten

sudo service sshd restart

Ich füge dann eine Zeile "Port 23453" meiner .ssh / config-Datei hinzu

Host foo 
Hostname my-ec2-public-DNS
Port 23453
IdentityFile my ssl key

Wenn ich eine andere Git Bash-Shell öffne (ohne meine bestehende Verbindung zu schließen) und versuche, in meine Instanz zu ssh (mit ssh foo), wird der folgende Fehler angezeigt:

ssh: connect to host my-ec2-public-DNS port 23453: Bad file number

Die an diese Instanz angehängte Sicherheitsgruppe verfügt über zwei Einträge, beide TCP

22 (SSH) 0.0.0.0/0

23453 0.0.0.0/0

Ich vermute, dass der Port immer noch von meiner Firewall blockiert wird.

Die Ausgabe von sudo iptables -List wie folgt

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

Was für mich ziemlich offen aussieht.

AKTUALISIEREN

Nach dem Hinzufügen einer iptables-Regel

iptables -A INPUT -p tcp --dport 23453 -j ACCEPT

und erneut versuchen, immer noch kein Glück.

Ausgabe von 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

Welches sieht ausreichend offen aus. Ich bin mir nicht ganz sicher, wie ich nach eingehenden Paketen oder Aktivitäten am Port suchen soll. Aber die Ausgabe von netstat -ntlp(als root)

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

Welches scheint mir sshd auf 23453 zu zeigen.

Ich habe erneut überprüft, ob in der Instanz der Port in der Sicherheitsgruppe geöffnet ist (Port: 23453, Protokoll: tcp, Quelle: 0.0.0.0/0).

Was kann sonst dazu führen, dass keine Verbindung über SSH hergestellt werden kann?

Prost

POSTMORTEM

Ich kann mich jetzt verbinden. Es war eine fehlende Regel in iptables. Die Ausgabe von iptables -Ljetzt sieht folgendermaßen aus:

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

— Andrew Martin
quelle

Für alle, die den Unterschied zwischen dem dritten iptables -L(ssh funktioniert) und dem zweiten iptables -L(ssh ist blockiert) nicht erkennen können. Schauen Sie sich die Reihenfolge der Regeln in der INPUT-Kette an (die 6 Zeilen unter dem ersten "Ziel"), sie werden von oben nach unten gelesen, sodass im zweiten Regelsatz "REJECT all" vor "ACCEPT tcp" getroffen wird dpt: 23453 ". Das dritte Regelwerk enthält den Eintrag ACCEPT über und damit vor dem Eintrag REJECT.

— Andrew Martin

12

In Ihrer Instanz-Firewall ist dieser Port nicht geöffnet. Versuchen Sie den folgenden Befehl:

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

Beachten Sie, dass iptables-Regeln gespeichert werden müssen, damit sie nach einem Neustart bestehen bleiben. Auf RHEL ist das:

/sbin/service iptables save

— melsayed
quelle

Das hat funktioniert. Wenn mir jemand einen wichtigen Unterschied zwischen der Iptables-Regel von @ melsayed und der Iptables-Regel von Frank sagen könnte, wäre ich sehr dankbar. Ich denke, dies bedeutet auch, dass die Antwort auf meine letzte Frage lautet: "Ja, unter AWS müssen Sie Ports in ec2-Instanz-Firewalls sowie deren Sicherheitsgruppen öffnen." Vielen Dank an alle.

— Andrew Martin

Ich habe versucht, Franks Antwort zu kommentieren, aber ich habe noch nicht genug Repräsentanten :)

— melsayed

2

Grundsätzlich fügt Franks Befehl iptables (-A) eine neue Regel hinzu, die die Verbindung zu diesem Port ermöglicht. Das Problem ist, dass die Regel am Ende der Liste der iptables-Regeln hinzugefügt wird. Die letzte Regel in der iptables-Liste lehnt alles ab, was vorher nicht explizit erlaubt ist. Da iptables-Regeln der Reihe nach angewendet werden, wird die Verbindung abgeglichen und abgelehnt, bevor überhaupt zur neuen Regel gelangt wird.

— melsayed

2

Ich habe an der 3. Stelle eine neue Regel in die Liste eingefügt (-I INPUT 3). Welches am Ende vor der Ablehnungsregel abgeglichen wird, wodurch die Verbindung ermöglicht wird. Wie Frank erwähnt hat, können Sie mit iptables -nvL die Anzahl der Pakete anzeigen, die mit jeder Regel übereinstimmen. Dies hilft beim Debuggen einer solchen Konfiguration.

— melsayed

/sbin/service iptables savefunktioniert nicht für mich, auch nicht mit sudo.

— Huertanix

2

Fügen Sie eine iptables-Regel hinzu

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

Dies akzeptiert Datenverkehr von einem beliebigen Host über Port 23435 und versucht zu ssh. Wenn Sie Pakete oder Aktivitäten sehen, bedeutet dies, dass die Pakete Ihren Server erreichen.

Wenn Sie keine Pakete sehen, bedeutet dies, dass die AWS-Sicherheitsgruppe keine Regel hat, um Ihren Port zuzulassen.

Wenn Sie jedoch Datenverkehr mit dieser Regel (von iptables -nvL) sehen, müssen Sie "netstat -ntlp" ausführen und überprüfen, ob der SSH-Dämon auf Port 2435 ausgeführt wird 0.0.0.0/0.

Hoffentlich würden diese Schritte das Problem beheben. wenn immer noch nein, dann sag es mir.

— Farhan
quelle

1

Sind Sie sicher, dass die Sicherheitsgruppe richtig eingestellt ist? Haben Sie auf "Änderungen übernehmen" geklickt? Viele Leute vergessen, ihre Änderungen tatsächlich anzuwenden :)

"Ungültige Dateinummer" bedeutet normalerweise Verbindungszeitüberschreitungen, und Ihr iptables-Setup sieht korrekt aus.

— Waleed Hamra
quelle

Ich bin schon einmal in die Falle geraten, Änderungen anzuwenden. Nie wieder. :)

— Andrew Martin

-1

Falls jemand über dieses Thema stolpert, weil er den Standardport von ssh geändert hat, ist hier eine Lösung, die für mich funktioniert hat:

Um eine Unternehmensfirewall zu umgehen, habe ich den Port auf 80 geändert /etc/ssh/sshd_conf.
Leider war Apache bereits auf dieser Instanz installiert, so dass ich nicht mehr ssh konnte.
Ich habe das Volume von der Instanz getrennt.
hat es an eine andere Instanz angehängt
hat es gemountet, den Port in der Konfigurationsdatei geändert
hat es abgenommen und wieder an die alte Instanz angehängt
neu gestartet: alles gut: D.

— Homezar
quelle