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
Show
Code: Alles auswählen
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBznIp2HIULTYk0th7hRb2YBy0svp1Ts0yhsfXRpbGSrAsZ0146RsRD22mC7GP7KbSfgXLhtxJJxy2CHCADWcoScJoQvlfqKqUkY26lvPJN0KXBCpzkEuZrkWlrap1k85F5eTOHKG5H9Mr51Q7Gq1AtynXqwPqsoPzV+ox5Qma9gCq31UctSQWq7kPb/q89ZKKyh41bszk+7u9UbEdGpIKvctJrjORNS2xbxL246xqDdQ3UsWZPt8xhdzrn+whLy53S0UDdHX1q57B/SsRhLGqgJIH2jvOUfe+1J7EOe9hC6rFKZMoikE5hZK2nH83QC9lx8qDUb+JSplhQFGKGRGnn rsa-key-20121003Nun 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: Alles auswählen
echo "" >> ~/.ssh/authorized_keysDann 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: Alles auswählen
test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL -login"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: Alles auswählen
# /etc/ssh/sshd_config
...
PermitRootLogin without-password
...Code: Alles auswählen
# /etc/ssh/sshd_config
...
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
...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.
... Fortsetzung folgt