ubuntuusers.de

Du betrachtest eine alte Revision dieser Wikiseite.

SSH

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

Wiki/Icons/security.png Es war einmal eine Zeit, als Computer über das Netz mit Hilfe eines Protokolls namens Telnet zugänglich waren. Mit dem Befehl telnet konnte man sich über das Netzwerk bei anderen Systemen anmelden, die den Telnet-Daemon installiert hatten. Vorausgesetzt, man wusste das Passwort. Leider bot das Protokoll keine Verschlüsselung, so dass das Mitschneiden von Passwörtern zur trivialen Angelegenheit wurde.

Um diesem Treiben einen Riegel vorzuschieben, fertigte der Finne Tatu Ylönen in den frühen Neunzigern des vorigen Jahrhunderts eine Programmsuite an – bestehend aus einem Server, einem Client und mehreren Hilfsprogrammen – die er ssh (secure shell) nannte. Das SSH-Protokoll, das er veröffentlichte, bot eine komplett verschlüsselte Alternative zu Telnet und noch vieles mehr und wurde ein voller Erfolg.

Als er später die Firma ssh.com gründete und die Version 2 der SSH-Suite nur noch unter einer kommerziellen Lizenz anbot, nahmen sich die Entwickler des Betriebssystems OpenBSD des Quellcodes von ssh1 an und entwickelten das Programm bis zum heutigen Tage unter dem Namen OpenSSH weiter. Die OpenSSH-Suite wurde quasi fester Bestandteil aller Linux-Distributionen und auch von Ubuntu.

Auch wenn es inzwischen Erweiterungen für Telnet gibt, die bspw. SSL-Verschlüsselung oder Kerberos-Authentifizierung bieten, wurde der Telnet-Server fast komplett von SSH verdrängt und ist nicht mehr verbreitet.

Mehr Details zur verwendeten Verschlüsselung finden sich weiter unten.

⚓︎

Der SSH-Client

Als sicherer Telnet-Ersatz bietet ssh drei wichtige Eigenschaften:

  • Authentifizierung der Gegenstelle

  • Verschlüsselung der Datenübertragung einschließlich der Anmelde-Informationen

  • Datenintegrität, also Schutz vor Manipulation der Übertragung

Das funktioniert normalerweise in einen Terminal-Fenster [2] so:

user@client:~$ ssh user@sol-1
user@sol-1's password:
Last login: Sun Feb 12 07:38:50 2006 from client.local
Sun Microsystems Inc.   SunOS 5.9       Generic_112234-03       November 2002
bash-2.05$ 

Und schon befindet man sich auf einem anderen System, in diesem Fall mit dem Betriebssystem Solaris.

user@client:~$ ssh server
Password:
Linux vdr 2.4.27-ctvdr-1 #1 Fri Oct 15 18:38:29 UTC 2004 i686 GNU/Linux
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sun Feb 12 07:38:23 2006 from client.local
user@server:~$ id
uid=500(user) gid=500(user) Gruppen=500(user)
user@server:~$ 

Oder auf einem anderen Linux-System. Wie man sieht, ist die Angabe des Benutzernamens optional, wenn er auf beiden Systemen gleich ist. Man kann auch einfach einen Befehl anhängen, der anstelle der Terminal-Session ausgeführt wird. Nach der Ausführung des Befehls wird die SSH-Session dann automatisch beendet:

user@client:~$ ssh server cat /etc/issue
Password:
Debian GNU/Linux 3.1 \n \l
user@client:~$ 

Oder etwas komplizierter - eine Datensicherung machen ("backup"):

user@client:~$ ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz
Password:
network/
network/interfaces
network/if-post-down.d/
network/if-pre-up.d/
network/if-up.d/
network/if-down.d/
network/options
network/interfaces.pre-etherconf
network/interfaces.1
network/run
user@client:~$ ll etc_network_backup.tar.gz
-rw-r--r--  1 user user 10240 2006-03-07 02:17 etc_network_backup.tar.gz
user@client:~$ 

