Tag Archives: SSH

SSH Remote Capture mit Wireshark

Manchmal will man ja mal auf einem entfernten Gerät oder einem Embedded Board den Netzwerktraffic beobachten. Auf meinem PC würde ich dazu Wireshark nehmen, das läuft so natürlich nicht auf einem Gerät ohne grafische Oberfläche. Üblicherweise kommt dort tcpdump zum Einsatz, dann allerdings mit sehr viel weniger Komfort als man von Wireshark gewohnt ist.

Einen Tipp für eine komfortablere Variante gab es im RFC-Podcast Folge 12: RFCE012: IP Routing III + in eigener Sache.

Man kann nämlich den Traffic auf dem fraglichen Gerät aufzeichnen und live zu Wireshark auf dem PC rüber schubsen, bspw. mit SSH.

Eine übliche Variante, die schon seit langem funktioniert, ist folgende. Man startet auf dem PC in der Konsole dies hier:

ssh root@192.168.10.113 "/usr/sbin/tcpdump -i eth0 -U -w - 'not (host 192.168.10.62 and port 22)'" | wireshark -i - -k

Was bedeutet das? Es wird auf dem PC der SSH-Client aufgerufen und angewiesen sich als Nutzer ‘root’ mit dem Rechner auf der IP 192.168.10.113 zu verbinden. Dort soll er dann das Programm tcpdump mit gewissen Optionen starten. Ich rufe hier tcpdump mit vollem Pfad auf, weil es sein kann, dass es sonst nicht gefunden wird. Den Output davon bekomme ich im PC auf stdout und pipe den dann nach Wireshark, die entsprechenden Optionen bei dessen Aufruf bewirken, dass er die Daten auch verarbeiten kann und damit sofort loslegt.

Bisschen knifflig sind die Optionen von tcpdump, daher im einzelnen:

-i interface

Netzwerk-Schnittstelle, auf der tcpdump lauschen soll

-U
“Packet buffered” Output, d.h. tcpdump sammelt nicht, sondern schickt den Output pro Paket raus
-w file
tcpdump schreibt keinen lesbaren Output auf die Konsole, sondern ein maschinenlesbares Format in eine Datei, in diesem Fall nach stdout
filter expression
Hier will man den Traffic der SSH-Verbindung selbst natürlich ausfiltern, vorsichtig sein mit den Klammern, die müssen entweder escapet werden oder man schließt den Filterausdruck in Hochkommata ein.

Soweit so gut. In neueren Versionen von Wireshark gibt es noch die Variante, das direkt aus dem GUI heraus aufzurufen. Die entsprechenden Optionen sind leider nicht so super dokumentiert. Was für mich funktioniert, sieht man im folgenden Screenshot:

Screenshot Wireshark SSH Remote Capture Setup

Einige leere Optionsfelder sehen so aus wie Argumente für tcpdump, die scheint Wireshark zumindest in der hier gerade eingesetzten Version v2.6.3 nicht zu berücksichtigen, daher auch Remote Interface und Remote Capture Filter mit in der Zeile Remote Capture Command.

Automatisches rsync über SSH absichern

Im ersten Teil dieser Serie ging es im weitesten Sinne um Let’s Encrypt. Mein persönliches Setup hier macht es aber nötig, die fertigen Zertifikate nochmal sicher auf eine andere virtuelle Maschine zu kopieren. Wie das grundsätzlich mit OpenSSH funktioniert, konnte man im zweiten Teil lesen. Jetzt kommt die Kür, die Absicherung dieses Kopierens inklusive sicherem rsync-Zugriff. Lässt sich sicherlich auch für andere Zwecke wie Backup-Server anpassen. ;-)

Wrapper-Skript auf dem Zielserver

