Die letzten Meldungen

SYSTEMAUSBILDUNG im SoSe 2017 „Grundlagen und Aspekte von Betriebssystemen und systemnahen Diensten”

21. April 2017

Mit Beginn des Sommersemesters 2017 setzt das RRZE auch seine Veranstaltungsreihe „SYSTEMAUSBILDUNG – Grundlagen und Aspekte von Betriebssystemen und systemnahen Diensten“ fort und lädt Sie herzlich zu seinen Vorträgen ein.
Weiterlesen...

Wartungsankündigung für „campo“ am 27.04.2017

19. April 2017

Aufgrund von Wartungsarbeiten wird das campo-Portal am Donnerstag, 27. April 2017 zwischen 15:00 Uhr und 19:00 Uhr nicht zur Verfügung stehen.
Weiterlesen...

Wartung der FAUbox

18. April 2017

Am Mittwoch, 19.04.2017 wird die FAUbox ein Versionsupgrade erhalten. Wir nutzen das Wartungsfenster des Loadbalancers. Start der Arbeiten wird 15:00 Uhr sein. Ende der Arbeiten an der FAUbox wird voraussichtlich um 15:30 sein.
Weiterlesen...

Meldungen nach Thema

 

SSH konfigurieren

Allgemeines

Gleich zu Anfang ein paar kurze Worte zu den verwendeten Begriffen in diesem Artikel:

Prinzipiell gilt die Unterscheidung zwischen der Externer Link:  kommerziellen SSH (ssh.com) und der OpenSource-AlternativeExterner Link:  OpenSSH.
Welche der beiden Versionen Sie im Einsatz haben können Sie leicht feststellen. Der Aufruf:

linux~ > ssh -V
	

liefert je nach SSH-version folgende Ausgaben:

  • OpenSSH:
     OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
  • Ssh.com:
     ssh: SSH Secure Shell 3.2.0 (non-commercial version) on sparc-sun-solaris2.6

SSH mit Komfort

Manche Systemarbeiten erfordern häfiges Einloggen auf anderen Rechnern. Im Normalfall muss bei jedem Anmeldevorgang das Passwort erneut eingegeben werden, was auf Dauer sehr lästig werden kann. Die Secure Shell bietet (neben dem passwort-basierten Einlog-Vorgang) auch die Möglichkeit sich mit Hilfe abgelegter Schlüssel zu authentifizieren.

Obwohl beide nach dem gleichen Prinzip arbeiten, kann man dabei zwei Mechanismen unterscheiden:

Rechnerbasiert

Bei der rechnerbasierten Authentifizierung mit Schlüsseln wird einem Benutzer, der sich an einem Rechner erfolgreich angemeldet hat, erlaubt dies auch auf anderen Rechner zu tun - und zwar ohne Passwort. Die beteiligten Rechner müssen natürlich zuvor die notwendigen Schlüssel erhalten haben. Diese Art der Konfiguration kann jedoch nur der Systemverwalter root vornehmen.

Benutzerbasiert

Wie bereits der Name vermuten läßt, verhält sich das bei der benutzerbasierten Version anders: Sofern der Systemverwalter diese Möglichkeit nicht ausgeschlossen hat, kann jeder Benutzer selbst die notwendigen Dateien erzeugen, um eine passwort-lose Anmeldung zu bewerkstelligen.

Konfiguration des SSHD-Dienstes für Hostbased Authentication

Serverseitig

Um die rechnerbasierte Authentifizierung Authentifizierung zu erlauben, muss in der Konfigurationsdatei des SSH-Dienstes (/etc/sshd/sshd_config) die Option HostbasedAuthentication aktiviert werden:

<...>
HostbasedAuthentication yes
<...>
	

Zusätzlich müssen alle Rechner, die die Erlaubnis erhalten sollen, sich auf dem Server (ohne Passwort) anzumelden in die Datei /etc/ssh/shosts.equiv eingetragen werden:

client1.rrze.uni-erlangen.de
client2.rrze.uni-erlangen.de
<...>
	

Ebenso müssen die Clients den öffentlichen Teil ihres Schlüssels auf dem Server hinterlegen. Dabei gibt es zwei Typen von Keys, die in den Dateien /etc/ssh/ssh_known_hosts (SSH1 RSA keys) bzw. /etc/ssh/ssh_known_hosts2 (SSH2 RSA+DSA keys) abgelegt werden.