Bei einer langsamen Verbindung empfiehlt sich zusätzlich die Benutzung der Option -C (großes C), die zusätzlich zur Verschlüsselung eine transparente Kompression der übertragenen Daten aktiviert. Bei einer schnellen Verbindung wird die Kompression aber vermutlich bremsen.

Woher weiß man nun aber, dass man tatsächlich mit dem richtigen Rechner verbunden ist, und nicht ein Angreifer die Verbindung umgeleitet hat? Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert. Greift man zum ersten Mal auf einen bestimmten Server zu, kennt man diesen Schlüssel natürlich noch nicht. (Außer man hat ihn sich auf anderen Wegen im Voraus besorgt.)

user@client:~$ ssh server
The authenticity of host 'server (192.168.1.5)' can't be established.
RSA key fingerprint is b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server' (RSA) to the list of known hosts.
Password: 

Wenn gerade in diesem Moment jemand die Verbindung gekapert hat, hat man natürlich Pech, außer man kann den Administrator des Servers nach dem richtigen Fingerprint des Host-Schlüssels fragen.

⚓︎

Hinweis:

Den RSA-Fingerprint eines Servers kann man mit dem Systemprogramm ssh-keygen erfahren: der Befehl ssh-keygen -f /etc/ssh/ssh_host_rsa_key.pub -l gibt den Fingerprint und einige weitere Informationen aus, z.B. 1024 b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1 /etc/ssh/ssh_host_rsa_key.pub. Wenn man auf Nummer sicher gehen möchte, lässt man sich vom Administrator des Servers diese Ausgabe mitgeben (evtl. ausdrucken) und kann dann beim ersten Verbindungsversuch überprüfen, ob man sich tatsächlich zum richtigen SSH-Server verbunden hat und nicht zu einem dazwischengeschalteten Angreifer.

Bei allen weiteren Kontakten stellt das ssh-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen privaten Schlüssel verfügt, der zum öffentlichen, in der Datei ~/.ssh/known_hosts abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.

Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erstmal auf dem Client mit dem Befehl

ssh-keygen -R hostname 

aus der known_hosts-Datei entfernen.

Sollte die Verbindung nicht mehr reagieren, z.B. wenn der SSH-Server heruntergefahren wurde, lässt sich der ssh-Client mit der Eingabe von "~." (Nacheinander) beenden.

Hinweis:

Wer (noch) einen Windows-Desktop benutzt und über das SSH-Protokoll auf seine Linux-Maschinen zugreifen will, der findet hier 🇬🇧 das Programm PuTTY.

Benutzeroberfläche für die Verbindungsverwaltung

Wem es zu mühsam ist, in der Konsole die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um seine Verbindungsdaten zu verwalten.

  • gnome-rdp (universe, [2]) - Mit dem Programm kann man nicht nur RDP und VNC Verbindungen aufbauen, sondern auch normale SSH Terminal Sitzungen. Leider kann man in der aktuellen Version die Zugangspasswörter nicht speichern lassen und keine Angaben zum verwendeten Port machen, es funktioniert somit nur mit Servern die den Standard-SSH-Port nutzen.

  • kssh (universe, [2]) - Das Programm erlaubt, Server, Benutzernamen und Optionen zu speichern, und öffnet dann eine Konsole mit dem entsprechenden Login.

  • putty (universe, [2]) - Das eher unter Windows bekannte Programm gibt es sehr wohl auch unter Linux. (mehr)

.ssh/config

Wenn man sich auf der Konsole mit einem anderen Server verbinden möchte, muss man evtl. z.B. Port und Benutzernamen angeben. Um das Ganze zu vereinfachen, kann man Voreinstellungen für ssh in der config-Datei $HOME/.ssh/config hinterlegen. Hier ein Beispiel:

# ssh (secure shell) configuration file
Host test1
    HostName 123.456.789.0
    Port 980
    User MeinBenutzerName

Host test2
    HostName test.mynet.local
    User test
    CheckHostIP no
    Cipher blowfish

Host foobar
    HostName domain.tld
    Port 55550
    User fanta
    IdentityFile ~/.ssh/private_ssh_key_rsa

Nun braucht man nicht mehr

