Su AWS devo aprire le porte nel firewall di un'istanza EC2 e nel gruppo di sicurezza?

8

Se cambio la mia porta SSH da 22 a 23453, non riesco più a collegarmi.

Più in dettaglio, sto usando un'istanza Red Hat EC2 su Amazon Web Services. Questa è la seconda modifica che ho su una nuova installazione (la prima modifica è stata quella di aggiungere un utente non root).

Posso ssh bene usando Git Bash e un file .ssh / config locale, modifico la riga in / etc / ssh / sshd_config che attualmente dice

#Port 23453

dire

Port 23453

quindi riavviare sshd con

sudo service sshd restart

Aggiungo quindi una riga "Porta 23453" il mio file .ssh / config

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

Se apro un'altra shell Git Bash (senza chiudere la mia connessione esistente) e provo a ssh nella mia istanza (con ssh foo) vedo il seguente errore:

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

Il gruppo di sicurezza collegato a questa istanza ha due voci, entrambe TCP

22 (SSH) 0.0.0.0/0

23453 0.0.0.0/0

La mia ipotesi migliore è che la porta sia ancora bloccata dal mio firewall.

L'output di sudo iptables -Lè il seguente

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

Il che mi sembra abbastanza aperto.

AGGIORNARE

Dopo aver aggiunto una regola iptables

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

e riprovare, ancora nessuna fortuna.

Uscita di 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

Che sembra sufficientemente aperto. Non sono del tutto sicuro di come cercare pacchetti in arrivo o attività sulla porta. Ma l'output di netstat -ntlp(come 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

Il che mi sembra mostrare sshd il 23453.

Ho ricontrollato che l'istanza ha la porta aperta nel gruppo di sicurezza (Porta: 23453, Protocollo: tcp, Fonte: 0.0.0.0/0)

Cos'altro può causare la mancata connessione tramite SSH?

Saluti

POSTMORTEM

Ora posso collegarmi. Era una regola mancante in iptables. L'output di iptables -Lnow è simile al seguente:

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
fonte

Per chiunque non riesca a vedere la differenza tra il terzo iptables -L(funziona ssh) e il secondo iptables -L(ssh è bloccato). Guarda l'ordine delle regole nella catena INPUT (le 6 righe sotto il primo "target"), vengono lette dall'alto verso il basso, quindi nella seconda serie di regole, "REJECT all" viene colpito prima di "ACCEPT tcp DPT: 23453" . La terza serie di regole ha la voce ACCEPT sopra, e quindi prima, la voce REJECT.

— Andrew Martin,

12

Il firewall dell'istanza non ha questa porta aperta. Prova il seguente comando:

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

Si noti che le regole di iptables devono essere salvate per persistere dopo un riavvio. Su RHEL questo è:

/sbin/service iptables save

— melsayed
fonte

Questo ha funzionato. Se qualcuno potesse dirmi una differenza importante tra la regola iptables di @ melsayed e la regola iptables di Frank, sarei molto grato. Inoltre, suppongo che ciò significhi che la risposta alla mia ultima domanda è "Sì, su AWS devi aprire le porte nei firewall delle istanze ec2 e i loro gruppi di sicurezza". Grazie a tutti.

— Andrew Martin,

Ho provato a commentare la risposta di Frank, ma non ho ancora abbastanza rappresentante :)

— melsayed

2

Fondamentalmente, il comando iptables di Frank aggiunge (-A) una nuova regola che consentirebbe la connessione a quella porta. Il problema è che aggiunge la regola alla fine dell'elenco di regole iptables. L'ultima regola nell'elenco iptables rifiuta tutto ciò che non è stato esplicitamente consentito prima di esso. Poiché le regole di iptables sono applicate in ordine, la connessione viene abbinata e rifiutata prima ancora di arrivare alla nuova regola.

— melsayed

2

Ho inserito una nuova regola nell'elenco, in terza posizione (-I INPUT 3). Che viene abbinato prima della regola di rifiuto alla fine, consentendo quindi la connessione. Come accennato da Frank, potresti usare iptables -nvL per vedere il numero di pacchetti corrispondenti a ciascuna regola, il che aiuta durante il debug di tale configurazione.

— melsayed

/sbin/service iptables savenon funziona per me, nemmeno con sudo.

— Huertanix,

2

Aggiungi una regola iptables

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

che accetta il traffico da qualsiasi host, dalla porta 23435, e prova a ssh, se vedi pacchetti o attività, significa che i pacchetti stanno raggiungendo il tuo server.

Se non vedi pacchetti, significa che il gruppo Sicurezza AWS non ha regole per consentire la tua porta.

ma se vedi traffico su questa regola (per iptables -nvL), devi eseguire "netstat -ntlp" e verificare se il demone SSH è in esecuzione sulla porta 2435. e su 0.0.0.0/0.

speriamo che questi passaggi risolvano il problema. se ancora no, allora dimmelo.

— Farhan
fonte

1

Sei sicuro che il gruppo di sicurezza sia impostato correttamente? Hai fatto clic su "Applica modifiche"? Molte persone dimenticano di applicare effettivamente le loro modifiche :)

"Numero file errato" di solito indica timeout di connessione e la configurazione di iptables sembra corretta.

— Wraed Hamra
fonte

Una volta ho commesso un fallo per la trappola "applica modifiche". Mai più. :)

— Andrew Martin,

-1

Nel caso in cui qualcuno si imbatta in questo argomento perché hanno cambiato la porta predefinita di ssh, ecco una soluzione che ha funzionato per me:

Per bypassare un firewall aziendale, ho cambiato la porta in 80 su /etc/ssh/sshd_conf.
Sfortunatamente, Apache era già installato su quell'istanza, quindi non potevo più ssh.
Ho staccato il volume dall'istanza.
allegato a un'altra istanza
montato, modificato la porta nel file di configurazione
rimosso, ricollegato alla vecchia istanza
riavviato: tutto bene: D

— Homezar
fonte