Um die öffentlichen Schlüssel zu erhalten kann man sie entweder von Hand kopieren und modifizieren, oder aber man verwendet einfach das Programm ssh-keyscan:

linux~ # ssh-keyscan -t rsa client1.rrze.uni-erlangen.de >> /etc/ssh/ssh_known_hosts2
linux~ # ssh-keyscan -t dsa client1.rrze.uni-erlangen.de >> /etc/ssh/ssh_known_hosts2
	

Jede Zeile der Datei /etc/ssh/ssh_known_hosts2 besteht dabei aus drei Spalten: Die erste besteht aus einer (durch Kommata getrennten) Liste von Namen und IP-Adressen, die einen Rechner bezeichnen. Meist besteht diese Liste aus dem FQDN (z.B. client1.rrze.uni-erlangen.de), dem eigentlichen Hostname (z.B. client1) und der IP-Adresse (z.B. 192.168.0.10). Das zweite Feld beschreibt den Typ des Schlüssels, also entweder ssh-rsa oder ssh-dss. Als letztes folgt der eigentliche Key.

Clientseitig

Auch auf dem Client muss die hostbasierte Authentifizierung aktiviert werden. Analog zum Server muss dazu in der Konfigurations-Datei des Clients (/etc/ssh/ssh_config) der Eintrag HostbasedAuthentication auf yes gesetzt werden.

Zusätzlich muss die Verwendung des Hilfstools ssh-keysign erlaubt werden:

...
HostbasedAuthentication yes
EnableSSHKeysign yes
...
	

Nur mit dessen Hilfe kann der SSH-Client (der ja meist mit einer normalen Benutzerkennung benutzt wird, nicht als User root) den privaten Schlüssel des Rechners lesen. Mit Hilfe eines Sticky-Bits erhät das Programm /usr/lib/ssh/ssh-keysign die notwendigen Zugriffsrechte:

client~ # ls -l /usr/lib/ssh/ssh-keysign
-rwxr-xr-x  1 root root 129500 2005-02-11 18:53 /usr/lib/ssh/ssh-keysign
client~ # chmod u+s /usr/lib/ssh/ssh-keysign
client~ # ls -l /usr/lib/ssh/ssh-keysign
-rwsr-xr-x  1 root root 129500 2005-02-11 18:53 /usr/lib/ssh/ssh-keysign
	

Erzeugen von Benutzerschlüsseln

Um eine SSH-Verbindung ohne lästige Passwort-Abfrage durchführen zu können, muss der Benutzer als erstes ein Schlüsselpaar erzeugen:

OpenSSH

linux~ > ssh-keygen -t dsa -b 2048 -f ~/.ssh/id_dsa
	

Ssh.com

linux~ > ssh-keygen -t dsa -b 2048 ~/.ssh2/id_dsa
linux~ > echo "idkey id_dsa" > ~/.ssh2/identification
	

Achtung! Damit die Kommunikation in beide Richtungen funktioniert, müssen 2 verschiedene Schlüsselpaare angelegt werden (also eines für OpenSSH und eines für Ssh.com).

Nach einiger Zeit werden Sie nach einem Passwort gefragt, mit dem der erzeugte private Key verschlüsselt werden sollen. Wenn Sie hier nichts eingeben wird dieser im Klartext abgelegt, was ein Sicherheitsrisiko darstellt. Doch dazu später mehr.

Obiges Kommando erzeugt zwei Dateien: Den privaten Schlüssel id_dsa und den dazu gehörigen öffentlichen Teil id_dsa.pub.

Für die OpenSSH sollten beide Dateien im Verzeichnis $HOME/.ssh liegen, bei ssh.com hingegen unter $HOME/.ssh2.

Konvertierung der verschiedenen Schlüssel-Formate

Unglücklicherweise benutzen OpenSSH und Ssh.com unterschiedliche Verzeichnisstrukturen und Dateiformate. Neue Versionen der OpenSSH beherrschen aber die Konvertierung der (public key) Dateien in beide Richtungen. Die folgenden Beispiele funktionieren dementsprechend nur mit der OpenSSH-Version des Programms key-gen.

OpenSSH -> SSH

linux~ > ssh-keygen -e -f ~/.ssh/id_dsa.pub > ~/.ssh2/id_dsa_openssh.pub
	

SSH -> OpenSSH

