AW: Authrized_keys verwenden
der root benutzer hat sein home-dir hier: " /root/ " aber nicht in " / "
ausserdem muss
AuthorizedKeysFile in
/etc/ssh/sshd_config so eingestellt werden:
%h/.ssh/authorized_keys
(du hast es auf /home/ eingestellt aber laut deiner beschreibung das .ssh verzeichniss in " / " erstellt, das kann so also eh nicht gehen..)
das %h sorgt dafür dass das homedir verwendet wird, vom benutzer root ist das wie gesagt /root/ aber bei anderen normalen shell benutzern ist das /home/benutzer usw. das %h sorgt also dafür dass das automatisch immer passend ist
ich poste dir dazu mal meine Anleitung aus dem pebkac IPC forum:
====================================================================================================
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
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:
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:
(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:
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:
====================================================================================================
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:
Wenn auch andere Nutzer von der Schlüsselnutzung überzeugt werden sollen, dann sieht es etwas komplexer aus:
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.
