Secure Shell - ssh
Bei Internetdiensten wie eMail oder Web haben sich verschlüsselte Datenübertragungen mit SSL/TLS ohne Eingriffe in das Originalprotokoll durchgesetzt. Bei den klassischen unverschlüsselten Unix-Diensten zum Arbeiten mit entfernten Rechnern oder zur Datenübertragung auf andere Rechner - z.B. telnet, rcp und rsh - erfolgt eine alternative Lösiung mittels OpenSSH.
openSSH - Programmsuite
Die für die Secure-Shell benötigten Pakete werden i.d.R. bereits bei der Erstinstallation erfolgreich ins System eingebettet. Bei Centos teilen sich die Programme der Programmsuite auf folgende Pakete auf:
- openssh.i386 : Die OpenSSH-Implementierung der SSH Protokoll-Versionen 1 und 2
- openssh-clients.i386 : Die OpenSSH-Client-Anwendungen
- openssh-server.i386 : Der OpenSSH-Server Daemon
- openssh-askpass.i386 : Passphrase-Dialog für OpenSSH und X
openssh
Mittels rpm -iql können wir überprüfen, welche Programme, Konfigurationsdateien und Dokumentationen installiert wurden.
# rpm -iql openssh Name : openssh Relocations: (not relocatable) Version : 4.3p2 Vendor: CentOS ... ... Signature : DSA/SHA1, Mo 09 Mär 2009 02:48:50 CET, Key ID a8a447dce8562897 Packager : Karanbir Singh <kbsingh@karan.org> URL : http://www.openssh.com/portable.html Summary : Die OpenSSH-Implementierung der SSH Protokoll-Versionen 1 und 2 Description : SSH (Secure SHell) is a program for logging into and executing commands on a remote machine. SSH is intended to replace rlogin and rsh, and to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. OpenSSH is OpenBSD's version of the last free version of SSH, bringing it up to date in terms of security and features, as well as removing all patented algorithms to separate libraries. This package includes the core files necessary for both the OpenSSH client and server. To make this package useful, you should also install openssh-clients, openssh-server, or both. /etc/ssh /etc/ssh/moduli /usr/bin/ssh-keygen /usr/libexec/openssh /usr/libexec/openssh/ssh-keysign /usr/share/doc/openssh-4.3p2 /usr/share/doc/openssh-4.3p2/CREDITS /usr/share/doc/openssh-4.3p2/ChangeLog /usr/share/doc/openssh-4.3p2/INSTALL /usr/share/doc/openssh-4.3p2/LICENCE /usr/share/doc/openssh-4.3p2/OVERVIEW /usr/share/doc/openssh-4.3p2/README /usr/share/doc/openssh-4.3p2/README.dns /usr/share/doc/openssh-4.3p2/README.nss /usr/share/doc/openssh-4.3p2/README.platform /usr/share/doc/openssh-4.3p2/README.privsep /usr/share/doc/openssh-4.3p2/README.smartcard /usr/share/doc/openssh-4.3p2/README.tun /usr/share/doc/openssh-4.3p2/RFC.nroff /usr/share/doc/openssh-4.3p2/TODO /usr/share/doc/openssh-4.3p2/WARNING.RNG /usr/share/man/man1/ssh-keygen.1.gz /usr/share/man/man8/ssh-keysign.8.gz
openssh-clients
Beim Paket openssh-clients wird mitgeliefert:
# rpm -iql openssh-clients Name : openssh-clients Relocations: (not relocatable) Version : 4.3p2 Vendor: CentOS ... ... Signature : DSA/SHA1, Mo 09 Mär 2009 02:48:50 CET, Key ID a8a447dce8562897 Packager : Karanbir Singh <kbsingh@karan.org> URL : http://www.openssh.com/portable.html Summary : Die OpenSSH-Client-Anwendungen Description : OpenSSH is a free version of SSH (Secure SHell), a program for logging into and executing commands on a remote machine. This package includes the clients necessary to make encrypted connections to SSH servers. You'll also need to install the openssh package on OpenSSH clients. /etc/ssh/ssh_config /usr/bin/scp /usr/bin/sftp /usr/bin/slogin /usr/bin/ssh /usr/bin/ssh-add /usr/bin/ssh-agent /usr/bin/ssh-copy-id /usr/bin/ssh-keyscan /usr/share/man/man1/scp.1.gz /usr/share/man/man1/sftp.1.gz /usr/share/man/man1/slogin.1.gz /usr/share/man/man1/ssh-add.1.gz /usr/share/man/man1/ssh-agent.1.gz /usr/share/man/man1/ssh-copy-id.1.gz /usr/share/man/man1/ssh-keyscan.1.gz /usr/share/man/man1/ssh.1.gz /usr/share/man/man5/ssh_config.5.gz
openssh-server
Hingegen liefert uns openssh-server folgende Dateien:
# rpm -iql openssh-server Name : openssh-server Relocations: (not relocatable) Version : 4.3p2 Vendor: CentOS ... ... Signature : DSA/SHA1, Mo 09 Mär 2009 02:48:50 CET, Key ID a8a447dce8562897 Packager : Karanbir Singh <kbsingh@karan.org> URL : http://www.openssh.com/portable.html Summary : Der OpenSSH-Server Daemon Description : OpenSSH is a free version of SSH (Secure SHell), a program for logging into and executing commands on a remote machine. This package contains the secure shell daemon (sshd). The sshd daemon allows SSH clients to securely connect to your SSH server. You also need to have the openssh package installed. /etc/pam.d/sshd /etc/rc.d/init.d/sshd /etc/ssh /etc/ssh/sshd_config /usr/libexec/openssh/sftp-server /usr/sbin/sshd /usr/share/man/man5/sshd_config.5.gz /usr/share/man/man8/sftp-server.8.gz /usr/share/man/man8/sshd.8.gz /var/empty/sshd /var/empty/sshd/etc /var/empty/sshd/etc/localtime
openssh-askpass
Zu guter Letzt sehen wir uns noch das Paket openssh-askpass genauer an:
# rpm -iql openssh-askpass Name : openssh-askpass Relocations: (not relocatable) Version : 4.3p2 Vendor: CentOS ... ... Signature : DSA/SHA1, Mo 09 Mär 2009 02:48:50 CET, Key ID a8a447dce8562897 Packager : Karanbir Singh <kbsingh@karan.org> URL : http://www.openssh.com/portable.html Summary : Passphrase-Dialog für OpenSSH und X Description : OpenSSH is a free version of SSH (Secure SHell), a program for logging into and executing commands on a remote machine. This package contains an X11 passphrase dialog for OpenSSH. /etc/profile.d/gnome-ssh-askpass.csh /etc/profile.d/gnome-ssh-askpass.sh /usr/libexec/openssh/gnome-ssh-askpass /usr/libexec/openssh/ssh-askpass
ssh in der Praxis
Auch wenn das Passwort bei ssh verschlüsselt übertragen wird, lohnt ein Blick auf die Alternative RSA/DSA-Authentifizierung. Bei dieser Variante muss gar kein Passwort über das Netz übertragen werden. Normalerweise muss der User beim Zugriff via ssh auf einen entfernten Rechner sein Passwort eingeben. Zum einen wollen wir aus Sicherheitsgründen darauf verzichten und zum anderen kann dies doch auf Dauer doch als etwas nervig empfunden werden. Einfacher geht dies über asymetrische Schlüssel.
Erzeugung eines Schlüssel
Als erstes erzeugen wir uns einen Schlüssel für die Authentifizierung:
[django@host ~]$ ssh-keygen -b 4096 -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/django/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/django/.ssh/id_rsa. Your public key has been saved in /home/django/.ssh/id_rsa.pub. The key fingerprint is: 2b:83:69:f2:76:e8:c9:8b:cf:34:c8:c2:ae:2b:e1:ee django@host.nausch.org
Die passphrase die man hier angibt, wird später beim Anmelden auf dem entfernten Rechner abgefragt, oder vom ssh-agent bei der Anmeldung mitübergeben.
Nun liegen in dem Verzeichnis /home/django/.ssh zwei Dateien:
[django@host .ssh]$ ll insgesamt 24 -rw------- 1 django django 3311 22. Apr 22:11 id_rsa -rw-r--r-- 1 django django 748 22. Apr 22:11 id_rsa.pub
id_rsa enthält den privaten Schlüssel und sollte auf keinen Fall weitergegeben werden und darf auch nur für den Nutzer selbst lesbar sein! id_rsa.pub, der öffentliche Schlüssel, dagegen muss auf den Zielrechner kopiert werden.
Zielverzeichnis anlegen und öffentlichen Schlüssel kopieren
Auf dem Zielrechner legen wir nun das Verzeichnis .ssh an und schützen es entsprechend.
[django@zielhost django]$ mkdir .ssh [django@zielhost django]$ chmod 700 .ssh
Den öffentlichen Schlüssel kopieren wir dann wie folgt auf das Zielsystem:
[django@host .ssh]$ scp /home/django/.ssh/id_rsa.pub zielhost:/home/django/.ssh/id_rsa.pub
Anschließend wird der Schlüssel in die Datei authorized_keys kopiert. Diese Datei kann mehrere Schlüssel enthalten, daher ist das doppelte Umleitungszeichen wichtig, um eine evt. existierende Datei nicht versehentlich zu überschreiben. Somit wird der neue Schlüssel in die Datei hinzugefügt:
[django@zielhost .ssh]$ cat id_rsa.pub >> authorized_keys
Zu guter Letzt passen wir noch die Berechtigungen an und löschen die nicht mehr benötigte id_rsa.pub
[django@zielhost .ssh]$ chmod 600 authorized_keys [django@zielhost .ssh]$ rm id_rsa.pub
Das Kopieren des Public-Keys auf unseren Zielhost mit Anpassen der Dateiberechtigungen kann man natürlich auch einfacher vornehmen. Man benutzt hierzu einfach den Befehl ssh-copy-id aus dem Paket openssh-clients.
$ ssh-copy-id -i ~/.ssh/id_rsa.pub testhost.intra.nausch.org
Die Angabe ~/.ssh/id_rsa.pub
entspricht dabei dem Public-Key und testhost.intra.nausch.org
dem gewünschten Zielhost.
authorized_keys vs. authorized_keys2
Bei der Einführung von SSH Version 2 kam die Datei authorized_keys2
zum Einsatz. Seit OpenSSH 3.0 wird nun wiederum neben der authorized_keys2
wieder die authorized_keys
verwendet. In unserem Fall nutzen wir in unserem obigen Beispiel daher nur noch die Schlüsseldatei authorized_keys
.
ssh-Daemon
ssh-Daemon einrichten/anpassen
Folgende Zeilen müssen wir in der Datei /etc/ssh/sshd_config anpassen:
# vim /etc/ssh/sshd_config
PermitRootLogin yes RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
Anschließend starten wir mit
# service sshd restart
den ssh-Daemon neu und melden uns mit ssh zielhost am entfernten Rechner an.
Finale sshd-Änderungen
Das war's eigentlich schon. Im Moment kann sich der user mittels rsa-key oder seinem Passwort anmelden -es funktionieren beide Verfahren. Das kann während der Umstiegphase von Passwörtern auf Schlüssel wichtig sein, um sich z.B. nicht versehentlich selbst auszusperren. Schlägt die Anmeldung mit dem fehl, tritt wieder die Passwortauthentifizierung in Kraft.
Wenn jedoch alles wunschgemäß funktioniert sollte man in der /etc/ssh/sshd_config des Zielsystems folgenden Eintrag freischalten:
# vim /etc/ssh/sshd_config
PasswordAuthentication no
Anschließend den daemon wieder mittels:
# service sshd restart
neu starten.
Somit sind dann nur noch Userlogins zugelassen, die einen Publikkey auf dem Zielsystem besitzen.
Wichtig ist jedoch immer:
Der User muß selbst darauf achten, dass sein privater Schlüssel nicht in fremde Hände gelangt! Will man noch sicherer gehen, vergibt man, wie Eingangs bereits erwähnt, bei der Erzeugung des Schlüssels eine Passphrase. Diese muss er User dann aber bei jedem neuen Verbindungsaufbau angeben!
ssh-Daemon automatisch starten
Damit der ssh-Daemon sshd automatisch bei jedem Systemstart startet, kann die Einrichtung eines Start-Scripts über folgenden Befehl erreicht werden:
# chkconfig sshd on
Ein Überprüfung ob der Dienst (Daemon) sshd wirklich bei jedem Systemstart automatisch mit gestartet wird, kann durch folgenden Befehl erreicht werden:
# chkconfig --list | grep sshd sshd 0:Aus 1:Aus 2:Ein 3:Ein 4:Ein 5:Ein 6:Aus
Wichtig ist jeweils der Schalter on bei den Runleveln - 2 3 4 5.
sshd-Agent nutzen
Damit man nicht bei jedem anmelden am entfernten Rechner, die Passphrase erneut eingeben müssen, nutzen wir nun den ssh-agent.
Im Homeverzeichnis des remote-clients legen wir ein Verzeichnis autostart an:
$ mkir /home/django/.config/autostart
Dort legen wir die Datei ssh-add.desktop mit folgendem Inhalt an:
[Desktop Entry] Name=No name Encoding=UTF-8 Version=1.0 Exec=ssh-add X-GNOME-Autostart-enabled=true
Somit wird beim nächsten Amelden am X-Gnome-Desktop die passphrase einmalig abgefragt und beim Anmelden am Remotesystem mit übertragen.
SSH ProxyCommand - Transparente multi-jump SSH
Oft steht man vor einem Problem, dass man ein Host nicht direkt via ssh erreichbar ist, man aber dennoch zur Adminsitration dort hin möchte oder gar Dateien via scp kopieren möchte.
Schauenm wir uns hierzu einfach mal nachstehende Skizze an.
Von der Admin-Workstation aus, wollen wir nun nicht nur zum nächstgelegenen Host springen, sondern auch zum übernächsten oder gar zu einem Host im Internet, den wir aber aus Sicherheitsgründen nicht direkt erreichen dürfen und auch können.
System-Skizze
Lösung
manuelle Sprünge
Die vermutlich naheliegendste Variante ist vermutlich der jeweils manuelle Spring zum nächsten Host. Damit wir in unserem Beispiel die A-Firewall erreichen können springen wir nacheinander zum jeweilig nächsten Host. Mit Hilfe der Option -A nutzen wir dabei die SSH-Key-Forwarding-Option des SSH-Agenten.
$ ssh -A firewall-c.idmz.nausch.org
$ ssh -A firewall-b.edmz.nausch.org
$ ssh -A firewall-a.nausch.org
Na ja, komfortabel ist das nicht gerade und beim Kopieren von Daten von Ende zu Ende nervt das doch gewaltig, oder?
verkette Sprünge
O.K. wird sich da der ein oder andere sagen, dann verkette ich die Sprünge doch einfach.
$ ssh -A -t firewall-c.idmz.nausch.org ssh -A -t firewall-b.edmz.nausch.org ssh -A firewall-a.nausch.org
Oder ich schreib mir jeweils kleine bash-scripte zum Springen
$ vim ~/bin/fwa-jump
- ~/bin/fwa-jump
# /bin/bash ssh -t -A -Y firewall-c.idmz.nausch.org 'ssh -Y -A -l swat maill.idmz.nausch.org'
Na ja, das Kopieren geht immer noch nur von Host zu Host, oder eben mit einer verketteten Befehlsfolge oder eigenen Bash-Scripten.
ssh mit ProxyCommand und netcat
Die Komfortabelste Variante ist nun die Nutzung der Option ProxyCommand. Hierzu legen wir uns einmalig eine entsprechende Konfigurationsdatei auf unserer Administrations-Workstation mit nachfolgendem Inhalt an.
$ vim ~/.ssh/config
- ~/.ssh/config
# Django : 2012-06-13 # ssh-jumps über mehrere Sprunghosts # Erster Sprunghost (fwc) - direkt erreichbar # Host --> fwc Host fwc Hostname firewall-c.idmz.nausch.org # Zweiter Sprunghost (fwb) - nur über fwc erreichbar # Host --> fwc --> fwb Host fwb Hostname firewall-b.edmz.nausch.org ProxyCommand ssh fwc nc -w 120 %h %p # Dritter Sprunghost (fwa) - nur über fwb erreichbar # Host --> fwc --> fwb --> fwa Host fwa Hostname firewall-a.nausch.org ProxyCommand ssh fwb nc -w 120 %h %p # externer Server im Internet nur über externe Firewall "A" erreichbar # also: Host --> fwc --> fwb --> fwa --> daxie Host daxie Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag> ProxyCommand ssh -l root -i ~/.ssh/id_rsa_daxie -2 -4 fwa nc -w 120 %h
Anschließend passen wir noch die Dateiberechtigungen an, damit ssh später nicht mäkelt.
$ chmod 600 ~/.ssh/config
Auf den Sprunghosts wird das Paket netcat benötigt. Wenn dies noch nicht bei der Grundinstallation unseres Systems bereits installiert wurde, werden wir dies nun noch nachholen.
# yum install nc -y
Test
Nun können wir ganz einfach direkt einen Tunnel zu unserem Zielhost aufspannen, genauso also würden wir den Zielhostz direkt „sehen“.
$ ssh fwa
Auch können wir nun ohne großem Heckmeck Dateien von einem Ende zum anderen Ende kopieren.
$ scp ~/Downloads/enigmail-1.4-sm+tb.xpi daxie:/tmp/
$ scp daxie:/home/baby/Photos/Bild_001.png .