SSH nach außen öffnen

[Cyrics]

Hiho,

ich bin nun öfter unterwegs und muss meinen Server ab und zu auch mal von außen erreichen.

Ich hab mir einen DynDNS.org-Account besorgt und dort meine AusgangsIP eingetragen und bei meinem Router die Weiterleitung zum Server aktiviviert.
Es ist der HTTP und SSH-Port offen. Der Rest ist sowohl durch den Router als auch durch iptables gesperrt.
Als SSH-Port hab ich Port 666 gewählt, da mir der 22-Port einfach zu oft attackiert wird...

doch wie erreiche ich meinen Server nun von außen?
Port 666 und 80 sind wie gesagt freigeschaltet und meine Website erreich ich z.B. aber wenn ich meinen SSH-Server kontaktieren will, wird meine Anfrage ausgezählt bis zum Time-Out, was ja ein Hinweis darauf ist, dass ich geblockt werde.

Liegt es an der /etc/hosts.allow ?
Dort hab ich ALL: ALL
stehen. Und die Reportanweisung bei Finger-Attacken.

Grosses Fragezeichen!

Daten:
Server läuft Debian Sarge 2.6 Kernel

 

[mathilda]

Hi,
sagst Du denn Deinem ssh-client auch, dass er am Port 666 klopfen soll? Das machst Du mit dem Schalter -p.
Läuft denn Dein Server auch auf Port 666? Oder sagst Du Deinem Router: "Alles was bei 666 ankommt an den Server und den Port 22 weiterleiten"?
An Deiner Stelle würde ich den Server auf Port 22 laufen lassen, den Port 22 am Router auf Port 22 auf Deinem Server durchschleifen und die Passwortauthentifizierung in Deinem ssh-Server deaktivieren. Arbeite besser mit einer PKI. Auch wenn der Port 22 häufig attackiert wird, heisst das noch lange nicht, dass das eine ssh-Attacke ist (und nur die versteht ein ssh-Server). Der einzige Nachteil ist der, dass Traffic verursacht wird. Aber der wird auch verursacht, wenn Dein ssh-Server auf Port 666 läuft.
Wenn Du mit iptables Deinen Server härten willst, kannst Du ihm auch folgende Regel mit auf den Weg geben "Akzeptiere auf Port 22 nur ssh-Protokoll". Dann gibt es natürlich noch 1000 mehr Möglichkeiten, Deinen Server zu sichern, die Du bestimmt alle umgesetzt hast.
Sehr gute Wahl mit Debian. Bei mir läuft auch Debian.
Gruß,
- mathilda

 

[Cyrics]

hab viele Linux-Distributionen durch gehabt, aber bin einfach bei Debian hängen geblieben, dass Einfache hats mir einfach angetan *g*

jap, also hab meinem SSH-Client, bzw. der Config gesagt, dass er von nun auf 666 sendet. Genauso ist durch iptables 666 extra geöffnet und als SSH-Protokoll deklariert. Meine SSH-Anfrage findet ja auch im lokalen Netz ohne Probleme statt, nur nach außen hin werd ich abgeblockt (eigentlich eine tolle Sache gegen Hacker, aber ich will ja nun doch drauf *g*)

Also
ssh läuft auf Port 666, RSA-Authentifikation, Root und Co. sind deaktiviert und können sich nicht mal mehr per tty einloggen. SSH ist nur verfügbar für einen User -> ich. Mein Benutzername ist nicht unbedingt leicht erratbar, und die ganzen Attacken (es waren im übrigen SSH-Attacken) hatten nur Standarduser durchprobiert und meien Usernamen nicht mal rausgekriegt.
Bastille und Co. haben das System eigentlich schon gut abgeschottet. Aber ich denke nun, dass es zu gut abgeschottet ist, denn ich schaff ja meine Anfrage nicht mehr
und ich weiss einfach nicht woran es liegen kann.