linux~ > ssh-keygen -i -f ~/.ssh2/id_dsa.pub > ~/.ssh/id_dsa_sshcom.pub
	

Schlüssel für authorisierte Benutzer

OpenSSH -> OpenSSH

linux~ > cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
	

Ssh.com -> OpenSSH

linux~ > cat ~/.ssh/id_dsa_sshcom.pub >> ~/.ssh/authorized_keys
	

OpenSSH -> Ssh.com


linux~ > echo "Key id_dsa_openssh.pub" >> ~/.ssh2/authorization
	

Ssh.com -> Ssh.com

linux~ > echo "Key id_dsa.pub" >> ~/.ssh2/authorization
	

ssh-agent/ssh-add

Wer seine Schlüssel möglichst sicher aufbewahren will, der verzichtet beim Erstellen nicht auf die Eingabe eines Passwortes. Dadurch wird der private Schlüssel nicht im Klartext auf der Festplatte abgelegt.

Um jedoch trotzdem damit arbeiten zu können muss man jetzt jedesmal statt des Benutzer-Passworts das Passwort eingeben, das den Schlüssel schützt. Damit scheint der Vorteil dieser Methode sehr fraglich - erst die Programme ssh-agent und ssh-add sorgen für Sicherheit in Verbindung mit dem nötigen Komfort.

ssh-agent

Der ssh-agent übernimmt die Verwaltung der Keys, sobald sie im Klartext vorliegen (zur Decodierung wird ssh-add eingesetzt, siehe unten).

linux~ > ssh-agent
setenv SSH_AUTH_SOCK /tmp/ssh-XXIpRd80/agent.27932;
setenv SSH_AGENT_PID 27933;
echo Agent pid 27933;
	

Beim Start gibt der ssh-agent diejenigen Informationen aus, die andere SSH Tools für den Zugriff auf die von ihm verwalteten Schlüssel benötigen. Die Ausgabe besteht aus einfachen Kommandos, die man auf der Shell ausführen kann. Letztendlich sorgen diese Anweisungen nur dafür, dass zwei Umgebungsvariablen (SSH_AUTH_SOCK und SSH_AGENT_PID) gesetzt werden. Die einfachste Variante den ssh-agent zu benutzen, besteht darin ihn mit Hilfe des Kommandos eval aufzurufen. Mit dessen Hilfe wird der Agent gestartet und gleichzeitig die Variablen gesetzt:

linux~ > eval `ssh-agent`
Agent pid 27933
	

Bei der Verwendung von ssh-agent spielen die Variablen eine zentrale Rolle. Variablen gelten nur in der aktuellen Shell und in all ihren Kindprozessen, d.h. wenn man ssh-agent in einer Shell aufruft, so werden die Variablen nur in dieser Shell oder an alle darin gestarteten Programmen vererbt. Folglich können auch nur diese Programme auf den Agenten zugreifen. Deswegen macht es Sinn ssh-agent möglichst bald während des Anmeldeprozesses zu starten - z.B. in der Datei .xsession (bei grafischem Login).

ssh-add

Mit Hilfe von ssh-add werden die auf der Platte verschlüsselten Keys nach der Eingabe des Passworts in ihrer Klartext-Form vom ssh-agent gespeichert. Ab diesem Zeitpunkt liegen sie unverschlüsselt im Speicher, der Zustand der Dateien auf Platte bleibt davon aber unberührt.

Nachdem der Zugriff einmal freigeschalten wurde bleibt dem Benutzer die lästige Passwort-Eingabe erspart. Beim Ausloggen wird ssh-agent beendet und zurück bleiben nur die verschlüsselten Keys auf Platte.

Tests

Manchmal ist es nötig die Authentifizierung mittels Schlüsseln zu deaktivieren. Das kann man mit Hilfe von Kommandozeilen Optionen erreichen:

linux~ > ssh targethost -o PreferredAuthentications=password
	

Letzte Änderung: 13. Maerz 2012, Historie

zum Seitenanfang

Startseite | Kontakt | Impressum

RRZE - Regionales RechenZentrum Erlangen, Martensstraße 1, D-91058 Erlangen | Tel.: +49 9131 8527031 | Fax: +49 9131 302941

Zielgruppennavigation

  1. Studierende
  2. Beschäftigte
  3. Einrichtungen
  4. IT-Beauftragte
  5. Presse & Öffentlichkeit