OpenSSH를 사용하여 로컬 컴퓨터에서 SSH 서버를 설정하려고합니다. 원격 호스트에서 로컬 SSH 서버로 SSH를 시도하면 SSH 서버가 응답하지 않고 요청 시간이 초과됩니다. 나는 단순히 간과하고있는 이것에 대한 확실한 수정이 있다고 확신합니다.
원격 호스트에서 SSH를 시도하면 다음과 같이됩니다.
yoshimi@robots:/$ ssh -vv volt@99.3.26.94
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out
robots내 원격 호스트는 어디에 있으며 99.3.26.94로컬 SSH 서버입니다.
SSH가 실행 중입니다
volt@arnold:~$ ps -A | grep sshd
5784 ? 00:00:00 sshd
arnold로컬 SSH 서버는 어디에 있습니까 ?
라우터에서 포트 포워딩 설정
포트 80과 22를 SSH 서버로 전달하도록 홈 라우터를 설정했습니다. 흥미롭게도 포트 80은 문제없이 작동했습니다. Apache 웹 디렉토리로 바로 이동합니다. 22 번 포트 – 그리 많지 않습니다.
NMap은 필터링되었다고 말합니다
yoshimi@robots:/$ nmap -p 22 99.3.26.94
Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT STATE SERVICE
22/tcp filtered ssh
Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds
robots내 원격 호스트는 어디에 있으며 99.3.26.94로컬 SSH 서버입니다.
IPTables가 아닙니다 (제 생각에는)
volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
… 그리고 나는 다른 방화벽을 가지고 있지 않습니다. 비교적 데비안 netinst입니다.
그렇다면 : 다른 무엇을 할 수 있습니까? 확실히 트래픽을 무시하는 방화벽과 같은 것 같습니다.하지만 라우터가 아닌 경우 iptables가 아니며 SSH 서버의 다른 방화벽이 아닙니다.
편집 : 내부 네트워크 오류로 인한 연결 요청
yoshimi@robots:/$ ssh volt@192.168.1.90
ssh: connect to host 192.168.1.90 port 22: No route to host
답변
매우 실망스러운 자기 대답
이 문제를 하루 동안 제쳐두고 다시 돌아 왔을 때, 나는 모든 것이 신비하게 올바르게 작동한다는 것을 알기 위해 안심하고 교란했습니다 (안심보다 교란되었습니다).
그렇다면 무엇이 문제였습니까?
라우터, SSH 서버 및 SSH 클라이언트 시스템이 아닌 설정이 변경되거나 조정되지 않았습니다. 라우터가 적절한 설정에도 불구하고 들어오는 트래픽을 제대로 처리하지 못한다고 말하는 것이 상당히 안전합니다. 딩키 홈 라우터 소프트웨어가 실제로 포트 전달을 처리하도록 설계 되지 않았기 때문에 가난한 사람이 필요한 변경을 구현하는 데 시간이 걸렸습니다.
그러나 그것은 6 시간과 같았다!!
그래 친구 야 나는 하루 종일 무엇이 잘못되었는지 알아 내려고 노력했다 . 잘못 이 없기 때문에 그것을 찾지 못했다 . 라우터 설정이 적용 되려면 6 시간이 소요될 수 있습니다.
이것이 내 문제인지 어떻게 알 수 있습니까?
이 도피하는 동안 내가 만난 멋진 도구는 tcpdump입니다. 이 마른 작은 녀석은 트래픽을 스니핑하여 실제로 진행중인 작업에 대한 귀중한 통찰력을 제공합니다. 또한, 그는보고자하는 대상을 정확하게 좁힐 수있는 수퍼 필터링 기능을 갖추고 있습니다. 예를 들어, 다음 명령은
tcpdump -i wlan1 port 22 -n -Q inout
지시 tcpdumpwlan1 인터페이스 (를 통해 트래픽을 찾기 위해 -i= ‘인터페이스’), DNS 이름 확인 (무시 만 포트 (22) -n= ‘이름없는 해상도를’), 우리는 들어오고 나가는 트래픽을 (보고 싶어 -Q수락 in, out또는 inout; inout기본값입니다).
원격 시스템을 통해 연결을 시도하는 동안 SSH 서버에서이 명령을 실행하면 문제가있는 정확한 위치를 신속하게 알 수 있습니다. 본질적으로 3 가지 가능성이 있습니다.
- 당신이보고있는 경우 들어오는 원격 시스템,하지만 트래픽을 더 보내는 로컬 서버의 트래픽, 서버에 문제가 거짓말 : 요구 사항이 변경되는 것을 방화벽 규칙 등이 거기에 아마
- 수신 및 발신 이 모두 표시 되지만 원격 시스템이 응답을 수신하지 않는 경우 라우터 일 가능성이 높습니다. 수신 트래픽은 허용하지만 발신 패킷은 삭제합니다.
- 트래픽 이 전혀없는 경우 라우터 문제 일 수도 있습니다. 원격 시스템의
SYN패킷은 서버에 도달하기 전에 라우터에 의해 무시되고 삭제됩니다.
그리고 문제가 어디에 있는지 발견하면, 수정은 (보통) 사소한 것입니다.
답변
Mint (Ubuntu)를 실행 중입니다.
나는 모든 권한을 부여했습니다 … authorized_keys, chmodding, chowning, ssh 및 sshd 등의 올바른 형식으로 공개 키. 모든 곳에서 문서화되었습니다.
저에게는 ufw 방화벽이었습니다. ssh 응답이 전혀 없기 때문에이 문제를 해결할 수 있었지만 LAN에서 두 가지 방법으로 문제를 해결할 수는 없었습니다.
나는 테스트했다 :
sudo ufw service stop
… 완벽하게 작동했습니다. 즉, ssh 호출에서 응답을 받았습니다.
따라서 ufw를 다시 시작하십시오.
sudo ufw service start
… 그리고 규칙을 추가하십시오 :
sudo ufw allow openssh
모두 잘 작동합니다.
답변
나처럼 UFW를 활성화했다면 (Linux에서는 내 경우 우분투) 다음을 시도하십시오.
sudo ufw enable OpenSSH
방화벽에서 OpenSSH가 허용됩니다.
답변
다른 사람들을 위해서만 :
-Q 대신 tcpdump에서 -P 옵션을 사용해야했습니다.
tcpdump -i wlan1 port 22 -n -P inout
답변
대부분의 경우 방화벽은 범인입니다. 수행 service iptables stop과 service ip6tables stop.
서비스 중지가 작동하지 않으면 iptable flush를 수행하십시오.
iptables --flush.
VM이 호스트에서 동일하게 수행되는 경우