|
|
| Zeile 47: |
Zeile 47: |
| <div class="mw-collapsible-content">'''Antwort5'''</div> | | <div class="mw-collapsible-content">'''Antwort5'''</div> |
| </div> | | </div> |
|
| |
| = TMP =
| |
| == Authentifizierung über Public-Keys ==
| |
| 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 <tt>ssh-keygen</tt> 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 <tt>ssh-copy-id</tt> 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 <tt>-i ~/pfad/dateiname</tt> gesondert angegeben werden.
| |
| * Für die dauerhafte Nutzung empfiehlt sich ein Eintrag in der mittels <tt>IdentityFile</tt>-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 <tt>.ssh</tt>-Verzeichnis und <tt>authorized_keys</tt> nur für den Eigentümer Schreibrechte hat.
| |
| * Hintergrund ist wohl, die Gefahr zu verringern, dass <tt>authorized_keys</tt> 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 <tt>passwd -l <user></tt>.
| |
| * 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 <tt>authorized_keys</tt> 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 <tt>authorized_keys</tt> in ein nicht-verschlüsseltes Verzeichnis zu legen (zum Beispiel /etc/ssh/username/) und die Einstellung ''AuthorizedKeysFile'' in der <tt>/etc/ssh/sshd_config</tt> 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: [http://superuser.com/questions/61057/ssh-with-authorized-keys-to-an-ubuntu-system-with-encrypted-homedir 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 <tt>ssh-add</tt>, wobei die Option <tt>-l</tt> 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 <tt>ssh-add</tt> 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-[http://de.wikipedia.org/wiki/Runlevel Runlevel] oder von einer Live-CD starten.
| |
|
| |
|
| |
|
| [[Kategorie:Entwurf]] | | [[Kategorie:Entwurf]] |
| [[Kategorie:SSH]] | | [[Kategorie:SSH]] |