Mit SSH Key sicher auf Server zugreifen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hier eine Beschreibung wie man seinen Server noch ein bischen sicherer machen kann indem man sich nicht nur über einen SSH Key anmeldet sondern auch das anmelden als root abschaltet...

    Zunächst besorgen wir uns PuttyGen um den SSH Key Paar (Private und Public) zu generieren und speichern PuttyGen ins selbe Verzeichniss wo auch die Putty.exe liegt (muss aber nicht sein, nur der Ordnung halber ;)). Kann aber auch sein das es bei eurer PuTTY Installation bereits dabei ist...

    Dann PuTTYgen starten und unten [x] SSH-2 RSA auswählen sowie 2048 bit eintragen (ist sicherer)
    Dann klickt ihr auf " Generate " und bewegt die Maus innerhalb des Fensters wild hin und her bis der grüne Balken voll ist :)

    Nun als Key comment am besten eure Mail Adresse eintragen und ein Key Passphrase eingeben (umso länger umso sicherer).

    Achtung!! Dieses Passphrase muss dann bei jedem Öffnen des Private keys eingegeben werden!

    Von der Benutzung einer leeren Passphrase ist jedoch abzuraten, weil sonst jeder, der evtl. in den Besitz dieser Datei kommt, sofortigen Zugriff auf alle zugehörigen Systeme erhält!
    Die Passphrase sollte aber auch nicht zu lang sein, denn sie wird doch das eine oder andere Mal abgefragt. Aber andererseits auch nicht zu kurz!

    Dann bitte beides abspeichern: Public Key am besten mit der Dateiendung " .pub " und Private Key mit der Dateiendung " .ppk " (.ppk weil ihr den Key mit putty nutzt)

    Das wichtigste Feld, ist das obige: Public key for pasting into OpenSSH authorized_keys file! Hier bitte den gesamten Inhalt des Feldes kopieren (STRG + C) und in ein neues leeres Text File einfügen (STRG + V): SSH-Public-authorized_keys.txt (Der Inhalt dieser Datei wird später auf den Server in die Datei " ~/.ssh/authorized_keys " kopiert.. Diesen Schritt könnt ihr auch überspringen und den Key direkt in die Datein einfügen wie im nächsten Schritt beschrieben)
    Die Zeile sähe dann zum Beispiel so aus:

    Spoiler anzeigen
    Code
    ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBznIp2HIULTYk0th7hRb2YBy0svp1Ts0yhsfXRpbGSrAsZ0146RsRD22mC7GP7KbSfgXLhtxJJxy2CHCADWcoScJoQvlfqKqUkY26lvPJN0KXBCpzkEuZrkWlrap1k85F5eTOHKG5H9Mr51Q7Gq1AtynXqwPqsoPzV+ox5Qma9gCq31UctSQWq7kPb/q89ZKKyh41bszk+7u9UbEdGpIKvctJrjORNS2xbxL246xqDdQ3UsWZPt8xhdzrn+whLy53S0UDdHX1q57B/SsRhLGqgJIH2jvOUfe+1J7EOe9hC6rFKZMoikE5hZK2nH83QC9lx8qDUb+JSplhQFGKGRGnn rsa-key-20121003

    Damit wären wir mit PuTTYgen fertig...


    Nun erstellt ihr einen neuen Shellbenutzer mit dem ihr euch künftig an dem Server anmeldet:
    useradd -m -s/bin/bash us3r
    Anstatt " us3r " (das ist der benutzer/login-name) könnt ihr aber auch irgendwas anderes eingeben...
    Dann wechselt ihr zu diesem neu angelegten Benutzer: su - us3r
    Dann müsst ihr erst das Verzeichniss " .ssh " erstellen: mkdir .ssh
    Und dann fügt ihr den oben als wichtig vermerkten und in die extra Datei (SSH-Public-authorized_keys.txt) gespeicherten Public Key in die Datei authorized_keys:

    Code
    echo "" >> ~/.ssh/authorized_keys


    (den key innerhalb "" einfügen)

    Dann startet ihr PuTTy und wählt euer Profil für den Server aus (oder legt euch eins an). Dann geht ihr links auf SSH -> Auth ... und wählt dann auf der rechten Seite unten bei " Private key file for authentication " das zuvor erstellste *.ppk File aus und geht links dann wieder auf Session und speichert das Profil.

    Und dann wars das erstmal auch schon und könnt euch Verbinden und das erst mal testen ;)
    ...Um euch anzumelden müsst ihr nun eben die Key Passphrase eingeben... Es ginge zwar auch ohne aber das wäre wie gesagt nicht sooo sicher fals jemand fremdes in den besitz des Public Keys kommen würde...

    Wenn das funktioniert könnt ihr Die Datei SSH-Public-authorized_keys.txt wieder löschen.


    Nutzt man nun slogin, ssh, oder scp will der Server auf der anderen Seite den Beweis, dass man zu einem der dort in der authorized_keys liegenden öffentlichen Schlüssel den privaten Teil hat.

    Der lokale Client verlangt also nach der Passphrase, um den (lokal in id_rsa) gespeicherten privaten Schlüssel zu "aktivieren".

    Passen beide Schlüssel zusammen, ist der Server davon überzeugt, dass wir einer derjenigen sind, die Zugang erhalten sollen...

    Um das beständige Nachfragen nach der Passphrase zu unterdrücken, ist es möglich einen ssh-agent beim Login zu starten.
    Dieser Agent bekommt die Passphrase übergeben, kann den privaten Schlüssel aktivieren und in Zukunft alle Fragen nach diesem Schlüssel stellvertretend beantworten.

    Für normale Konsolen-Logins bearbeiten wir dazu die Datei " .profile " und fügen ans Ende der Datei folgendes ein:

    Code
    test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL -login"

    Natürlich gibt's noch die "classic-Variante" mit eval `ssh-agent` und einem anschliessenden ssh-add. Aber es bleiben dann Probleme beim Killen der nach Sessionende übrigbleibenden Agents.

    Weitere Infos dazu könnt ihr auch hier nachlesen: http://wiki.ubuntuusers.de/SSH#Der-SSH-Agent


    Immer noch Probleme?

    Nun kann es sein, dass es trotzdem noch nicht passwortfrei funktionert, was könnte alles geprüft werden?

    • Ist der ssh-Zugriff überhaupt möglich? (Ein beliebtes Problem ist ... key_exchange ... connection closed by foreign host. Das liegt dann meist daran, dass die Reverse-Auflösung der eigenen IP-Adresse nicht mit dem Namen für den eigenen Host übereinstimmt.

      Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. Oder DNS in Ordnung bringen!


    • Passwort wird verlangt. Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: Das Verzeichnis " .ssh/ " und die die Datei " .ssh/authorized_keys " darf nur für den Eigentümer, der auch der "angepeilte" Nutzer sein muss, schreibbar sein. Auch das Home-Verzeichnis des angepeilten Nutzers darf ausschliesslich für den Eigenümer beschreibbar sein.

      ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

    • Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. M.W. ist die SSH2 auf Debian/GNU-Linux gepatcht und sucht die wie gehabt in ~/.ssh/authorized_keys, aber u.a. auf SuSE-Systemen habe ich schon gesehen, dass eben diese 2 angehängt werden muss.

    Erzwingen der Verwendung von Schlüsseln

    Wenn das jetzt alles so schön funktioniert, wollen wir ja auch die Anmeldung mit den Schlüsseln erzwingen. Wenn es nur den Root-Account betrifft, ist das relativ einfach:

    Code
    # /etc/ssh/sshd_config
        ...
        PermitRootLogin without-password
        ...

    Wenn auch andere Nutzer von der Schlüsselnutzung überzeugt werden sollen, dann sieht es etwas komplexer aus:

    Code
    # /etc/ssh/sshd_config
        ...
        PasswordAuthentication no
        ChallengeResponseAuthentication no
        UsePAM yes
        ...

    Wenn eine schlüsselfreie Anmeldung erkannt wird, versucht die SSH zuerst, PAM zu nutzen (UsePAM und ChallengeResponseAuthentication), zu erkennen am Passwort-Prompt Password:. Wenn das nicht funktioniert, versucht die SSH anschliessend noch mal selbst, das Passwort zu prüfen (PasswordAuthentication), der Passwort-Prompt ändert sich zu user@host's password:. PAM auszuschalten wäre auch möglicht, ist aber nicht nützlich, weil dann z.B. Session-Management über PAM nicht mehr funktioniert, einige Umgebungsvariablen nicht gesetzt werden usw. usf. Waren die oben angegebenen Manipulationen erfolgreich, so darf keinesfalls nach einem Passwort, sondern nur nach einer Passphrase (das ist dann die für den privaten Schlüssel) gefragt werden. Natürlich muss für derlei Versuche der SSH-Agent ausgeschaltet, oder wenigstens "gelähmt" sein (ssh-add -x).

    Ist das alles?
    Nein, natürlich nicht. Wenn nun mehrere Leute auf den den selben Account (z.B. root) einer Maschine zugreifen müssen und es sollen noch personenspezifische Dinge (History, Begrüssung, ... ) in z.B. der .bash_profile veranstaltet werden, dann gibt es eine ziemlich clevere Lösung:

    An den Anfang der dem Nutzer entsprechenden Zeile in .ssh/authorized_keys wird eine Option eingetragen. Diese Zeile sieht dann etwa so aus:

    enviroment="REMOTE_USER=heinz" 1024 37 1452609839509....

    Diese Umgebungsvariable lässt sich dann prima auswerten und alles andere muss vielleicht nicht mehr erklärt werden ;) (Übrigens: in der Manualseite zum sshd steht das alles beschrieben.)

    Achtung: Bei neueren SSH (was ist neu? Neuer als 3.4) muss in der Konfiguration extra erlaubt werden, dass Environment-Variablen gesetzt werden dürfen. Sonst werden die betroffenen Zeilen der authorized_keys einfach ignoriert. Die entsprechende Option heisst PermitUserEnvironment.

  • Super Tutorial. Hat alles funktioniert danke dafür.
    Ich habe allerdings eine "Verständnisfrage":

    Wie mache ich das, wenn ich von mehreren "Orten" auf den Pi via SSH zugreifen möchte?
    Ein SSH-Key pro Benutzer oder pro Ort? (PC und/oder Laptop)

    Sorry für diese (einfache) Frage aber irgendwie stehe ich gerade auf dem Schlauch obwohl ich mich sonst mit dieser Materie auskenne :D

  • Es ist ein Key pro Benutzer. Wenn ein Benutzer von mehreren Orten aus zugreifen können soll, dann muss er entweder den Key mit sich rumschleppen (z.B. auf nem USB-Stick) oder auf alle Rechner kopieren.

    Genau das macht diese Methode sicherer als das bloße Login per Passwort:
    Man braucht Passwort und Keyfile zum Login.

  • Ordoban hat Recht, ich möchte nur ergänzen.
    Wenn man Bedenken hat, ob der Schlüssel vertraulich bleibt in einer speziellen Umgebung, dann kann man durchaus einen extra Schlüssel dort verwenden und den dann beim leisesten Verdacht einer Kompromitierung nur diesen Schlüssel sperren anstatt den, den man sonst überall verwendet.
    Beispiel: Ich habe einen Server (RPI oder sonstwas) auf den ich per ssh (+key) zugreife und den selben Schlüssel verwende ich auch für GitHub, den Communityserver, etc
    Ich habe auch einen eigenen Uni-Account mit eigenem geschützten Home-Directory und bin häufig an diesen Uni-Rechnern und will auch von dort aus an meinen Server.
    Dann kann ich auf meinem Uni-Account einen zweiten Schlüssel haben mit dem ich mich anmelden kann, den ich aber im Falle eines Sicherheitsproblems an der Uni einfach aus der authorized_keys entfernen kann.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!