Für alte SSH Hasen ist es nichts Unbekanntes, daß man von einem dritten PC aus, direkt Files zwischen zwei anderen SSH-Servern hinundher kopieren kann. Dazu muß lediglich zwei vollständige Logins angeben:

scp user@server1:/path/foo user@server2:/path/

Solange man die schwache Passwortauthentifizierung benutzt, bekommt man zwei Abfragen zu den Passwörtern der beiden Zugänge. Nachvollziehbar, weil Server 1 das Passwort für Server 2 nicht kennt.

Was aber, wenn man das nicht mehr benutzen kann, weil man sich nur noch mit Key authentifizieren kann ?

Der erste Server, dem man das Kommando zum Kopieren von Daten gibt, akzeptiert klaglos den Schlüssel den unser SSH-Agent ( das ist der Gnome-Keyring-Manager der bei Euch auf dem Desktop läuft ) zur Verfügung stellt. Damit kann man zwar das Kopieren starten, wird sofort ausgebremst, weil Server 1 das Passwort von Server 2 wissen will.

Wenn Server 2 jetzt auch nur noch Keys akzeptiert, weil die PasswortAuth im SSHD deaktiviert wurden, und das solltet Ihr immer einstellen:

PermitRootLogin without-password

Dann habt Ihr ein Problem, denn den nötigen Key kann man nicht vom heimischen PC zum ersten Server senden und dann zur Auth bei Server 2 nutzen.  Um das zu umschiffen gibt es eine unschöne Lösung, die „mal“ geht, wenn es sich um wenige Daten handelt: die Option “ -3 “ (Minus Drei) .

Diese Option sagt SCP , daß es die Daten erst zum eigenen PC überträgt und dann erst zum Server 2. Man kann also nicht mehr von einem Directcopy reden. Am spart sich so lediglich, daß die Dateien erstmal im Temp-Ordner vom System landen und später von Hand gelöscht werden müssen. So gesehen, macht es den Kopierprozess schon einfacher.

Die Lösung mit den Bauchschmerzen

Das es SSH-Agenten gibt, hatte ich ja schon erwähnt. Auf einem normalen Server kann man das Tool auch mit genau dem Namen starten : ssh-agent . Das Programm installieren wir auf Server 1 und rufen es auf. Es gibt uns einige Umgebungsvariablen aus :

#!/bin/bash
SSH_AUTH_SOCK=/tmp/ssh-tqJtR00AWwOq/agent.2040; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2048; export SSH_AGENT_PID;

Die müssen wir z.B. mit „export“ aktivieren, damit ssh den ssh-agent findet. Das obige Beispiel ist aus einem kleinen Script, daß beim Starten der Root-Shell ausgeführt wird. Damit ist man dann als Root automatisch an den ssh-agenten gebunden und muß sich nicht mehr um diese Details kümmern. Da man dem ssh-agent sagen kann, wie lange die Authentifizierungsdaten gecached werden sollen, kann man z.B. den ganzen Tag ohne Eingabe von Passwörtern für Keys arbeiten.

Auszug aus der /root/.bashrc

# Source ssh user agent
if [ -f /root/.sshagent ]; then
        .  /root/.sshagent
fi

Damit eröffnet sich eine Möglichkeit, die Daten von Server 1 auf Server 2 direkt zu kopieren, ohne schwache Passwörter benutzen zu müssen.  Man aktiviert also auf dem Server 1 den RSA/DSA – Schlüssel/key  für Server 2 im ssh-agent und kann dann mit SCP den ganzen Tag Aufträge verteilen.

ssh-add -i /path/foo/key.rsa

Wenn man Keys nutzt, sollte der jeweilige Key noch mit einem Passwort gesichert sein, damit nicht jeder den Key, so er denn erbeutet wurde, benutzen kann.

Und wieso Bauchschmerzen ?

Wenn man vernünftig Arbeiten will, muß der Agent die Authdaten mal min. für einen Arbeitstag cachen. Je länger desto mehr Bauchschmerzen sollte man bekommen, denn in der Zeit könnte jeder, der auf dem Server root wird, sich ungestört in allen Systemen einloggen oder Daten kopieren, zu denen der Schlüssel Einlass gewährt. Der Vorgang das einer Root wird, ist natürlich schon Horror pur, aber wenn die ganze Serverfarm betroffen ist, also wer bei dem Gedanken keine Bauchschmerzen bekommt, dem kann man nicht mehr helfen.

Wenn so ein Server sicher ist, braucht man natürlich keine Bauchschmerzen haben, aber bei den vielen Bugs die in allem möglichen drin ist…. puhh.. Ein bisschen Angst schwingt immer mit. Das mich keiner falsch versteht, ich liebe meinen ssh-agent, aber ich nutze ihn nur, wenn es unbedingt sein muß 🙂

Der logistische Teil

Der ssh-agent müßte auf allen Servern laufen und dort den Schlüssel aktiviert haben, von dem Daten irgendwohinanders kopiert werden sollen. Das kann im Detail recht aufwendig werden, wenn man nicht überall den gleichen Key benutzt.

Das es keine so gute Idee ist, überall den gleichen Key in jede Richtung zu benutzen, sollte Euch klar sein.