SSH/Public-Keys: Unterschied zwischen den Versionen
K Textersetzung - „= Umgebungsvariablen =“ durch „= Umgebung =“ |
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“ |
||
Zeile 178: | Zeile 178: | ||
* Wenn auch das nicht mehr hilft, muss man das System zum Reparieren im Single-User-[http://de.wikipedia.org/wiki/Runlevel Runlevel] oder von einer Live-CD starten. | * Wenn auch das nicht mehr hilft, muss man das System zum Reparieren im Single-User-[http://de.wikipedia.org/wiki/Runlevel Runlevel] oder von einer Live-CD starten. | ||
== | == Aufruf == | ||
=== Parameter === | === Parameter === | ||
=== Optionen === | === Optionen === |
Aktuelle Version vom 12. November 2024, 18:47 Uhr
SSH/Public-Keys Authentifizierung über Public-Keys
Beschreibung
Wem die Authentifizierung über Passwörter trotz der Kryptografie zu unsicher ist, - immerhin könnte das Passwort ja erraten werden - der benutzt am besten das Public-Key-Verfahren.
- Hierbei wird asymmetrische Kryptografie genutzt, um den Benutzer zu authentifizieren.
- Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei ~/.ssh/authorized_keys des Zielsystems, der private Schlüssel in einer Datei (meist id_rsa) im Verzeichnis ~/.ssh auf dem lokalen System, wo er zusätzlich von einer "pass phrase" geschützt wird.
- Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte Challenge.
- Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt.
Damit man dieses Verfahren überhaupt verwenden kann, muss man sich zunächst mit Hilfe des Kommandozeilenprogramms ssh-keygen ein entsprechendes Schlüsselpaar erzeugen:
ssh-keygen -t rsa -b 4096 Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local The key's randomart image is: +--[ RSA 4096]----+ | | | | | | | + . | | S E | | . + + | | .o . o.| | o.oo. oo| | =o.BO+| +-----------------+
Der voreingestellte Dateiname (id_rsa) kann einfach mit der Taste ⏎ bestätigt werden, außer man möchte sich ein weiteres Schlüsselpaar erzeugen.
- 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.
Nun muss noch der öffentliche Schlüssel, zu erkennen an der Endung .pub (id_rsa.pub), auf dem Zielsystem deponiert werden.
- Dazu dient das Programm ssh-copy-id.
Zu diesem Zeitpunkt muss die Authentifizierung per Passwort noch erlaubt sein (PasswordAuthentication yes)
ssh-copy-id -i ~/.ssh/id_rsa.pub user@server Password: Now try logging into the machine, with "ssh 'user@server'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
Hinweis
Sollte man - warum auch immer - bei der Angabe des Dateinamens des Schlüssels die Endung .pub vergessen, so wird diese automatisch durch ssh-copy-id angehängt.
- Man kann also nie aus Versehen seinen privaten Schlüssel Namens id_rsa (also ohne Endung .pub) übertragen.
Sollte ssh-copy-id nicht funktionieren, kann man den öffentlichen Schlüssel auch anders auf das Zielsystem kopieren und in die Datei ~/.ssh/authorized_keys einfügen.
- Dabei ist unbedingt darauf zu achten, dass die Datei mit der Endung .pub und nicht der private Schlüssel ohne diese Endung verwendet wird:
cat id_rsa.pub | ssh server 'cat>> ~/.ssh/authorized_keys'
Wenn ein vom Standard abweichender Dateiname für den Key gewählt wurde, muss er mittels der Kommandozeilenoption -i ~/pfad/dateiname gesondert angegeben werden.
- Für die dauerhafte Nutzung empfiehlt sich ein Eintrag in der mittels IdentityFile-Parameter.
Hinweis
Bei der Datei ~/.ssh/authorized_keys sowie des Ordners ~/.ssh auf dem Server noch restriktiver gesetzt werden, falls diese neu erzeugt wurden und daher nur mit Standardrechten ausgestattet sind:
chmod 700 /home/BENUTZERNAME/.ssh chmod 600 /home/BENUTZERNAME/.ssh/authorized_keys
Anschließend kann man sich ohne Passwort anmelden:
ssh user@server Enter passphrase for key '/home/user/.ssh/id_rsa': Linux server.local 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 GNU/Linux The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Fri Mar 3 03:51:14 2006
In einigen Fällen tritt ein Fehler beim ersten Anmeldeversuch auf:
Agent admitted failure to sign using the key.
In diesem Fall einfach ssh-add ausführen.
ssh-add Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
Hinweis
Falls es noch nicht klappt kann es daran liegen, dass die Rechte beim Server nicht korrekt sind.
- sshd achtet darauf, dass das Homeverzeichnis, das dem Login-Namen entspricht (also die "Mappe" selbst), das .ssh-Verzeichnis und authorized_keys nur für den Eigentümer Schreibrechte hat.
- Hintergrund ist wohl, die Gefahr zu verringern, dass authorized_keys manipuliert wird und man keinen Zugriff mehr hat, wenn der Passwortzugang (s.u.) gesperrt ist.
Wer also bei bestimmten Konten auf dem Server auch einer Gruppe Schreibrechte gewähren will, muss evtl.
- die Optionen in /etc/ssh/sshd_config prüfen.
Jetzt ist es aber immer noch möglich, sich mit dem Passwort anzumelden.
- Um dies zu unterbinden, sind in der Datei /etc/ssh/sshd_config die Optionen
PasswordAuthentication no UsePAM no
zu setzen und mit einem
sudo /etc/init.d/ssh reload
die Konfiguration neu einlesen lassen.
Alternativ: Auf der Serverseite eingeben passwd -l <user>.
- Damit sind Passwörter nur für ausgewählte Accounts sperrbar.
Verschlüsseltes Home-Verzeichnis
Man sollte darauf achten, dass bei verschlüsselten Home-Verzeichnissen (ecryptfs) auch die authorized_keys mit verschlüsselt ist und somit nicht zur Authentifizierung verwendet werden kann, solange das Home-Verzeichnis nicht entschlüsselt ist (durch parallele Anmeldung mit dem gleichen Benutzernamen).
Eine Abhilfe ist zum Beispiel die authorized_keys in ein nicht-verschlüsseltes Verzeichnis zu legen (zum Beispiel /etc/ssh/username/) und die Einstellung AuthorizedKeysFile in der /etc/ssh/sshd_config auf /etc/ssh/%u/authorized_keys zu ändern (Root-Rechte und Neustart des SSH-Daemons erforderlich).
sudo mkdir /etc/ssh/$USER sudo mv $HOME/.ssh/authorized_keys /etc/ssh/$USER/ ln -s /etc/ssh/$USER/authorized_keys $HOME/.ssh/
Quelle: SSH with authorized_keys to an Ubuntu system with encrypted homedir?
Der SSH-Agent
Unter grafischen Desktop-Sitzungen (Unity, Gnome, etc.) startet automatisch im Hintergrund der SSH-Agent.
- In diesem werden automatisch die privaten Schlüssel abgelegt, sodass nicht jedes Mal die "pass phrase" abgefragt wird.
- Dies verbindet die Bequemlichkeit der Bedienung mit der Sicherheit des Public-Key-Verfahrens.
Zur direkten Interaktion mit dem SSH-Agenten im Terminal dient das Programm ssh-add, wobei die Option -l die augenblicklich gespeicherten Schlüssel auflistet:
ssh-add -l {{{ The agent has no identities. ssh-add Enter passphrase for /home/user/.ssh/id_rsa: Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) ssh-add -l 1024 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 /home/user/.ssh/id_rsa (RSA) ssh server Last login: Wed Mar 8 11:11:58 2006 from 192.168.4.56
Wenn man nicht über Unity oder eine andere graphische Benutzeroberfläche, die unter dem ssh-agent läuft, eingeloggt ist, funktioniert das so leider nicht.
- Dann muss man vorher noch ein
exec ssh-agent bash
ausführen, um eine Shell zu öffnen, die mit dem ssh-agent kommunizieren kann.
Arbeitet man oft im Terminal und möchte nicht immer wieder die "pass phrase" eingeben, kann man das folgende in seine .bashrc eintragen:
if [ $SSH_AGENT_PID ]; then if $(ssh-add -l) != *id_?sa* ; then ssh-add -t 2h ## Haltbarkeit von 2 Std. fi fi
Login über mehrere Rechner
Ab und zu muss man sich von Rechner zu Rechner hangeln, da kein direkter Zugriff besteht.
- Doch der Key wird nicht automatisch übertragen.
- Darum besteht die Möglichkeit dies direkt in der ~/.ssh/config zu vermerken.
ForwardAgent yes
SSH-Askpass
Wenn eines der Pakete ssh-askpass, ssh-askpass-gnome, ssh-askpass-fullscreen oder gtk-led-askpass installiert ist, kann ssh-add die Passphrase in Ermangelung eines Terminals auch über ein Dialogfenster abfragen.
- Das nutzt man sinnvollerweise, um seinen Schlüssel gleich nach der Anmeldung auf einem grafischen System zu laden .
- Für KDE-Nutzer gibt es das Paket ksshaskpass, das für ssh-add eine graphische Oberfläche zur Verfügung stellt.
Single-Sign-On
Wem immer noch zu umständlich ist, beim Login nacheinander erst das Login-Passwort und dann die SSH-Passphrase einzugeben, der installiert sich stattdessen das Paket libpam-ssh.
Mit den richtigen Einstellungen wird man beim Login nach der Eingabe des Benutzernamens nicht mehr nach dem Passwort, sondern nach der SSH-Passphrase gefragt und kann sich danach ohne nervige Passwortabfrage mittels SSH auf seinen Systemen bewegen.
Nur wenn man die Passphrase nicht richtig eintippt, kann man sich stattdessen auch mit seinem normalen Passwort authentifizieren.
- Zu beachten ist allerdings, dass der dann nicht mehr automatisch freigeschaltet wird.
Macht man hier einen Fehler, kann man sich eventuell nicht mehr am System anmelden.
- Sollte das passiert sein, ist es normalerweise noch möglich, sich per SSH einzuloggen und den Fehler zu beheben.
- Wenn auch das nicht mehr hilft, muss man das System zum Reparieren im Single-User-Runlevel oder von einer Live-CD starten.