Der erste Verdacht war ja die hosts.allow in /etc, aber die hat nun ALL: ALL drin stehen und es hat sich nichts geändert.
Und das ist mir wirklich nichts mit Port 22... das ist mehr als Bedänklich, da die ständigen Attacken doch schon etwas nerven und das Problem ist einfach die ständige Angst, dass es dann doch irgendwann jemanden gelingt meinen User rauszukriegen und dann beginnen erstmal die Passwort-Attacken... dann kriegen sie vielleicht mit, dass Passwörter nicht akzeptiert werden und dann beginnt das sinnlose generieren von Keys bis sie mitkriegen, dass der RSA-Key mit 2048 Bit verschlüsselt wurde... bis sie da angekommen sind, ist meine Log-Partition von 4 GB sicher komplett ausgefüllt... aber soweit will ich es einfach nicht kommen lassen.

Also das Hauptproblem:
es funktioniert alles komplett im lokalen Netz mit der selben Anfrage. Per DynDNS stell ich jetzt die Anfrage immer von außen auf den Server. Port 80, also HTTP antwortet, aber nicht SSH, da werd ich geblockt. Die Frage ist also wo in SSH die Beschränkung zu finden ist nicht nach außen zu senden.

 

[mathilda]

Es gibt jetzt 2 Möglichkeiten.
1. Deine ssh-Anfrage erreicht nie Deinen Server.
2. Sie erreicht ihn, aber die Antwort geht nicht dorthin zurück, wo sie hin soll.

Verwende doch mal den Schalter -v (verbose, heisst so viel schnattern) und schau Dir die Meldungen an. Kannst sie auch gern hier posten und ich werde ein Auge drüber werfen.

Frage: Wenn Du testest, bist Du dann tatsächlich ausserhalb Deines LANs, oder schickst Du von Deinem LAN die Anfrage an den Router, Port 666?
Noch eine Frage: Welchen Client verwendest Du?
- mathilda

 

[Cyrics]

Also als Client nehm ich das einfache Terminal *g*
und sonst hatte ich es auch mit Cyberduck probiert zu connecten, aber mit dem selben Problem (was ja eigentlich auch klar war)

Ich hab mal gleich mit 3mal -v gemacht:

localhost:~/.ssh Username$ ssh xxx.homeunix.org -p 666 -l username -i id_rsa -v -v -v
OpenSSH_3.8.1p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.homeunix.org [xxx.xxx.xxx.xxx] port 666.
debug1: connect to address xxx.xxx.xxx.xxx port 666: Operation timed out
ssh: connect to host xxx.homeunix.org port 666: Operation timed out

Ich connecte von außerhalb auf meinen Server. Hab nämlich 3 offene WLAN-Netze um mich herum *gggggggggg* das ist für solche Testzwecke sehr sehr nützlich

Bin auch etwas paranoid schon langsam und hab Usernamen, IP und Adresse abgeändert.

Was da auffällig ist, ist dass er die ssh_config liest und nicht die sshd_config, wie ich erst dachte... ich mir gleich mal die ssh_config anschauen gehen.
Danke schonmal für die Mühe!

Ich hatte sonst überlegt mal meinen Portscanner über den Server laufen zu lassen, aber ich hab den ja auch so eingestellt gehabt, dass er bei Portscanner-Aktivität alle Ports schliesst und blockt, also krieg ich nicht mal raus ob Port 666 wirklich was sendet oder einfach noch komplett geschlossen ist.

Edit:
hier noch der Auszug aus meinem firewall-Skript:

# SSH
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 666 -j ACCEPT

Das Skript hatte ich heute sonst schon neugestartet gehabt um einen solchen Fehler auszuschliessen.

 

[Trapper]

Was da auffällig ist, ist dass er die ssh_config liest und nicht die sshd_config, wie ich erst dachte... ich mir gleich mal die ssh_config anschauen gehen.

Das ist überhaupt nicht auffällig, denn du startest ja mit dem Aufruf ssh die Client-Anwendung. Warum sollte sich diese für die Daemon-Konfiguration interessieren?

 