ssh MeinBenutzerName@123.456.789.0 -p980 

zu schreiben, es reicht nun ein kurzes

ssh test1 

für einen Verbindungsaufbau. Alle Parameter, die man verwenden kann, findet man unter openbsd.org 🇬🇧 oder in der Manpages von ssh_config.

⚓︎

Der SSH-Server

Im Gegensatz zum SSH-Klienten ist der SSH-Server unter Ubuntu standardmäßig nicht installiert. Er lässt sich über das Paket

  • openssh-server

Befehl zum Installieren der Pakete:

sudo apt-get install openssh-server 

Oder mit apturl installieren, Link: apt://openssh-server

installieren [1].

Die Konfiguration des SSH-Servers sshd findet über die Datei /etc/ssh/sshd_config statt. Die Voreinstellungen sind aber durchweg akzeptabel.

Wer den sshd auf einem Gateway oder Router betreibt oder aus einem anderen Grund mehrere Netzwerkschnittstellen verwendet (bspw. WLAN), der möchte dort vielleicht die ListenAddress-Direktive benutzen, um den Server nur an bestimmten Netzwerk-Schnittstellen laufen zu lassen.

Außerdem kann es sinnvoll sein, PermitRootLogin auf no zu setzen. Dann kann sich niemand direkt als root einloggen, sondern man meldet sich unter seinem Benutzernamen an und ruft dann su oder sudo -s auf. Das ist aber unter Ubuntu sowieso nur für die Leute interessant, die dem "root"-Benutzerkonto überhaupt ein Passwort zugewiesen haben.

Mit den Direktiven AllowUsers und AllowGroups bzw. DenyUsers und DenyGroups lässt sich noch genauer festlegen, welche Benutzer sich anmelden dürfen und welche nicht. Dies empfiehlt sich besonders bei Servern. AllowGroups admin verbietet bspw. allen Benutzern, die keine Mitglieder der Gruppe admin sind, den Zugriff.

Wer sich ausschließlich über das noch sicherere Public-Key-Verfahren anmelden will, der sollte die Benutzung von Passwörtern mit PasswordAuthentication no abschalten.

Falls lange Wartezeiten bei der Anmeldung am SSH-Server auftreten, könnte das an einer fehlgeschlagenen Namensauflösung liegen. Da man SSH normalerweise sowieso über die IP benutzt, können diese DNS-Anfragen in der sshd_config deaktiviert werden. Der dafür nötige Eintrag wäre UseDNS no.

Nach erfolgter Änderung der Datei sshd_config muss der Server mit dem Befehl:

sudo reload ssh 

neugestartet werden, damit die Änderungen wirksam werden.

⚓︎

Hinweis:

Standardmäßig wird der SSH-Server beim Booten geladen. Wird SSH allerdings nur manchmal benötigt, sollte es nicht immer laufen. Man kann es z.B. ganz einfach mit dem Programm BUM (hier erklärt Dienste (Abschnitt „BUM-Boot-Up-Manager“)) am automatischen Starten hindern.

Dateitransfer

Wenn man also ein Protokoll hat, das so sicher wie nach dem heutigen Stand der Technik möglich Daten durch einen verschlüsselten Kanal senden und empfangen kann, dann wäre es wohl Verschwendung, dieses Protokoll nur für interaktive Terminal-Sessions zu benutzen. Sehr häufig möchte man bspw. einfach nur Dateien sicher von einem System zum anderen bewegen. Dafür existieren verschiedene Programme der grafischen Benutzeroberfläche sowie gleich zwei Terminalbefehle nämlich scp und sftp.

Transfer von der Kommandozeile

⚓︎

scp

Das Kommandozeilenwerkzeug scp funktioniert in etwa so wie das normale Unix-Kommando cp, nur dass es über Systemgrenzen hinweg funktioniert. Jedes Datei- oder Verzeichnisargument kann dabei optional, getrennt durch einen Doppelpunkt, durch einen vorangestellten Benutzer- bzw. Hostnamen ergänzt werden. Dabei werden weggelassene Teile durch den aktuellen Benutzernamen, localhost bzw. das Homeverzeichnis (bzw. das aktuelle Verzeichnis) ergänzt, etwa so:

