-
Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.
SSH einrichten - wie geht das am Einfachsten?
- Ersteller lin
- Erstellt am
Hi,
aber ob das Ergebnis auch gleich gut (=> sicher) ist?
Meine "Lösung" oder besser meine Empfehlung:
Und es kommt garantiert:
Ich persönlich lehne ein Verbiegen des Ports auf dem der sshd lauscht (22), ab.
Das ist IMHO lediglich Security through obscurity. Sicherheit wird nicht durch "Verstecken", sondern durch geeignete kryptogrfische Maßnahmen erreicht. Das einzige, was durch einen anderen Port erreicht wird, ist das das Log etwas kleiner wird. Der Spielmatz wird ausgesperrt - aber nur dieser.
Wers brauch kann ja fail2ban nutzen.
MfG Peter
aber ob das Ergebnis auch gleich gut (=> sicher) ist?
Meine "Lösung" oder besser meine Empfehlung:
- Via Yast (ja ...) den sshd als Dienst dauerhaft starten und auch in der Firewall freigeben (wird gern vergessen).
- Auf der Konsole eine Testverbindung zu diesem Server aufbauen (damit du weißt, ob es überhaupt funktioniert).
- Den sshd unbedingt härten. Dazu per Konsole:
- mit ssh-keygen ein zeitgemäßes (ich nehme 4K) Schlüsselpaar für den ssh-Nutzer (auf dem Client) erzeugen
- den public.key danach beim Nutzerkonto auf dem Server nach ~/.ssh/authorized_keys einfügen
- testen, ob jetzt eine ssh-Verbindung ohne Benutzerpasswort (also per Key) funktioniert (erst dann weitermachen!)
- /etc/ssh/sshd_config auf sshd_konfig_original kopieren (für Rückkehr im Fehlerfall ...) und die sshd_config editieren
- ServerKeyBits 2048 (default: 1028, muss nicht, ich nutze und empfehle es aber)
- LoginGraceTime 1m (da wir uns per PubkeyAuthentication einloggen reicht das völlig aus)
- PermitRootLogin no (immer per user einloggen, dann wenn nötig zum root werden)
- MaxAuthTries 2 (nur zwei Fehlversuche, wir nutzen ja PubkeyAuthentication)
- PubkeyAuthentication yes (nur kontrollieren, ist Standard, haben wir ja eigentlich schon oben getestet mit der Anmeldung per key)
- PasswordAuthentication no (das ist die eigentliche wichtige Änderung, welche uns die gewollte Sicherheit bringt!)
Und es kommt garantiert:
Ich persönlich lehne ein Verbiegen des Ports auf dem der sshd lauscht (22), ab.
Das ist IMHO lediglich Security through obscurity. Sicherheit wird nicht durch "Verstecken", sondern durch geeignete kryptogrfische Maßnahmen erreicht. Das einzige, was durch einen anderen Port erreicht wird, ist das das Log etwas kleiner wird. Der Spielmatz wird ausgesperrt - aber nur dieser.
Wers brauch kann ja fail2ban nutzen.
MfG Peter
ssh-keygen fragt nach dem Passwort.
Wozu sollte ich das extra noch erwähnen? Hier muss <user> selber nachdenken.
Erwähnenswert, und deshalb das ToDo, ist, dass man heutzutage keinen sshd mehr mit direktem root-Zugriff und nur mit Passwort-Authentisierung betreiben sollte. Und nur darauf kam es mir an.
Wozu sollte ich das extra noch erwähnen? Hier muss <user> selber nachdenken.
Erwähnenswert, und deshalb das ToDo, ist, dass man heutzutage keinen sshd mehr mit direktem root-Zugriff und nur mit Passwort-Authentisierung betreiben sollte. Und nur darauf kam es mir an.
A
Anonymous
Gast
In der Datei /etc/ssh/sshd_config ist dieser Eintrag bereits vorhanden, alle anderen aus deiner Liste sind auskommentiert./dev/null schrieb:
—
Welchen Port empfielst du für ssh? 22? – Aber was, wenn nun mehrere Rechner hinter einem Router lauschen?
—
Entschuldige, das verstehe ich jetzt von dir nicht richtig:/dev/null schrieb:
1) […] dass man heutzutage keinen sshd mehr mit direktem root-Zugriff und nur mit Passwort-Authentisierung betreiben sollte.
2) […] dass man heutzutage keinen sshd mehr mit direktem root-Zugriff oder mit Passwort-Authentisierung betreiben sollte.
Meinst du nun 1) oder 2)?
@Sauerland: Wo du Recht hast, hast du Recht ;-) Und sogar ich mache das per Yast, wie beschrieben und incl. der Portfreigabe.
@rolandb:
Also in meiner, zugegebenermaßen nicht mehr ganz frischen Muster-config aus dem Jahr 2012 steht:
Und ich verweise auf das "change to no here!" Da ich das bei allen meinen Systemen selbstverständlich geändert habe, kann ich nicht mehr nachweisen, ob bei 13.2 nun "yes" oder "no" stand. Ist doch letztendlich auch egal. Wichtig ist, es steht definitiv jetzt "no" drin. Also zumindest überprüfen.
Alle sshd lauschen auf :22.
Aber im Router mache ich für jedes meiner Geräte die ich unbedingt direkt aus dem INet erreichen will (es handelt sich hier um ein rein privates Homenetz, und ich will auch nicht alles von außen erreichbar haben - dafür habe ich ein IPsec-VPN) eine entsprechende Weiterleitung. Der für mich gut merkbare Port aus dem INet ist "22<Hostanteil_IP-Adresse_im_Netz>". Also meinetwegen "22201" für den Rechner 192.168.188.201. (Die .188. ist wegen des VPN-Routings!) Aber wie gesagt, weil ich mehrere Geräte per ssh erreichen will und nicht etwa, um eine Pseudosicherheit zu erreichen.
Ich empfehle niemandem, einen sshd so zu betreiben, dass man sich dort gleich als root anmelden kann (*) und ich empfehle jedem, selbst bei einem kleinen RasPi oder anderen Spielsachen, die Anmeldung mit Benutzername/Passwort zu deaktivieren und ausschließlich PubkeyAuthentication mit zeitgemäßen Schlüsseln zu verwenden (und auch diese wie alle PW regelmäßig zu wechseln).
(*) Ich habe eine einzige Ausnahme, wo es nicht anders geht: mein Synology-NAS. Dort muss man sich als root anmelden.
Ich habe auf jedem meiner Rechner (und auch auf dem Schlau-Fernsprechgerät) ein eigenes Schlüsselpaar, und in der authorized_keys der als Server fungierenden Geräte alle meine publickKeys drin. Somit kann ich mit jedem Gerät auf alle betreffenden Geräte zugreifen.
Letzendlich ist das sogar bequemer, als mit Benutzername/Passwort.
So, ich denke ich habe jetzt alles gesagt.
MfG Peter
@rolandb:
Also in meiner, zugegebenermaßen nicht mehr ganz frischen Muster-config aus dem Jahr 2012 steht:
Code:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yesIch sehe hinsichtlich der Erhöhung der Sicherheit keinen Sinn darin, nur deswegen den ssh-Port zu verbiegen. Mitunter kommt ja so was als "guter Ratschlag". Es kann sogar zu Problemen führen, wenn auf manchen ssh-Clients oder sshd-Servern bestimmter Geräte (wo man nicht so einfach die config ändern kann) der Port fest einprogrammiert ist. So manches Sync-Programm erwartet einfach diesen Port.
Genau das ist bei mir der Fall. Ich mache das so:
Alle sshd lauschen auf :22.
Aber im Router mache ich für jedes meiner Geräte die ich unbedingt direkt aus dem INet erreichen will (es handelt sich hier um ein rein privates Homenetz, und ich will auch nicht alles von außen erreichbar haben - dafür habe ich ein IPsec-VPN) eine entsprechende Weiterleitung. Der für mich gut merkbare Port aus dem INet ist "22<Hostanteil_IP-Adresse_im_Netz>". Also meinetwegen "22201" für den Rechner 192.168.188.201. (Die .188. ist wegen des VPN-Routings!) Aber wie gesagt, weil ich mehrere Geräte per ssh erreichen will und nicht etwa, um eine Pseudosicherheit zu erreichen.
Sowohl als auch.
Ich empfehle niemandem, einen sshd so zu betreiben, dass man sich dort gleich als root anmelden kann (*) und ich empfehle jedem, selbst bei einem kleinen RasPi oder anderen Spielsachen, die Anmeldung mit Benutzername/Passwort zu deaktivieren und ausschließlich PubkeyAuthentication mit zeitgemäßen Schlüsseln zu verwenden (und auch diese wie alle PW regelmäßig zu wechseln).
(*) Ich habe eine einzige Ausnahme, wo es nicht anders geht: mein Synology-NAS. Dort muss man sich als root anmelden.
Ich habe auf jedem meiner Rechner (und auch auf dem Schlau-Fernsprechgerät) ein eigenes Schlüsselpaar, und in der authorized_keys der als Server fungierenden Geräte alle meine publickKeys drin. Somit kann ich mit jedem Gerät auf alle betreffenden Geräte zugreifen.
Letzendlich ist das sogar bequemer, als mit Benutzername/Passwort.
So, ich denke ich habe jetzt alles gesagt.
MfG Peter
A
Anonymous
Gast
Dieser Wert steht bei openSUSE 12.3 auch schon auf no./dev/null schrieb:
Damit vereinfacht sich die Sache ein Stückchen. – Hat das SuSE-Team den Tipp von Dir bekommen?
Ja gut, danke, aber wenn du schon die Zahl 188 in den Raum stellst, könntest du noch ihre Bedeutung für IPsec-VPN erläutern,
oder aber einen Verweis auf einen vernünftig geschriebenen Text in Buchform geben, was sich leicht anhört, aber nicht so ist.
OK, also doch noch eine Antwort hier ...
Plumpes Routing ...
Du kannst ein Routing nur von einem Netzwerk in ein anderes durchführen.
Mein Smartphone und mein außerhäusig betriebenes Notebook (auf dem ich gerade tippe) sind via UMTS-Router (=> private IP von diesem Router) im INet, erhalten aber vom VPN eine IP aus meinem Homenet. => zwei Netzbereiche, Routing funktioniert, ich kann also jedes Gerät zu Hause direkt ansprechen.
Jetzt befinde ich mich bei einem Freund, der auch eine Fritz!Box betreibt (192.168.178.0/24), meine Geräte erhalten also eine IP aus diesem Netz. Wenn ich jetzt mein Homenet ebenfalls unter dem gleichen Netz betreibe, erfolgt kein Routing in mein eigenes Netz. Schlimmstenfalls ist sogar die mir vom VPN zugeteilte (festgelegte) IP schon im Netz des Freundes vergeben, und meine Geräte versuchen, sich mit dieser IP zu verbinden (zum Bsp. für den automatischen Syc. von Kalendern und Adressbüchern mit meiner ownCloud auf dem RasPi).
Ändere ich jetzt aber einmalig mein Heimnetz auf einen "unüblichen" IP-Bereich, wird mir das o.g. mit sehr großer Sicherheit nie passieren.
OK?
MfG Peter
Plumpes Routing ...
Du kannst ein Routing nur von einem Netzwerk in ein anderes durchführen.
Mein Smartphone und mein außerhäusig betriebenes Notebook (auf dem ich gerade tippe) sind via UMTS-Router (=> private IP von diesem Router) im INet, erhalten aber vom VPN eine IP aus meinem Homenet. => zwei Netzbereiche, Routing funktioniert, ich kann also jedes Gerät zu Hause direkt ansprechen.
Jetzt befinde ich mich bei einem Freund, der auch eine Fritz!Box betreibt (192.168.178.0/24), meine Geräte erhalten also eine IP aus diesem Netz. Wenn ich jetzt mein Homenet ebenfalls unter dem gleichen Netz betreibe, erfolgt kein Routing in mein eigenes Netz. Schlimmstenfalls ist sogar die mir vom VPN zugeteilte (festgelegte) IP schon im Netz des Freundes vergeben, und meine Geräte versuchen, sich mit dieser IP zu verbinden (zum Bsp. für den automatischen Syc. von Kalendern und Adressbüchern mit meiner ownCloud auf dem RasPi).
Ändere ich jetzt aber einmalig mein Heimnetz auf einen "unüblichen" IP-Bereich, wird mir das o.g. mit sehr großer Sicherheit nie passieren.
OK?
MfG Peter
A
Anonymous
Gast
Hallo Peter,
das einzige, was ich im Moment verstehe, ist, dass die 188 von Dir willkürlich gewählt wurde, um Konflikte mit 0, 1, 2, 178 zu vermeiden, da diese Lokal IP Nummern (im dritten Block) in Consumer-Routern zumeist voreingestellt sind.
Aber wie ein UMTS-Modem+Router mit einem ADSL-Modem+Router per VPN zusammenarbeitet ist mir ein Rätsel. Ich bin natürlich gewillt das zu lernen, aber dazu sollte ich das Netzschema mal auf einem Blatt Papier sehen. So ist das viel zu abstrakt.
Mirko Dölle oder Michael Kofler – ich würde ja von beiden Autoren Bücher kaufen, wenn sie günstig wären…
Und sowas findet man leider nicht in einer Bücherei, um das mal durchzublättern.
das einzige, was ich im Moment verstehe, ist, dass die 188 von Dir willkürlich gewählt wurde, um Konflikte mit 0, 1, 2, 178 zu vermeiden, da diese Lokal IP Nummern (im dritten Block) in Consumer-Routern zumeist voreingestellt sind.
Aber wie ein UMTS-Modem+Router mit einem ADSL-Modem+Router per VPN zusammenarbeitet ist mir ein Rätsel. Ich bin natürlich gewillt das zu lernen, aber dazu sollte ich das Netzschema mal auf einem Blatt Papier sehen. So ist das viel zu abstrakt.
Mirko Dölle oder Michael Kofler – ich würde ja von beiden Autoren Bücher kaufen, wenn sie günstig wären…
Und sowas findet man leider nicht in einer Bücherei, um das mal durchzublättern.
hallo und guten Abend Peter, Roland und Sauerland.
vielen Dank für die postings. Hab es überflogen. Das ist ja geballt u. dichte Information!! Also der ssh ist enabled. Ich komm auch auf den Server - aber da ich die authentifizierung noch einbinden muss bricht das dann auch ab (s.u.)
Der Hintergrund - das Problem das mich zum Tunneln bringt: Ich hab auf einem SERVER Webmin drauf. ich komm aber nicht auf den webmin. Deshalb müssen wir tunneln
Also bei dem Vesuch webmin zu ereichen liegt ggf. ein bug vor: Das einzige was noch sein kann ist da eine IP nicht zu Domain auflöst ,
eigentlich dürfte das nicht passieren bei vodafone und tkom, Wir haben mal einen Bug report geschickt - siehe unten.
Ergo probier ich es jetzt mit einen port forward mit
und geh dann eben mit dem Browser auf https://127.0.0.1:7799
also zum tunneln geh ich vor wie folgt;
das sieht dann so aus;
ja - ich hab noch einen pub-key einzubinden. Der liegt vor auf dem Rechner. Denke, dass es mit den "Authentication"-settings un den "authorized_keys" file zu tun hat.
Frage; Wie binde ich denn den pub-key denn am besten ein?
Das Muster nach dem ich vorgegangen bin:
wobei die Syntax folgenden Regeln folgt;
also die Frage; Wie binde ich denn den pub-key denn am besten ein?
Zum vermuteten Bug auf Webmin: wir haben mal einen Bug report an webmin geschickt. Irgendwo ist ein Fehler
wenn die IP DNS dieses Format hat:
BTW; noch ne zusatzfrage: kann ich denn auch mit filezilla-tunneln!?
vielen Dank für die postings. Hab es überflogen. Das ist ja geballt u. dichte Information!! Also der ssh ist enabled. Ich komm auch auf den Server - aber da ich die authentifizierung noch einbinden muss bricht das dann auch ab (s.u.)
Der Hintergrund - das Problem das mich zum Tunneln bringt: Ich hab auf einem SERVER Webmin drauf. ich komm aber nicht auf den webmin. Deshalb müssen wir tunneln
Also bei dem Vesuch webmin zu ereichen liegt ggf. ein bug vor: Das einzige was noch sein kann ist da eine IP nicht zu Domain auflöst ,
eigentlich dürfte das nicht passieren bei vodafone und tkom, Wir haben mal einen Bug report geschickt - siehe unten.
Ergo probier ich es jetzt mit einen port forward mit
Code:
ssh/sftp=20 7799:127.0.0.1:7799und geh dann eben mit dem Browser auf https://127.0.0.1:7799
also zum tunneln geh ich vor wie folgt;
das sieht dann so aus;
Code:
linux-70ce:/home/martin # ssh -p525 -L 7799:127.0.0.1:7799 vhost@www2.myhost.org
The authenticity of host '[www2.myhost.org]:525 ([xxx.yy.zz.www]:525)' can't be established.
ECDSA key fingerprint is 33:1e:c5:d7:22:11:7c:aa:46:be:83:dc:eb:ee:13:00.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added '[www2.myhost.org]:525,[xxx.yy.zz.www]:525' (ECDSA) to the list of known hosts.
Permission denied (publickey).
linux-70ce:/home/martin # ssh -p525 -L 7799:127.0.0.1:7799 vhost@www2.myhost.org
Permission denied (publickey).ja - ich hab noch einen pub-key einzubinden. Der liegt vor auf dem Rechner. Denke, dass es mit den "Authentication"-settings un den "authorized_keys" file zu tun hat.
Frage; Wie binde ich denn den pub-key denn am besten ein?
Das Muster nach dem ich vorgegangen bin:
Code:
ssh -L localport:host:hostport user@ssh_server -Nwobei die Syntax folgenden Regeln folgt;
Quelle: http://www.linuxhorizon.ro/ssh-tunnel.html
also die Frage; Wie binde ich denn den pub-key denn am besten ein?
Zum vermuteten Bug auf Webmin: wir haben mal einen Bug report an webmin geschickt. Irgendwo ist ein Fehler
wenn die IP DNS dieses Format hat:
Hmm - Vermutlich sind die Minuszeichen das Problem.
BTW; noch ne zusatzfrage: kann ich denn auch mit filezilla-tunneln!?