it-swarm.com.de

SSH-Server beantwortet keine Verbindungsanfragen

Ich versuche, mit OpenSSH einen SSH-Server auf meinem lokalen Computer einzurichten. Wenn ich versuche, SSH von einem Remote-Host auf meinen lokalen SSH-Server zu übertragen, antwortet der SSH-Server nicht und die Anforderung läuft ab. Ich bin mir ziemlich sicher, dass es eine wirklich offensichtliche Lösung dafür gibt, die ich einfach übersehen habe.

Folgendes passiert, wenn ich versuche, SSH von einem Remote-Host aus zu aktivieren:

[email protected]:/$ ssh -vv [email protected]
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

Wobei robots mein Remote-Host ist und 99.3.26.94 ist mein lokaler SSH-Server.

SSH läuft

[email protected]:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

Wobei arnold mein lokaler SSH-Server ist.

Portweiterleitung ist auf dem Router eingerichtet

Ich habe meinen Heimrouter so eingerichtet, dass er die Ports 80 und 22 an meinen SSH-Server weiterleitet. Interessanterweise funktionierte Port 80 reibungslos - geht direkt in das Apache-Webverzeichnis. Port 22 - nicht so sehr.

NMap sagt, es ist gefiltert

[email protected]:/$ 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

Wobei robots mein Remote-Host ist und 99.3.26.94 ist mein lokaler SSH-Server.

Es ist nicht IPTables (glaube ich)

[email protected]:~$ 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            

... und ich habe keine anderen Firewalls - es ist ein relativ frisches Debian-Netzwerk.

Also, dann: Was könnte es sonst sein? Es scheint sicherlich eine Art Firewall zu sein, den Datenverkehr einfach zu ignorieren, aber wenn es nicht das ist Router, es ist nicht iptables, und es ist keine andere Firewall auf dem SSH-Server, ... was zum Teufel gibt es sonst noch?

BEARBEITEN: Verbindungsanforderung aufgrund eines internen Netzwerkfehlers

[email protected]:/$ ssh [email protected]
ssh: connect to Host 192.168.1.90 port 22: No route to Host
14

Eine sehr enttäuschende Selbstantwort

Nachdem ich dieses Problem für einen Tag beiseite gelegt hatte und darauf zurückgekommen war, war ich sowohl erleichtert als auch beunruhigt (eher beunruhigt als erleichtert), als ich feststellte, dass auf mysteriöse Weise alles richtig funktionierte.

Also, was war das Problem?

Es wurden keine Einstellungen geändert oder angepasst - nicht auf dem Router, nicht auf dem SSH-Server und nicht auf dem Computer des SSH-Clients. Es ist ziemlich sicher zu sagen, dass der Router den eingehenden Datenverkehr trotz der richtigen Einstellungen nicht richtig verarbeitet hat. Angesichts der Tatsache, dass die versaute Heimrouter-Software nicht wirklich für die Portweiterleitung ausgelegt ist, hat der arme Kerl eine Weile gebraucht, um die erforderlichen Änderungen umzusetzen.

Aber es ist wie 6 Stunden gewesen !!

Ja Alter, ich weiß. Ich habe den ganzen Tag versucht herauszufinden, was los war - und habe es nie gefunden, weil dort nichts falsch war. Offensichtlich kann es 6 Stunden - möglicherweise länger - dauern, bis die Router-Einstellungen wirksam werden.

Woher weiß ich, ob dies mein Problem ist?

Ein nützliches Werkzeug, auf das ich während dieser Eskapade gestoßen bin, ist tcpdump. Dieser schlanke kleine Kerl schnüffelt Verkehr für Sie und bietet wertvolle Einblicke in das, was tatsächlich vor sich geht. Außerdem hat er einige super Filterfunktionen, mit denen Sie genau eingrenzen können, wonach Sie suchen/suchen. Zum Beispiel der Befehl:

tcpdump -i wlan1 port 22 -n -Q inout

Weist tcpdump an, über die wlan1-Schnittstelle nach Verkehr zu suchen (-i = 'Schnittstelle') ignoriert nur über Port 22 die DNS-Namensauflösung (-n = 'keine Namensauflösung'), und wir möchten sowohl eingehenden als auch ausgehenden Verkehr sehen (-Q akzeptiert in, out oder inout; inout ist die Standardeinstellung).

Wenn Sie diesen Befehl auf Ihrem SSH-Server ausführen, während Sie versuchen, eine Verbindung über einen Remotecomputer herzustellen, wird schnell klar, wo genau das Problem liegt. Grundsätzlich gibt es 3 Möglichkeiten:

  1. Wenn Sie eingehenden Datenverkehr von der Remote-Maschine sehen, aber keinen ausgehenden Datenverkehr von Ihrem lokalen Server, das Problem liegt beim Server: Es gibt wahrscheinlich eine Firewall-Regel, die geändert werden muss, etc.
  2. Wenn Sie sowohl eingehenden als auch ausgehenden sehen, Ihr Remotecomputer jedoch keine Antwort erhält, ist dies höchstwahrscheinlich der Router: Er lässt den eingehenden Datenverkehr zu , aber Ihre ausgehenden Pakete verwerfen.
  3. Wenn überhaupt kein Datenverkehr vorhanden ist , ist dies wahrscheinlich auch ein Routerproblem: Die SYN -Pakete des Remotecomputers werden von der ignoriert und verworfen Router, bevor sie überhaupt Ihren Server erreichen.

Und sobald Sie herausgefunden haben, wo das Problem liegt, ist eine Lösung (normalerweise) trivial.

18

Ich verwende Mint (Ubuntu).

Ich hatte alles getan ... öffentlicher Schlüssel im richtigen Format in autorisierten Schlüsseln, chmodding, chowning, Neustart von ssh und sshd usw. Wie alles überall dokumentiert wurde.

Für mich war es die ufw Firewall. Das Fehlen einer SSH-Antwort hat mich darauf hingewiesen, aber ich konnte in einem LAN problemlos in beide Richtungen pingen.

Ich habe getestet von:

Sudo ufw service stop

... und es hat perfekt funktioniert, d. h. ich habe eine Antwort von einem SSH-Anruf erhalten.

Starten Sie also erneut:

Sudo ufw service start

... und füge die Regel hinzu:

Sudo ufw allow openssh

Alles funktioniert jetzt gut.

3
Fiddy Bux

Wenn Sie wie ich UFW aktiviert haben (unter Linux, in meinem Fall Ubuntu), versuchen Sie Folgendes:

Sudo ufw enable OpenSSH

Dadurch wird OpenSSH in der Firewall zugelassen.

1
uranibaba

Meistens ist die Firewall ein Schuldiger. Tunservice iptables stop und service ip6tables stop.

Wenn das Beenden des Dienstes nicht funktioniert, führen Sie eine iptable-Spülung durch.

iptables --flush.

Wenn es a VM ist, dann machen Sie dasselbe auch in Host

0
Vijay S B

Nur für andere:

Ich musste die Option -P in tcpdump anstelle von -Q verwenden

tcpdump -i wlan1 port 22 -n -P inout
0
Esel