Inhaltsverzeichnis

Secure Shell - ssh

openSSH LogoBei 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

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

InternetDMZDMZ_HOSTsIntranetfremdgehostetes_SystemHost beim Housing-ProviderHostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag>IP-Adresse: aa-bb-cc-ddbredmzEDMZ-Netzwerkswitch (bredmz)Netz:10.0.0.0/24bridmzEDMZ-Netzwerkswitch (bridmz)Netz:10.10.0.0/24edmz_switchEDMZ-SwitchNetgear Typ: xFWBFQDN: vml000010.dmz.nausch.org--------Services: iptablesFWCFQDN: vml000020.dmz.nausch.org--------Services: iptablesIDMZ_Repository_HostFQDN: vml000050.dmz.nausch.orgCNAME : syslog, tftp, installIP (IDMZ) : eth0 - 52:54:00:19:08:67 - 10.0.0.50Services : syslog, httpd, rpm-repository, tftp/pxeEDMZ_Repository_HostFQDN: vml100080.dmz.nausch.orgCNAME : mailIP (EDMZ) : eth0 - 52:54:00:14:12:71 - 10.0.0.50Services : syslog, httpd, rpm-repository, tftp/pxeSwitchPhysikalischer Netzwerk-SwitchNetz 10.10.10.0/26WorkstationGerät: Djangos Admin-WorkstationHostname: pml010040CNAME: office-workMAC:IP:10.10.10.40Firewall_A---A-Firewall---

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 .

Links