scp benutzerx@server1:datei1 datei2 benutzery@server2: 

In diesem Beispiel wurde die datei1 aus dem Homeverzeichnis von benutzerx auf server1 und die datei2 aus dem aktuellen Verzeichnis des lokalen Hosts in das Homeverzeichnis von benutzery auf server2 kopiert.

Der Befehl scp versteht auch einige von cp bekannte Optionen, bspw. -r für das rekursive Kopieren ganzer Verzeichnisbäume. Bedauerlicherweise unterstützt scp aber nicht alle cp-Optionen, die für das exakte Klonen von Verzeichnissen, inkl. aller Dateirechte und symbolischen Verknüpfungen notwendig sind. Für die exakte Replikation sollte deswegen entweder das Werkzeug rsync -e ssh genutzt werden (man beachte die Handbuchseite zu diesem Tool) oder der oben schon genutzte Trick mit tar und einer Pipe.

user@client:~$ ssh root@server 'cd verzeichnis; tar czvf - verz./dateien' | tar xzf - 

⚓︎

sftp

Die andere Möglichkeit des Dateitransfers lautet sftp. Das funktioniert genau so wie der normale Kommandozeilen-FTP-Client:

user@client:~$ sftp server
Connecting to server...
user@server's password:
sftp> pwd
Remote working directory: /export/home/user
sftp> dir
[...]
wichtige_datei.txt
[...]
sftp> get wichtige_datei.txt
Fetching /export/home/user/wichtige_datei.txt to wichtige_datei.txt
/export/home/user/wichtige_datei.txt                                                     100%   62KB  62.2KB/s   00:00
sftp> quit
user@client:~$ ls -la wichtige_datei.txt
-rw-r--r--  1 user user 63664 2006-03-10 17:26 wichtige_datei.txt
user@client:~$ 

Mit dem Befehl help bekommt man eine Übersicht über die möglichen Kommandos.

Entfernte Dateisysteme einbinden

Man kann das Dateisystem eines entfernten Rechners in sein eigenes Dateisystem mittels sshfs einbinden. Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich.

Grafische Programme zum Dateitransfer

Gnome/Ubuntu

Der Gnome-Dateimanager Nautilus unterstützt das SSH-Protokoll von Haus aus. Dazu benutzt man eine Adresse der Form ssh://rechnername/pfad, um über SSH die Dateien auf dem angegebenen Rechner zu sehen. Wenn man sich als ein anderer Benutzer anmelden möchte, verwendet man stattdessen eine Adresse der Form ssh://andererbenutzer@rechnername/pfad. Alternativ können auch die Hosts aus der ~/.ssh/config verwendet werden. Dort lassen sich auch noch andere SSH-Einstellung, wie. z.B SSH-Keys, definieren. Der Zugriff erfolgt mit ssh://hostname. Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen.

KDE/Kubuntu

Auch bei KDE ist SSH-Unterstützung eingebaut: Mit einer Adresse der Form fish://rechnername/pfad kann man auf die Dateien auf einem anderen Rechner zugreifen, und mit fish://andererbenutzer@rechnername/pfad meldet man sich als anderer Benutzer auf dem Zielrechner an. Dies funktioniert im Konqueror sowie in allen KDE-Anwendungen. Man kann also im Malprogramm kolourpaint auf DateiÖffnen.. gehen und dann im Dateidialog oben in der Adresszeile eine fish://-Adresse eingeben, um direkt ein Bild auf einem anderen Rechner anzusehen oder zu bearbeiten. Im Dateimanager Dolphin (Kubuntu-Standard) können über das Bookmark "Netzwerk" und den Assistenten "Netzwerkordner hinzufügen" neue ssh-basierte Netzwerkordner als feste Bookmarks erstellt werden. Wenn der Zielrechner ebenfalls ein UTF-8 codiertes Dateisystem hat, sind u.U. die Umlaute falsch angezeigt. Um dies zu ändern, muss man im Konqueror eine fish-Adresse aufrufen und kann nun unter "Extras → Entfernte Zeichencodierung wählen..." die entsprechende Codierung einstellen. Diese Einstellung ist fortan auch in Dolphin gültig. Diese Option einzustellen wird in KDE4 vermutlich in Dolphin selbst möglich sein.