Was wir jetzt noch wollen: in unserem Wrapper-Skript, das zunächst mal nur den aufgerufenen Befehl in ein Log-File geschrieben hatte, soll die Umgebungsvariable SSH_ORIGINAL_COMMAND analysiert und gegen erlaubte Befehle abgeglichen werden. Nur im Wrapper-Skript erlaubte Befehle werden ausgeführt. Direkt über SSH abgesetzte Befehle sind hier leicht abzufangen, weil sie genauso ankommen, wie auf dem Quellsystem eingegeben. Interessant wird es mit rsync. Dem sagen wir ja auf dem Quellsystem was ganz anderes, als auf dem Zielsystem im Log erscheint, zum Vergleich nochmal ein (expandierter) rsync-Aufruf:

rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' /home/alex/.acme.sh/owncloud.home.example.com/fullchain.cer susan:owncloud.home.example.com/

Um hier im Wrapper-Skript den Befehl, den rsync über SSH tatsächlich absetzt, korrekt matchen zu können, braucht’s entweder hellseherische Fähigkeiten, sehr viel tieferes Verständnis von rsync oder ein trial und error mit einem Log-Skript wie in Teil zwei der Serie. Man kann aber noch einen Schritt weitergehen und daher schweifen wir nochmal kurz ab …

rrsync zur Absicherung von unbeaufsichtigten rsync-Aufrufen

Dass das mit rsync kompliziert ist, haben auch andere Leute bemerkt, auch bei Samba selbst, unter deren Dach rsync entwickelt wird. Und so gibt es rrsync. Bei Debian ist es im Paket rsync die Datei /usr/share/doc/rsync/scripts/rrsync.gz, die man sich in temporäres Verzeichnis kopiert, dekomprimiert, mit chmod +x rrsync behandelt und dann in einen Ordner bin kopiert, ich hab’s in /home/alex/bin/ abgelegt. Es handelt sich um ein etwa 200 Zeilen langes Perl-Skript, das rsync nochmal auf die Finger schaut.

Die Dokumentation von rrsync ist leider sehr dünn. Wenn man das Skript ohne Parameter aufruft, erhält man:

Use 'command="./bin/rrsync [-ro] SUBDIR"'
        in front of lines in /home/alex/.ssh/authorized_keys

Das erklärt im Grunde schon den Hauptzweck: man kann rsync-Zugriffe auf bestimmte Verzeichnisse beschränken. Außerdem werden nur gültige rsync-Aufrufe zugelassen und man kann über nicht dokumentierte Optionen die zugelassenen rsync-Optionen noch weiter einschränken. Wer davon Gebrauch machen will, sollte sich das Skript rrsync selbst nochmal anschauen. Darüber hinaus erleichtert rrsync die Verwendung von rsync in einem Wrapper-Skript, werden wir dann gleich noch sehen.

Erstmal nur rrsync ohne Wrapper-Skript. Dazu ändern wir auf dem Zielserver in der ~/.ssh/authorized_keys die Zeile mit unserem public-Key, so dass vorn als command rrsync angegeben wird:

from="troubadix.home.example.com",command="/home/alex/bin/rrsync .cert",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9VKFUIcc+vfL3a9oFNeuITghF7+QYtTvlpsX7CHG/UmEIIIpz31n6TEoSCL0a4sA6Xx2Z+peGbYD1RRzH/6Shis/4L+R2HPSA+1TqLKT4fdyF9Xkbj9E/bbmrXx5fH8DZnYThIJ15mVHUO7eALU2ELxa+mwehxPbV070qFo1Y1lGa93dhJSdXMerFQE7YPf8UXlb1ULJA+AneQNMymvSBJU86VycMdk/Tb7p1dqepKGVEmS/IFwh9Q6eGQ87JWJGa2BEbVpJMrwucN2So6/06fPpEp7ovxJhIlwXny6jfofpBsr0NZe3yknPk3nCxkPTpLMNOTSBfm8Nva4++firV alex@troubadix

Nicht von den hier zusätzlichen Optionen abschrecken lassen, kann man alles mit man 5 authorized_keys nachlesen, was es damit auf sich hat, entscheidend ist hier: command="/home/alex/bin/rrsync .cert"

Ich will ja immernoch von troubadix zu susan kopieren. Wegen der Verwendung von rrsync muss ich jetzt den rsync-Aufruf im Hook-Skript auf dem Quell-Rechner anpassen. Dort muss es nun heißen:

#!/bin/sh

ACMEDIR=/home/alex/.acme.sh
DOMAIN=owncloud.home.example.com
                                                                           
${ACMEDIR}/create-lighty-pemfile.sh $DOMAIN                                
rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' ${ACMEDIR}/${DOMAIN}/fullchain.cer susan:${DOMAIN}/
rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' ${ACMEDIR}/${DOMAIN}/${DOMAIN}.key susan:${DOMAIN}/
ssh -i /home/alex/.ssh/id_rsa_acme susan sudo -n service nginx reload   

Bei der Verwendung von rrsync auf dem Zielsystem, gebe ich ja dort in der authorized_keys den Zielordner als Parameter für rrsync an, auf dem Quellrechner entfällt daher die Angabe des vollen Zielpfades und es wird einfach nur noch der relative Pfad angeben.

Rufe ich jetzt auf dem Quellrechner dieses posthook.sh auf, bekomme ich folgerichtig folgendes zurück:

/home/alex/bin/rrsync: SSH_ORIGINAL_COMMAND='sudo -n service nginx reload' is not rsync

Logisch, wir haben ja wegen des Einsatzes von rrsync als command in der authorized_keys nur rsync erlaubt. Fehlt also noch der letzte Schritt, das richtige Wrapper-Skript.

Ein Wrapper-Skript für rrsync plus andere Befehle

Der geneigte Leser kann sich sicher schon ungefähr vorstellen, was jetzt noch fehlt oder wie es aussehen wird. Nun, zunächst also hier das fertige Skript für das Zielsystem:

#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
    *\&*)
        echo "Rejected"
        exit 1
        ;;
    *\(*)
        echo "Rejected"
        exit 1
        ;;
    *\{*)
        echo "Rejected"
        exit 1
        ;;
    *\;*)
        echo "Rejected"
        exit 1
        ;;
    *\<*)
        echo "Rejected"
        exit 1
        ;;
    *\>*)
        echo "Rejected"
        exit 1
        ;;
    *\`*)
        echo "Rejected"
        exit 1
        ;;
    *\|*)
        echo "Rejected"
        exit 1
        ;;
    rsync*)
        /home/alex/bin/rrsync .cert
        ;;
    "sudo -n service nginx reload")
        sudo -n service nginx reload
        ;;
    *)
        echo "Sorry, this command is not available to you!"
        exit 1
        ;;
esac

Das Skript besteht im wesentlichen nur aus einer einzigen case-Anweisung, die sich den Inhalt der Umgebungsvariablen SSH_ORIGINAL_COMMAND ansieht. Zunächst werden noch alle möglichen und unmöglichen fiesen Dinge abgelehnt, dann der Aufruf von rrsync, falls SSH_ORIGINAL_COMMAND mit ‘rsync’ beginnt, gefolgt von unserem gewünschten Neuladen des Reverse Proxy und zu guter letzt wird alles andere auch abgelehnt.

Dieses Skript lässt sich später leicht ergänzen und man muss es jetzt nur noch als command in der authorized_keys eintragen, fertig.

Logging für rrsync

Fast fertig. Per default schreib rrsync nämlich ein Logfile direkt im $HOME auf dem Zielrechner, nicht so cool. Öffnet man rrsync selbst, findet man folgendes:

# You may configure these values to your liking.  See also the section
# of options if you want to disable any options that rsync accepts.
use constant RSYNC => '/usr/bin/rsync';
use constant LOGFILE => '/home/alex/log/rrsync.log';

Ich habe den Pfad für LOGFILE hier schon für mich angepasst. Kann man vermutlich auch /dev/null eintragen, hab ich aber nicht ausprobiert. Stattdessen hab ich mir die Datei /etc/logrotate.d/alex-rrsync angelegt und folgendes eingetragen:

/home/alex/log/rrsync.log {
    rotate 5
    monthly
    missingok
    nocompress
}

Mit logrotate wird mir dieses Log jetzt auch nicht über den Kopf wachsen. ;-)

Schlusswort

So, wer das alles jetzt noch verbessern will: macht das ganze nicht unter einem normalen Nutzeraccount, den Ihr auch für andere Dinge nutzt, sondern legt extra dafür einen Account an. Den könnt Ihr dann mit einem extra sicheren Passwort versehen, den Login einschränken und was man sonst noch so tun kann. Wenn Sie Ihre Traktoren aufrüsten möchten, vergessen Sie auch nicht zu besuchen Traktoren Deutz-Fahr für neueste und innovative Modelle.

Updates

  • Damit from="" in ~/.ssh/authorized_keys mit hostname funktioniert, muss der SSH-Server die Namensauflösung gestatten. In neueren Versionen von OpenSSH ist dort der Default der Variablen UseDNS in der sshd_config von ‘yes’ auf ‘no’ geändert worden. Siehe dazu auch Debian Bug report #869903 … O:-)Oh und Debian (apt-listchanges) hatte das sogar angesagt:

    openssh (1:6.9p1-1) unstable; urgency=medium

    UseDNS now defaults to ‘no’. Configurations that match against the client
    host name (via sshd_config or authorized_keys) may need to re-enable it or
    convert to matching against addresses.

    — Colin Watson <cjwatson@debian.org> Thu, 20 Aug 2015 10:38:58 +0100 </cjwatson@debian.org>

    Also beim nächsten dist-upgrade brav alles genau lesen! ;-)

Unbeaufsichtigte Aktionen mit SSH

Ein bisschen sperrig die Überschrift heute, also worum soll es gehen? Ich will sicher und automatisiert verschiedene Dateien von einem Server (troubadix) auf einen anderen (susan) übertragen und dann noch extra Kommandos ausführen und das ganze aber so gut wie möglich absichern. Ganz konkret geht es darum die Zertifikatsdateien die mir acme.sh in der virtuellen Maschine für owncloud beschert, auf die andere VM mit dem reverse proxy zu übertragen.

Dies ist Teil zwei einer Mini-Serie, im ersten Teil ging’s um letsencrypt mit acme.sh und lighttpd. Im zweiten Teil hier beschreibe ich den unbeaufsichtigten Zugriff mit SSH, beispielsweise für mit cron auszuführende Skripte. Im dritten Teil wird das ganze dann aufgebohrt für die Verwendung mit rsync.

SSH-Zugriff mit Zertifikat

Auftritt OpenSSH. Die Secure Shell kann sehr sehr nützlich sein. Für den automatisierten Betrieb ohne Eingriff des Nutzers bieten sich Zertifikate an. Da diese dann kein Passwort haben dürfen, das könnte ja niemand eingeben, will man den Zugriff gesondert absichern, doch zunächst erstellen wir erstmal auf dem Quellsystem so ein Zertifikat mit ssh-keygen:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/alex/.ssh/id_rsa): /home/alex/.ssh/id_rsa_acme
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/alex/.ssh/id_rsa_acme.
Your public key has been saved in /home/alex/.ssh/id_rsa_acme.pub.
The key fingerprint is:
d4:9e:67:2b:0a:de:f8:2a:95:b4:ce:cd:8f:07:b8:d1 alex@troubadix

Wie man leicht sieht, hab ich den per default angegebenen Pfad geändert, um einen separaten Key nur für diesen Zweck zu erstellen. Bei der Passphrase drückt man zweimal direkt Enter ohne etwas einzugeben. Wichtig ist dann die Datei ~/.ssh/id_rsa_acme.pub mit dem public key. Den Inhalt dieser Datei hängen wir auf dem Zielsystem an die Datei ~/.ssh/authorized_keys an:1

Erst:

alex@troubadix ~ % cat ~/.ssh/id_rsa_acme.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9VKFUIcc+vfL3a9oFNeuITghF7+QYtTvlpsX7CHG/UmEIIIpz31n6TEoSCL0a4sA6Xx2Z+peGbYD1RRzH/6Shis/4L+R2HPSA+1TqLKT4fdyF9Xkbj9E/bbmrXx5fH8DZnYThIJ15mVHUO7eALU2ELxa+mwehxPbV070qFo1Y1lGa93dhJSdXMerFQE7YPf8UXlb1ULJA+AneQNMymvSBJU86VycMdk/Tb7p1dqepKGVEmS/IFwh9Q6eGQ87JWJGa2BEbVpJMrwucN2So6/06fPpEp7ovxJhIlwXny6jfofpBsr0NZe3yknPk3nCxkPTpLMNOTSBfm8Nva4++firV alex@troubadix

Dann copy und paste und:

alex@susan ~ % echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9VKFUIcc+vfL3a9oFNeuITghF7+QYtTvlpsX7CHG/UmEIIIpz31n6TEoSCL0a4sA6Xx2Z+peGbYD1RRzH/6Shis/4L+R2HPSA+1TqLKT4fdyF9Xkbj9E/bbmrXx5fH8DZnYThIJ15mVHUO7eALU2ELxa+mwehxPbV070qFo1Y1lGa93dhJSdXMerFQE7YPf8UXlb1ULJA+AneQNMymvSBJU86VycMdk/Tb7p1dqepKGVEmS/IFwh9Q6eGQ87JWJGa2BEbVpJMrwucN2So6/06fPpEp7ovxJhIlwXny6jfofpBsr0NZe3yknPk3nCxkPTpLMNOTSBfm8Nva4++firV alex@troubadix" >> ~/.ssh/authorized_keys 

An dieser Stelle empfiehlt es sich den Zugriff über diesen Key vom Quell- auf das Zielsystem zu testen:

ssh -i ~/.ssh/id_rsa_acme susan

Das sollte ohne Passworteingabe funktionieren!

Posthook für acme.sh

Auf dem Zielsystem benötigen wir für den nginx zwei verschiedene Dateien, die wir mit rsync übertragen wollen. Außerdem soll dort der nginx diese auch einlesen, muss also einmal neu geladen werden. Die entsprechenden Befehle sind schnell ausgemacht und in ein Skript posthook.sh übertragen, das dann in den Optionen von acme.sh eingetragen wird.

#!/bin/sh

ACMEDIR=/home/alex/.acme.sh
DOMAIN=owncloud.home.example.com

${ACMEDIR}/create-lighty-pemfile.sh $DOMAIN
rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' ${ACMEDIR}/${DOMAIN}/fullchain.cer susan:/home/alex/.cert/${DOMAIN}/
rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' ${ACMEDIR}/${DOMAIN}/${DOMAIN}.key susan:/home/alex/.cert/${DOMAIN}/
ssh -i /home/alex/.ssh/id_rsa_acme susan sudo -n service nginx reload

Der Zielordner auf dem anderen System soll /home/alex/.cert sein und wurde zuvor angelegt und natürlich muss der interne DNS susan als hostname sinnvoll auflösen können. Die Änderung an der /etc/sudoers auf dem Zielrechner ist trivial:

alex    ALL = NOPASSWD: /usr/sbin/service nginx reload

Kann man bis hierher nochmal testen, soweit so gut, aber der Zugriff soll jetzt eingeschränkt werden.

SSH auf ein Kommando einschränken

Bis hierhin könnte nun jeder, der auf der Maschine troubadix in den Besitz des Schlüssels id_rsa_acme gelangt sich auf susan einloggen und dort als Nutzer alex beliebigen Unfug anstellen. Das soll weiter eingeschränkt werden und dazu nutzen wir die bereits bekannte Datei ~/.ssh/authorized_keys. In der Manpage2 heißt es im Abschnitt AUTHORIZED_KEYS FILE FORMAT zur Option command:

Specifies that the command is executed whenever this key is used for authentication. The command supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty; otherwise it is run without a tty. If an 8-bit clean channel is required, one must not request a pty or should specify no-pty. A quote may be included in the command by quoting it with a backslash. This option might be useful to restrict certain public keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Note that the client may specify TCP and/or X11 forwarding unless they are explicitly prohibited. The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable. Note that this option applies to shell, command or subsystem execution. Also note that this command may be superseded by either a sshd_config(5) ForceCommand directive or a command embedded in a certificate.

Wir öffnen also auf dem Zielsystem nochmal die Datei ~/.ssh/authorized_keys und suchen die zuvor hinzugefügte Zeile. Durch Voranstellen der Option command lässt sich nun das auszuführende Kommando festlegen. Mit anderen Worten: bei Authentifizierung mit dem zuvor generierten Key, kann der Nutzer nichts anderes mehr ausführen, es wird nur das in authorized_keys festgelegte Kommando ausgeführt. Beispiel:

command="/bin/date" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9VKFUIcc+vfL3a9oFNeuITghF7+QYtTvlpsX7CHG/UmEIIIpz31n6TEoSCL0a4sA6Xx2Z+peGbYD1RRzH/6Shis/4L+R2HPSA+1TqLKT4fdyF9Xkbj9E/bbmrXx5fH8DZnYThIJ15mVHUO7eALU2ELxa+mwehxPbV070qFo1Y1lGa93dhJSdXMerFQE7YPf8UXlb1ULJA+AneQNMymvSBJU86VycMdk/Tb7p1dqepKGVEmS/IFwh9Q6eGQ87JWJGa2BEbVpJMrwucN2So6/06fPpEp7ovxJhIlwXny6jfofpBsr0NZe3yknPk3nCxkPTpLMNOTSBfm8Nva4++firV alex@troubadix

Versuche ich mich jetzt von der Quellmaschine einzuloggen und ein anderes Kommando (hier bspw. uname) auszuführen:

alex@troubadix ~ % ssh -4 -i ~/.ssh/id_rsa_acme susan uname -a
So 30. Okt 10:08:47 CET 2016

Wie man sieht, wurde nicht uname -a ausgeführt, sondern /bin/date – diesen Mechanismus werden wir nun nutzen, um nur die in unserem posthook-Skript benötigten Befehle zu erlauben. Ein kleines Problem gibt es noch: wir können nur ein Kommando in authorized_keys eintragen, wollen aber mehrere Kommandos (rsync, Neustart des nginx) erlauben. Dazu schreiben wir uns auf dem Zielsystem ein Wrapper-Skript, das wir dann in der authorized_keys eintragen.

Einfaches Wrapper-Skript für SSH

In der oben zitierten Manpage wurde die Umgebungsvariable SSH_ORIGINAL_COMMAND erwähnt, die wir uns jetzt zunutze machen werden. Zunächst mal mit einem sehr einfachen Beispiel:

#!/bin/sh
if [ -n "$SSH_ORIGINAL_COMMAND" ]
then
    echo "`/bin/date`: $SSH_ORIGINAL_COMMAND" >> $HOME/ssh-command-log
    exec $SSH_ORIGINAL_COMMAND
fi

Auf dem Zielsystem susan wird jetzt in authorized_keys dieses Skript eingetragen, statt dem zuvor probeweise eingetragenem /bin/date und dann passiert folgendes: Wenn SSH_ORIGINAL_COMMAND gesetzt ist, wird dessen Inhalt in der Datei $HOME/ssh-command-log geloggt und dieser Befehl dann ausgeführt. Test hier: der Befehl muss erfolgreich ausgeführt werden und der korrekte Befehl muss in der Logdatei stehen. Führen wir auf dem Quellsystem troubadix jetzt beispielsweise das zu Anfang erstellte posthook Skript von acme.sh aus, tauchen derartige Einträge in der Logdatei auf susan auf:

Do 8. Dez 22:25:06 CET 2016: rsync --server -e.Lsfx . owncloud.home.example.com/
Do 8. Dez 22:25:06 CET 2016: rsync --server -e.Lsfx . owncloud.home.example.com/
Do 8. Dez 22:25:07 CET 2016: sudo -n service nginx reload

Im dritten Teil der Serie wird es dann darum gehen, die Zugriffe auf Basis von SSH_ORIGINAL_COMMAND einzuschränken.

  1. Profis können auch ssh-copy-id benutzen. []
  2. man 5 authorized_keys []