AWS에서 EC2 인스턴스의 방화벽과 보안 그룹에서 포트를 열어야합니까?


8

SSH 포트를 22에서 23453으로 변경하면 더 이상 ssh in 할 수 없습니다.

더 자세하게는 Amazon Web Services에서 Red Hat EC2 인스턴스를 사용하고 있습니다. 이것은 새로 설치했을 때의 두 번째 변경입니다 (첫 번째 변경은 루트가 아닌 사용자를 추가하는 것이 었습니다).

Git Bash와 로컬 .ssh / config 파일을 사용하여 잘 ssh 할 수 있습니다. 현재 / etc / ssh / sshd_config에서 줄을 편집합니다.

#Port 23453

말하다

Port 23453

그런 다음 sshd를 다시 시작하십시오.

sudo service sshd restart

그런 다음 .ssh / config 파일 "Port 23453"행을 추가하십시오.

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

23453에 sshd를 표시하는 것 같습니다.

인스턴스가 보안 그룹에서 포트가 열려 있는지 다시 확인했습니다 (포트 : 23453, 프로토콜 : tcp, 소스 : 0.0.0.0/0)

SSH를 통한 연결 실패의 원인은 무엇입니까?

건배

검시

이제 연결할 수 있습니다. 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 works)와 두 번째 iptables -L(ssh가 차단됨) 의 차이점을 볼 수없는 사람 INPUT 체인의 규칙 순서 (첫 번째 "대상"아래의 6 줄)를 위에서 아래로 읽습니다. 따라서 두 번째 규칙 세트에서 "모두 거부"는 "ACCEPT tcp"이전에 적중됩니다. dpt : 23453 ". 세 번째 규칙 세트에는 ACCEPT 항목이 있으며 그 이전에는 REJECT 항목이 있습니다.
Andrew Martin

답변:


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

이것은 효과가 있었다. 누군가 @melsayed의 iptables 규칙과 Frank의 iptables 규칙 사이에 중요한 차이점을 말해 줄 수 있다면 매우 감사하겠습니다. 또한 이것이 내 궁극적 인 질문에 대한 대답은 "예, AWS에서 ec2 인스턴스 방화벽과 보안 그룹의 포트를 열어야한다는 것"입니다. 모두 감사합니다.
Andrew Martin

나는 Frank의 답변에 대해 언급하려고 노력했지만 아직 충분한 담당자가 없습니다. :)
melsayed

2
기본적으로 Frank의 iptables 명령은 해당 포트에 연결할 수있는 새 규칙을 (-A) 추가합니다. 문제는 iptables 규칙 목록 끝에 규칙을 추가한다는 것입니다. iptables 목록의 마지막 규칙은 명시 적으로 허용되지 않은 모든 것을 거부합니다. iptables 규칙이 순서대로 적용되므로 새 규칙에 도달하기 전에 연결이 일치 및 거부됩니다.
12:15에 melsayed

2
3 번째 위치 (-I INPUT 3)에서 목록에 새 규칙을 삽입했습니다. 마지막에 거부 규칙 전에 일치하므로 연결을 허용합니다. Frank가 언급했듯이 iptables -nvL을 사용하여 각 규칙과 일치하는 패킷 수를 확인할 수 있으며 이러한 구성을 디버깅하는 동안 도움이됩니다.
12:15에 melsayed

/sbin/service iptables savesudo에서도 작동하지 않습니다.
huertanix

2

iptables 규칙 추가

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

패킷 23435를 통해 모든 호스트의 트래픽을 수락하고 ssh를 시도하면 패킷이나 활동이 있으면 패킷이 서버에 도달하고 있음을 의미합니다.

패킷이 표시되지 않으면 AWS 보안 그룹에 포트를 허용하는 규칙이 없음을 의미합니다.

그러나이 규칙에 트래픽이 표시되면 iptables -nvL"netstat -ntlp"를 실행하고 SSH 데몬이 포트 2435에서 실행되고 있는지 확인해야합니다 0.0.0.0/0.

이 단계가 문제를 해결하기를 바랍니다. 그래도 아니라면 말해주세요.


1

보안 그룹이 올바르게 설정되어 있습니까? "변경 사항 적용"을 클릭 했습니까? 많은 사람들이 실제로 변경 사항을 적용하는 것을 잊습니다. :)

"잘못된 파일 번호"는 일반적으로 연결 시간 초과를 나타내며 iptables 설정이 올바르게 보입니다.


나는 "변경 사항 적용"함정에 한 번 파울을했다. 다시는 :)
Andrew Martin

-1

ssh의 기본 포트를 변경 하여이 주제를 우연히 발견 한 경우 다음과 같은 해결책이 있습니다.

  1. 회사 방화벽을 우회하기 위해 포트를 80 on으로 변경했습니다 /etc/ssh/sshd_conf.
  2. 불행히도 Apache는 이미 해당 인스턴스에 설치되어 더 이상 ssh를 할 수 없었습니다.
  3. 인스턴스에서 볼륨을 분리했습니다.
  4. 다른 인스턴스에 첨부
  5. 마운트하고 구성 파일에서 포트를 변경했습니다.
  6. 분리하고 이전 인스턴스에 다시 부착
  7. 재부팅 : 모두 양호 : D
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.