Weitere grafische Programme

Die meisten grafischen FTP-Clients (FTP) unterstützen auch sftp oder scp über das SSH-Protokoll. Beim Gnome FTP-Cient gFTP etwa muss man unter "FTP → Optionen → Netz → Voreingestelltes Protokoll" in der Drop-Down-Liste SSH2 an Stelle von FTP auswählen. Leider hat gftp Probleme, wenn man neben Passwörtern auch Public-Keys (siehe Public-Key-Verfahren) benutzt. Das funktioniert nur mit dem SSH-Agenten (ebenfalls weiter unten beschrieben) und der Einstellung "Benötige SSH Benutzername/Passwort nicht" in "FTP → Optionen → SSH".

SSH-Verbindungen zu Datenverzeichnissen auf Fremdrechnern unterstützen auch Datensynchronisationsprogramme wie Unison und Backupprogramme wie Keep.

⚓︎

Authentifizierung über Public-Keys

Wem die Authentifizierung über Passwörter trotz der Verschlüsselung zu unsicher ist, - immerhin könnte das Passwort ja erraten werden - der benutzt am besten das Public-Key-Verfahren. Hierbei wird asymmetrische Verschlüsselung 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:

user@client:~$ ssh-keygen -t rsa
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 2048]----+
|                 |
|                 |
|                 |
|         +    .  |
|        S    E   |
|         .  + +  |
|          .o . o.|
|         o.oo. oo|
|          ==o.BO+|
+-----------------+
user@client:~$ 

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):

user@client:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@server
31
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.
user@client:~$ 

Sollte der Port nicht gerade 22 sein, dann muss der Befehl wie folgt aussehen:

ssh-copy-id -i ~/.ssh/id_rsa.pub '-p 12345 user@server' 

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.

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 ~/.ssh/config: mittels IdentityFile-Parameter.

Anschließend kann man sich ohne Passwort anmelden:

user@client:~$ 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
user@server:~$ 

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 Accounts beim 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. Damit man sich nur noch mit dem Key anmelden kann, sollte man noch die Optionen

PasswordAuthentication no
UsePAM no 

in der Datei /etc/ssh/sshd_config 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.

Und nochmals der Hinweis: Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erstmal auf dem Client mit dem Befehl

ssh-keygen -R hostname 

aus der known_hosts-Datei entfernen.

⚓︎

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 z.B. die authorized_keys in ein nicht-verschlüsseltes Verzeichnis zu legen (z.B. /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

⚓︎

Der SSH-Agent

So weit, so gut. Praktisch wäre es allerdings, wenn man nicht jedesmal die "pass phrase" eingeben müsste. Dann würde die Verwendung von Public-Keys nicht nur zur Sicherheit beitragen, sondern auch zur Bequemlichkeit (selten genug, dass sich das beides unter einen Hut bringen lässt).

Hier kommt der SSH-Agent ins Spiel. Im SSH-Agenten kann man seine(n) privaten Schlüssel ablegen, so dass sich der Agent von nun an um die Authentifizierung kümmert. Man muss also nur einmal seine "pass phrase" angeben, und der Agent behält dann den Schlüssel bis zu seiner Beendigung (normalerweise beim Abmelden des Benutzers ("logout")) im Speicher. Der SSH-Agent wird bei einer Ubuntu-Desktop-Sitzung automatisch im Hintergrund gestartet. Zur Interaktion mit dem SSH-Agenten dient das Programm ssh-add, wobei die Option -l die augenblicklich gespeicherten Schlüssel auflistet:

user@client:~$ ssh-add -l
The agent has no identities.
user@client:~$ ssh-add
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
user@client:~$ 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)
user@client:~$ ssh server
Last login: Wed Mar  8 11:11:58 2006 from 192.168.4.56
user@server:~$ 

