Hallo Ich habe einen Linux Server mit dem ich mich im lokalen Netzwerk mit Putty über den SSH Standard Port verbinde. Nun wollte ich die Möglichkeit einrichten, mich auch von außerhalb verbinden zu können. Dazu habe ich auf dem Zyxel Modem die angehängte Port Weiterleitung eingerichtet. ipfingerprints.com/ zeigt nun Port 82 als offen an, ich kann mich per Putty - SSH Port 82 - aber trotzdem nicht verbinden. Woran kann das liegen?
Der Linux-Server kennt die IP-Adresse Deines "Modems" (das dürfte eher ein Router sein) als Standardgateway resp. Router? Akzeptiert Deine SSH-Installation auch Verbindungen von nichtlokalen Adressen (d.h. welchen, die nicht in 192.168.30.0/24 liegen)?
Trigger Port klingt als wäre der nur dazu da, die Verbindung freizugeben. Diese muss dann vielleicht doch auf Port 22 erfolgen... Btw: Wenn man einen SSH Server am Internet betreibt sollte man übrigens immer die Passwort Authentifizierung abschalten und nur das Public Key Verfahren erlauben. Alle SSH Server sind permanenten Hacking-versuchen ausgesetzt...
PS: Port Forwarding funktioniert meist nur von außerhalb. Wenn du es von einem Rechner im selben lokalen Netz testest funktioniert es typischerweise nicht.
Dr. Sommer schrieb: > PS: Port Forwarding funktioniert meist nur von außerhalb. Wenn du > es von > einem Rechner im selben lokalen Netz testest funktioniert es > typischerweise nicht. Also mal mit einem anderen Zugang (z.B. Handy -> Tethering) testen ...
Frank E. schrieb: > Also mal mit einem anderen Zugang (z.B. Handy -> Tethering) hab ich gemacht und ging auf Anhieb. Komischerweise funktionierte danach auch der Zugang vom PC aus mit Putty... versteh wer kann... eine Frage noch, kann man in Putty einen Proxy definieren und so abspeichern dass jede Verbindung über diesen Proxy geht, ohne ihn jedesmal neu eingeben zu müssen?
Dr. Sommer schrieb: > Btw: Wenn man einen SSH Server am Internet betreibt sollte man übrigens > immer die Passwort Authentifizierung abschalten und nur das Public Key > Verfahren erlauben. Alle SSH Server sind permanenten Hacking-versuchen > ausgesetzt... Oder man macht fail2ban und das nicht mit den läppischen 10min Jail sondern gleich mit einem ganzen Tag oder so nach drei Fehlversuchen ;)
Georg A. schrieb: > Oder man macht fail2ban und das nicht mit den läppischen 10min Jail > sondern gleich mit einem ganzen Tag oder so nach drei Fehlversuchen ;) Das aber nur als zusätzliche Maßnahme (gegen DoS) - die eigentliche Sicherheit sollte aus der Public Key Authentifizierung kommen.
Dr. Sommer schrieb: > Das aber nur als zusätzliche Maßnahme (gegen DoS) - die eigentliche > Sicherheit sollte aus der Public Key Authentifizierung kommen. Damit kann man sich aber eben auch nur von eigenen Geräten einloggen. Das ist nicht immer hilfreich.
Georg A. schrieb: > Damit kann man sich aber eben auch nur von eigenen Geräten einloggen. Na, jeder dem man Zugang geben möchte kann einem ja seinen Public Key schicken. Bei GitHub & Co funktioniert es ja genauso - man trägt seinen Public Key im Web-Interface ein und kann fortan per Key auf Git-Via-SSH zugreifen. Das ist sogar komfortabler, weil man kein Passwort eingeben muss, sofern man seinen private key nicht verschlüsselt hat. Wenn man sich "unterwegs" von fremden Rechnern aus einloggen möchte, kann man seinen Key (verschlüsselt) per USB-Stick mitnehmen. Oder gleich so etwas nutzen: https://www.nitrokey.com/de
Dr. Sommer schrieb: > Btw: Wenn man einen SSH Server am Internet betreibt sollte man übrigens > immer die Passwort Authentifizierung abschalten und nur das Public Key > Verfahren erlauben. Alle SSH Server sind permanenten Hacking-versuchen > ausgesetzt... Es klingt lachhaft, aber es wirkt Wunder: wenn man den SSH-daemon auf einen (unprivileged) anderen Port verschiebt, reduzieren sich solche Versuche auf Null. Seit ich das bei meinen Kandidaten gemacht habe, kamen außer meinen eigenen Anfragen keine mehr. Natürlich schadet es nicht, wenn man trotzdem das public-key-Verfahren nutzt.
:
Bearbeitet durch User
Stephan E. schrieb: > Es klingt lachhaft, aber es wirkt Wunder: wenn man den SSH-daemon auf > einen (unprivileged) anderen Port verschiebt, reduzieren sich solche > Versuche auf Null. Ich weiß. Aber auch das würde ich nur als zusätzliche Maßnahme sehen. Sonst verlässt man sich nur auf sein Glück.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.