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 -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
답변
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.
이 단계가 문제를 해결하기를 바랍니다. 그래도 아니라면 말해주세요.
답변
보안 그룹이 올바르게 설정되어 있습니까? “변경 사항 적용”을 클릭 했습니까? 많은 사람들이 실제로 변경 사항을 적용하는 것을 잊습니다. 🙂
“잘못된 파일 번호”는 일반적으로 연결 시간 초과를 나타내며 iptables 설정이 올바르게 보입니다.
답변
ssh의 기본 포트를 변경 하여이 주제를 우연히 발견 한 경우 다음과 같은 해결책이 있습니다.
- 회사 방화벽을 우회하기 위해 포트를 80 on으로 변경했습니다
/etc/ssh/sshd_conf. - 불행히도 Apache는 이미 해당 인스턴스에 설치되어 더 이상 ssh를 할 수 없었습니다.
- 인스턴스에서 볼륨을 분리했습니다.
- 다른 인스턴스에 첨부
- 마운트하고 구성 파일에서 포트를 변경했습니다.
- 분리하고 이전 인스턴스에 다시 부착
- 재부팅 : 모두 양호 : D