Sur AWS Dois-je ouvrir des ports dans le pare-feu d'une instance EC2 ainsi que le groupe de sécurité?
Si je change de mon port SSH du 22 au 23453, je ne peux plus ssh dans.
De plus en détail, j'utilise une instance de Red Hat EC2 sur Amazon Web Services. C'est le deuxième changement que j'ai sur une nouvelle installation (premier changement consistait à ajouter un utilisateur non root).
Je peux ssh à l'aide de Git Bash et un fichier local .ssh/config, je modifie la ligne dans/etc/ssh/sshd_config qui dit actuellement
#Port 23453
dire
Port 23453
puis redémarrez Sshd avec
Sudo service sshd restart
J'ajoute ensuite une ligne "Port 23453" mon fichier .sSH/config
Host foo
Hostname my-ec2-public-DNS
Port 23453
IdentityFile my ssl key
Si j'ouvre une autre coquille Git Bash (sans fermer ma connexion existante) et tenter de ssh dans mon instance (avec SSH FOO), je vois l'erreur suivante:
ssh: connect to Host my-ec2-public-DNS port 23453: Bad file number
Le groupe de sécurité attaché à cette instance a deux entrées, TCP
22 (SSH) 0.0.0.0/0
23453 0.0.0.0/0
Ma meilleure hypothèse est que le port est toujours bloqué par mon pare-feu.
La sortie de Sudo iptables -L Est la suivante
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
Qui a l'air jolie à moi.
MISE À JOUR
Après avoir ajouté une règle d'iptables
iptables -A INPUT -p tcp --dport 23453 -j ACCEPT
et essayant encore, toujours pas de chance.
Sortie de 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
Qui a l'air suffisamment ouvert. Je ne suis pas tout à fait sûr comment rechercher des paquets entrant ou une activité sur le port. Mais la sortie de netstat -ntlp (Comme 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
Ce qui me semble montrer à SSHD le 23453.
J'ai vérifié à nouveau que l'instance porte le port ouvert dans le groupe de sécurité (Port: 23453, Protocole: TCP, Source: 0.0.0.0/0)
Que peut-on causer l'échec de la connexion via SSH?
À votre santé
POSTMORTEM
Je peux maintenant me connecter. C'était une règle manquante dans les IPtables. La sortie de iptables -L On dirait maintenant ceci:
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
Votre pare-feu d'instance n'a pas ce port ouvert. Essayez la commande suivante:
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
Notez que les règles IPTABLES doivent être enregistrées pour persister après un redémarrage. Sur rhel c'est:
/sbin/service iptables save
Ajouter une règle d'iptables
iptables -I INPUT 1 -p tcp --dport 23435 -j ACCEPT
ce qui accepte le trafic de n'importe quel hôte, par le port 23435 et essayez de SSH, si vous voyez des paquets ou une activité, cela signifie que les paquets atteignent votre serveur.
Si vous ne voyez aucun paquets, cela signifie que le groupe de sécurité AWS n'a pas de règle pour permettre votre port.
mais si vous voyez le trafic sur cette règle (par iptables -nvL), alors vous devez exécuter "netstat -ntlp" et vérifier si SSH Daemon fonctionne sur le port 2435. et sur 0.0.0.0/0.
espérons que ces étapes résoudraient la question. Si toujours non, alors dis-moi.
Êtes-vous sûr que le groupe de sécurité est défini correctement? Avez-vous cliqué sur "Appliquer les changements"? Beaucoup de gens oublient d'appliquer leurs changements :)
"Numéro de fichier incorrect" signifie généralement les délais de connexion et votre configuration IPTABLES a l'air correcte.