[Cyrics]

ach jetztversteh ich erst. Der liest die ssh_config von meinem iBook! Na die ist ja relativ uninteressant für die Verbindung zu meinem Server und bedarf ja keiner Änderung.

Sorry, dachte eben, dass er die ssh_config auf meinem Server anspricht, aber die liegt ja auch in einem anderen Verzeichnis als /etc

 

[Cyrics]

PROBLEM GELÖST

es lag an meinem Router... ich hab nur die Weiterleitung des Ports aktiviert, aber vergessen die Firewall des Routers auch noch für den Port freizumachen...

Port 80 ist da nämlich standardmässig frei...

jetzt bleibt nur noch die Frage, wieso sich mein DynDNS-Account nicht selbständig aktualisiert. Denn der hatte heute mittag die alte IP von gestern noch drin, und ich musste ihn per Hand meine neue IP einflößen.

Das wäre etwas doof, weil ich ja dann von außerhalb schwer erraten kann wie gerade die IP meines Servers ist... habt ihr da eine Idee?

hab den ddclient auf meinem Server laufen.
Desweiteren unterstützt auch mein Router DynDNS und hat die Anmeldedaten etc. für den DynDNS-Account um sich dort zu aktualisieren?
Irgendeine Idee?

 

[Containy]

Desweiteren unterstützt auch mein Router DynDNS und hat die Anmeldedaten etc. für den DynDNS-Account um sich dort zu aktualisieren?
Irgendeine Idee?

Der DynDNS-Client muss am Router laufen, da er die IP vom ISP bezieht. Der Rechner hat nur eine lokale IP auf den der DNS-Name nicht aufgelöst werden kann.

Gruß,
Containy

 

[mathilda]

Der DynDNS-Client muss am Router laufen, da er die IP vom ISP bezieht.

Das stimmt nicht. Der DynDNS Client kann irgendwo laufen. Er muss nur die IP vom Router kennen und den Benutzernamen bei DynDNS. Es gibt zB Clients, die laufen auf einem Rechner im LAN, schauen sich die externe IP vom Router an und leiten die an Dyn DNS weiter. Dazu muss der Rechner natuerlich eingeschaltet sein. Deswegen laesst man den DynDNS besser auf dem Router laufen, aber das ist nicht zwingend.

Schoen, dass es doch noch geklappt hat.

Gruss,
- mathilda

 

[Containy]

Das stimmt nicht. Der DynDNS Client kann irgendwo laufen. Er muss nur die IP vom Router kennen und den Benutzernamen bei DynDNS. Es gibt zB Clients, die laufen auf einem Rechner im LAN, schauen sich die externe IP vom Router an und leiten die an Dyn DNS weiter. Dazu muss der Rechner natuerlich eingeschaltet sein. Deswegen laesst man den DynDNS besser auf dem Router laufen, aber das ist nicht zwingend.

Schoen, dass es doch noch geklappt hat.

Gruss,
- mathilda

Oh das wusste ich nicht, wieder was gelernt, vielen Dank.

Containy

 

[Cyrics]

ich hab es aber dem Router nun überlassen.
Den DDClient hab ich bei Debian entfernt, und hab die Zugangsdaten bei meinem Router überarbeitet, und nun hat sich das Problem irgendwie gelöst gehabt.

Zumindestens erreiche ich meinen Server immer noch obwohl schon über 24 Stunden vorbei sind :-D

und das schönste:
mein SSH ist sicher, mein SSH ist sicher, mein SSH ist sicher



bin sehr stolz auf meinen Server, und würde ihn jetzt knutschen, knuddeln und mit ins Bett nehmen, aber bin leider derzeit 300 km von ihm entfernt... muss er also ohne mich erstmal auskommen *g*
ich mach mich jetzt mal dran meine Website zu überarbeiten und dort hinzusetzen, weil die ct-Debian-Website doch ein wenig langweilig nun langsam aussieht *g*