Na AWS, preciso abrir portas no firewall de uma instância do EC2 e no grupo de segurança?

8

Se eu mudar minha porta SSH de 22 para 23453, não será mais possível fazer o ssh.

Mais detalhadamente, estou usando uma instância do Red Hat EC2 no Amazon Web Services. Esta é a segunda alteração em uma nova instalação (a primeira alteração foi adicionar um usuário não root).

Posso fazer ssh usando o Git Bash e um arquivo local .ssh / config, edito a linha em / etc / ssh / sshd_config que atualmente diz

#Port 23453

dizer

Port 23453

depois reinicie o sshd com

sudo service sshd restart

Em seguida, adiciono uma linha "Porta 23453" meu arquivo .ssh / config

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

Se eu abrir outro shell do Git Bash (sem fechar minha conexão existente) e tentar ssh na minha instância (com ssh foo), vejo o seguinte erro:

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

O grupo de segurança anexado a esta instância possui duas entradas, ambas TCP

22 (SSH) 0.0.0.0/0

23453 0.0.0.0/0

Meu melhor palpite é que a porta ainda está bloqueada pelo meu firewall.

A saída de sudo iptables -Lé a seguinte

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

O que parece bem aberto para mim.

ATUALIZAR

Depois de adicionar uma regra iptables

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

e tentando de novo, ainda sem sorte.

Saída 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

O que parece suficientemente aberto. Não tenho muita certeza de como procurar pacotes chegando ou atividades na porta. Mas a saída de netstat -ntlp(como 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

O que me parece mostrar o sshd no 23453.

Verifiquei novamente que a instância tem a porta aberta no grupo de segurança (Porta: 23453, Protocolo: tcp, Fonte: 0.0.0.0/0)

O que mais pode estar causando a falha na conexão via SSH?

Felicidades

POSTMORTEM

Agora posso me conectar. Era uma regra ausente no iptables. A saída do iptables -Lnow é assim:

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
ssh amazon-ec2 iptables redhat amazon-web-services Andrew Martin
fonte
Para quem não consegue ver a diferença entre o terceiro iptables -L(o ssh funciona) e o segundo iptables -L(o ssh está bloqueado). Observe a ordem das regras na cadeia INPUT (as 6 linhas abaixo do primeiro "destino"); elas são lidas de cima para baixo; portanto, no segundo conjunto de regras, "REJECT all" é atingido antes de "ACCEPT tcp" dpt: 23453 ". O terceiro conjunto de regras tem a entrada ACEITAR acima e, portanto, antes, a entrada REJEITAR.
Andrew Martin

Respostas:

12

O firewall da instância não tem essa porta aberta. Tente o seguinte 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

Observe que as regras do iptables precisam ser salvas para persistir após uma reinicialização. No RHEL, é isso:

/sbin/service iptables save
melsayed
fonte
Isso funcionou. Se alguém pudesse me dizer uma diferença importante entre a regra iptables de @ melsayed e a regra iptables de Frank, ficaria muito grato. Além disso, acho que isso significa que a resposta para minha pergunta final é "Sim, na AWS, é necessário abrir portas nos firewalls da instância do ec2, bem como em seus grupos de segurança". Obrigado a todos.
Andrew Martin
Tentei comentário sobre a resposta de Frank, mas eu não tenho rep suficiente ainda :)
melsayed
2
Basicamente, o comando iptables de Frank adiciona (-A) uma nova regra que permitiria a conexão a essa porta. O problema é que ela adiciona a regra no final da lista de regras do iptables. A última regra na lista iptables rejeita qualquer coisa que não seja explicitamente permitida antes. Como as regras do iptables são aplicadas em ordem, a conexão é correspondida e rejeitada antes mesmo de chegar à nova regra.
melsayed
2
Eu inseri uma nova regra na lista, na 3ª posição (-I ENTRADA 3). Que corresponde antes da regra de rejeição no final, permitindo a conexão. Como Frank mencionou, você pode usar o iptables -nvL para ver o número de pacotes correspondentes a cada regra, o que ajuda na depuração dessa configuração.
melsayed
/sbin/service iptables savenão está funcionando para mim, mesmo com o sudo.
precisa saber é o seguinte
2

Adicionar uma regra iptables 

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

que aceita tráfego de qualquer host, pela porta 23435, e tenta ssh, se vir algum pacote ou atividade, isso significa que os pacotes estão alcançando o servidor.

Se você não vir pacotes, isso significa que o grupo AWS Security não possui regra para permitir sua porta.

mas se você iptables -nvLvir tráfego nesta regra (por ), precisará executar "netstat -ntlp" e verificar se o daemon SSH está em execução na porta 2435. e assim por diante 0.0.0.0/0.

espero que essas etapas resolvam o problema. se ainda não, então me diga.

Farhan
fonte
1

Tem certeza de que o grupo de segurança está definido corretamente? Você clicou em "Aplicar alterações"? Muitas pessoas esquecem de aplicar suas alterações :)

"Número de arquivo inválido" geralmente significa tempos limite de conexão e a configuração do iptables parece correta.

Waleed Hamra
fonte
Eu caí na armadilha de "aplicar alterações" uma vez antes. Nunca mais. :)
Andrew Martin
-1

Caso alguém se depare com esse tópico porque mudou a porta padrão do ssh, aqui está uma solução que funcionou para mim:

  1. Para ignorar um firewall corporativo, alterei a porta para 80 em /etc/ssh/sshd_conf.
  2. Infelizmente, o Apache já estava instalado nessa instância, então não pude mais ssh.
  3. Eu desanexei o volume da instância.
  4. anexou a outra instância
  5. montou, alterou a porta no arquivo de configuração
  6. desanexou, anexou-o na instância antiga
  7. reiniciado: tudo de bom: D
Homezar
fonte