Wenn man nicht über Gnome (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

user@client:~$ 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:

1
2
3
4
5
if [ $SSH_AGENT_PID ]; then
    if [[ $(ssh-add -l) != *id_?sa* ]]; then
        ssh-add -t 2h  ## Haltbarkeit von 2 Std.
    fi
fi

Über mehrere Rechner sich einloggen

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 [5]. Für KDE-Nutzer gibt es ab Intrepid 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 GNOME-Schlüsselbund dann nicht mehr automatisch freigeschaltet wird.

Hinweis:

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.

Ubuntu 9.10

Zur Anmeldung mit einer Passphrase muss man die Dateien login (für Konsolenzugang) und gdm (wahlweise kdm oder xdm; für den grafischen Login) im Verzeichnis /etc/pam.d anpassen. Dort muss man die Zeile

@include common-auth

durch

auth sufficient pam_ssh.so
auth required pam_unix.so nullok_secure use_first_pass

ersetzen und außerdem direkt hinter die Zeile @include common-session ein session optional pam_ssh.so setzen. /etc/pam.d/gdm sieht dann in etwa so aus:

auth    requisite       pam_nologin.so
auth    required        pam_env.so
auth sufficient pam_ssh.so
auth required pam_unix.so nullok_secure use_first_pass
@include common-account
session required        pam_limits.so
@include common-session
session optional pam_ssh.so
@include common-password

Danach wird in der Konsole nach der SSH-Passphrase gefragt, hier kann jedoch auch problemlos das normale Passwort eingegeben werden. Alternative Einstellmöglichkeiten finden sich außerdem in der Datei /usr/share/doc/libpam-ssh/README.Debian.

Ubuntu 9.04 und früher

Zur Anmeldung mit einer Passphrase muss man die Dateien login (für Konsolenzugang) und gdm (wahlweise kdm oder xdm; für den grafischen Login) im Verzeichnis /etc/pam.d anpassen. Dort muss man jeweils direkt vor die Zeile @include common-auth ein @include pam-ssh-auth setzen, und direkt nach die Zeile @include common-session ein @include pam-ssh-session. /etc/pam.d/gdm sieht dann bspw. in etwa so aus:

#%PAM-1.0
auth    requisite       pam_nologin.so
auth    required        pam_env.so
@include pam-ssh-auth
@include common-auth
@include common-account
session required        pam_limits.so
@include common-session
@include pam-ssh-session
@include common-password

(/etc/pam.d/login ist etwas länger...)

⚓︎

X-Forwarding

./screenshot_ssh_X.png Mit dem X11-Forwarding kann man auch grafische Programme, die man über SSH auf einem anderen Rechner startet, auf dem eigenen Display anzeigen lassen, und zwar unabhängig davon, welches Betriebssystem auf dem entfernten Rechner läuft (siehe Bild.) Das Programm muss sich nur an den X11-Standard halten, was leider die meisten Windows- und Mac-Programme ausschließt.

Um das X11-Forwarding zu aktivieren, muss man dem ssh-Befehl die Option -X (großes X) hinzufügen, die dem Programm eingeschränkte Rechte am eigenen Display einräumt. Für den Fall, dass es zu einem Programmabbruch kommt, weil diese eingeschränkten Rechte nicht ausreichen, existiert noch die Option -Y, die dem Programm volle Rechte gewährt. Diese sollte man jedoch nicht verwenden, wenn man dem Administrator des entfernten Rechners nicht vertraut, denn sie öffnet einen Tunnel, der auch in der umgekehrten Richtung für einen Angriff auf das eigene Display genutzt werden könnte. Vorsicht: mit der Option -x (kleines x) wird X11-Forwarding deaktiviert.

Serverkonfiguration

Hinweis:

Dies sollte in der Regel nicht notwendig sein.

Auf dem Server muss hierfür das Paket

  • xauth

installiert werden, wenn es das noch nicht ist.

Außerdem muss dem SSH-Daemon des Servers mitgeteilt werden, dass X-Forwarding verwendet wird. Das wird über die Konfigurationsdatei

 /etc/ssh/sshd_config

erledigt. Dort wird die Option

X11Forwarding yes

gesetzt. Danach ist ein Neustart des Daemons erforderlich.

Zusätzlich müssen in der Client-Konfigurationsdatei /etc/ssh/ssh_config die Einträge

ForwardX11 yes

und

ForwardX11Trusted yes

einkommentiert werden.

⚓︎

SSH-Tunnel

Wenn man mit Hilfe von SSH so ein nicht ganz triviales Protokoll wie X-Window tunneln kann, dann muss das doch auch mit anderen Protokollen funktionieren, oder? - Aber sicher geht das. Allerdings ist die Syntax für den SSH-Tunnelbau ein wenig verwirrend:

ssh -L [bind_address:]port:host:port user@server
ssh -R [bind_address:]port:host:port user@server 

Hierbei richtet die Option -L laut Dokumentation eine lokale, und die Option '-R' eine entfernte (englisch remote) Port-Weiterleitung ein. Der verschlüsselte Tunnel wird dabei immer zwischen dem eigenen Rechner und server hergestellt. Die Verbindung vom Ende des Tunnels zu host läuft dagegen unverschlüsselt ab, und wird aus Sicht des betreffenden Systems angegeben, weswegen man host in den allermeisten Fällen wohl auf "localhost" setzen sollte. Hierbei darf "localhost" nicht mit dem lokalen Rechner verwechselt werden. Es handelt sich um "localhost" von server aus betrachtet, daher um den Server selbst.

Die Option -L bzw. -R gibt dabei die Richtung an, aus der der Tunnel benutzt werden kann. Bei -L vom eigenen Rechner zum entfernten hin, bei -R in der entgegengesetzten Richtung. (Das merkt man sich am Besten als normaL und Rückwärts.)

Das erste port-Argument bezeichnet dabei den Einstiegsport in die Verbindung. Zu beachten ist hierbei, dass die Öffnung eines privilegierten Ports, also unter 1024, nur dem Superuser root gestattet ist. Man sollte also auf die höheren Ports ausweichen.

Mit dem optionalen Parameter bind_address kann man festlegen, auf welchen Netzwerkschnittstellen die Weiterleitung laufen soll, wobei localhost der Standard ist. Ein * oder ein leeres bind_address-Argument vor dem Doppelpunkt bedeutet, dass die Weiterleitung an allen Schnittstellen läuft. Möglicherweise funktioniert das nicht auf jedem Ubuntu-System auf Anhieb, da die IPv6-Adresse das irgendwie verhindert, weshalb man den SSH-Tunnel mit dem Argument -4 auf die IPv4-Schnittstellen beschränken muss.

Der zweite port-Parameter gibt schließlich an, auf welchen Port von host die Weiterleitung gehen soll.

Ein weiteres nützliches Argument ist die Option -N, die das Erzeugen einer Terminal-Sitzung auf dem entfernten System unterbindet, wenn man nur die Port-Weiterleitung benutzen möchte.

Beispiele

Weiterleitung von Port 8000 auf dem lokalen System an den Webserver (Port 80) auf server:

user@client:~$ ssh -L 8000:localhost:80 server -N &
[1] 10843
user@client:~$ netstat -anp --inet | egrep '(^Proto|8000)'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:8000          0.0.0.0:*               LISTEN     10843/ssh
user@client:~$ fg
ssh -L 8000:localhost:80 server -N
[Strg-C]
Killed by signal 2. 

Dasselbe, aber es wird nicht nur vom lokalen Host weitergeleitet, sondern von allen Schnittstellen (hierzu ist die Option GatewayPorts in der Server-Konfiguration entsprechend zu setzen, genaueres zu finden in der Manpage; man wähle diese Option mit Bedacht!):

user@client:~$ ssh -L *:8000:localhost:80 server -N -4 &
[1] 10906
user@client:~$ netstat -anp --inet | egrep '(^Proto|8000)'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN     10906/ssh 

Umgekehrte Richtung. Benutzern auf server wird ermöglicht, über localhost:3306 auf den MySQL-Server auf client zuzugreifen:

user@client:~$ ssh -R 3306:localhost:3306 server
Last login: Sat Mar 11 23:24:20 2006 from 192.168.4.56
user@server:~$ netstat -an --inet | egrep '(^Proto|3306)'
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN
user@server:~$ exit
logout
Connection to server closed. 

Zur Veranschaulichung folgt hier noch einmal eine grafische Darstellung dieser Beispiele:

./ssh-tunnel-improved.png

Doppelter SSH-Tunnel über zwei Konsolen:

./doppelter_ssh_tunnel.png

supportpc$ ssh -L 54321:localhost:54321 zwischennutzer@zwischen
zwischen$ ssh -L 54321:localhost:8080 zielnutzer@ziel 

SSH-Tunnel über Zwischenrechner mit Zielrechner verbinden:

./ssh_tunnel_zu_ziel.png

supportpc$ ssh -L 54322:ziel:22 zwischennutzer@zwischen 

Weitere Verschlüsselungsdetails

als Fortsetzung der Einleitung.

  • Symmetrische Verschlüsselung:

Wer als Laie an Verschlüsselung denkt, der denkt meist an die "symmetrische Verschlüsselung". Hierbei gibt es genau einen Schlüssel, mit dem ein Datensatz verschlüsselt wird. Nur wer diesen Schlüssel kennt (oder durch Probieren herausfindet) kann die Verschlüsselung umkehren und den Klartext wieder extrahieren. Bekannte und bewährte Algorithmen wie TripleDES, AES und Blowfish machen das Erraten des Schlüssels natürlich nicht gerade leicht, genauer gesagt, nach dem heutigen Stand der Technik nahezu unmöglich. Das einzige Problem bei der Benutzung von symmetrischer Verschlüsselung ist, den Schlüssel sicher zum Kommunikationspartner zu befördern.

  • Asymmetrische Verschlüsselung:

Um dieses Problem der symmetrischen Verschlüsselung zu umgehen, gelang es Forschern schon vor einiger Zeit, das gemeinsame Geheimnis, das für eine erfolgreiche Ver- und Entschlüsselung nötig ist, so hinter komplizierten Algorithmen zu verbergen, dass man es unter bestimmten Bedingungen öffentlich verteilen konnte. Bei diesem Verfahren, asymmetrische Verschlüsselung genannt, wird nicht ein Schlüssel erzeugt, sondern ein Schlüsselpaar, das mathematisch voneinander abhängt, aber nicht ohne sehr viel Aufwand voneinander abgeleitet werden kann. Jeweils zwei zueinander passende Schlüssel wirken auf geradezu magische Weise genau entgegengesetzt: Was mit dem einen Schlüssel verschlüsselt wird, kann nur durch den anderen Schlüssel wieder entschlüsselt werden. Dies ermöglicht es, einen der beiden Schlüssel öffentlich zur Verfügung zu stellen, um Sendungen zu verschlüsseln, die man aber einzig und allein mit dem anderen Schlüssel, den man niemals weitergibt, entschlüsseln kann.

Im Gegenzug kann man ein Datenpaket auch mit dem eigenen privaten Schlüssel chiffrieren. Wenn dieser Chiffretext sich dann mit dem öffentlichen Schlüssel wieder in Klartext zurückverwandeln lässt, weiß jeder, dass die Nachricht nur vom Besitzer des privaten Schlüssels kommen kann. Diese Anwendungsmöglichkeit nennt man digitale Signatur. Da der Umgang mit asymmetrischen Verschlüsselungsalgorithmen wie RSA oder DSA signifikant mehr Rechenleistung erfordert als mit symmetrischen, ist es gängige Praxis, am Beginn der Kommunikation mit Hilfe des öffentlichen Schlüssels einen neu generierten, symmetrischen Session-Schlüssel auszutauschen und für den Rest der Kommunikation auf symmetrische Verschlüsselung umzusteigen.

Diese Revision wurde am 12. November 2012 16:34 von vrumfondel erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Sicherheit, Netzwerk, Server, Shell, System, Internet, ssh, Fernwartung