Ich habe etwa 30 nahezu identische CentOS 6-Server, die aktualisierte Konfigurationsdateien automatisch mit einem RSA-Schlüssel bereitstellen müssen, um mich als Root anzumelden. Normalerweise ist dafür nur Rsync erforderlich, aber manchmal müssen möglicherweise Befehle auf den Servern ausgeführt werden, sodass auch SSH erforderlich ist. Da dies als Skript ausgeführt wird, um alle 30 Server zu aktualisieren, möchte ich keine Passphrase auf dem Schlüssel haben.
Bei mir funktioniert dieser Teil einwandfrei. Ich habe den RSA-Schlüssel erstellt und ihn zu authorized_keys für root hinzugefügt, sodass ich per SSH oder Rsync auf die Server zugreifen kann, ohne ein Passwort eingeben zu müssen.
Ich habe authorized_keys so eingestellt, dass nur der Schlüssel von einem einzigen Hostnamen akzeptiert wird, was dieses Setup relativ sicher machen sollte. Allerdings bin ich damit noch nicht ganz zufrieden und möchte es daher so einrichten, dass bei jeder Verwendung dieses Schlüssels eine E-Mail an unser gemeinsames technisches Postfach gesendet wird.
Es kommt häufig vor, dass ich mich als ich selbst bei diesen Servern anmelde und mich mit su als Root anmelde. Das ist in Ordnung, und ich möchte das technische Postfach nicht jedes Mal mit Spam überfluten, wenn sich einer von uns anmeldet. Ich möchte die E-Mails nur erhalten, wenn der SSH-Schlüssel verwendet wird.
Folgendes habe ich bisher auf Server1[bis 30].example.com:
cat /root/.ssh/authorized_keys
from="pusher.example.com",environment="SSHKEY=1" ssh-rsa AAAAB3NzaIwAAAxetcetc== root@pusher
tail -n 3 /root/.bash_profile
if [[ "${SSHKEY}" == "1" ]] ; then
echo 'Either we are getting hacked, or somebody used the SSH key on pusher to push something out to ' `hostname` ' at ' `date` | mail -s "WARNING - ROOT SSH KEY USED ON `hostname`!" [email protected]
fi
Das funktioniert perfekt für SSH. Wenn ich mich als ich selbst anmelde und „su“ ausführe, um Root zu werden, erhalte ich keine E-Mail. Wenn ich mich jedoch bei Pusher anmelde und Folgendes ausführe:
ssh -i /root/.ssh/server1.pri server1.example.com
Ich bekomme eine E-Mail. Das Problem besteht darin, Dateien zu übertragen. Wenn ich eines der folgenden ausführe:
scp -i /root/.ssh/server1.pri /tmp/file.txt server1.example.com:/tmp/
rsync -e 'ssh -i /root/.ssh/server1.pri' /tmp/test.txt server1.example.com:/tmp/
Ich bekomme die E-Mail immer noch nicht.
Gibt es eine Möglichkeit, dies so einzurichten, dass bei jeder Verwendung des Schlüssels für irgendetwas eine E-Mail gesendet wird, anstatt sich auf bash_profile zu verlassen? (Oder alternativ nur, wenn es für scp oder rsync verwendet wird, und ich werde den Schlüssel so beschränken, dass nur diese ausgeführt werden?)
Antwort1
Sie können missbrauchen /root/.ssh/rcfür Ihren Zweck (siehe man sshd) und fügen Sie mailxdort einen Befehl ein.
Antwort2
~/.bash_profile wird verwendet, wenn Bash als interaktive Login-Shell aufgerufen wird. ~/.bashrc wird für Nicht-Login-Shells verwendet. Die Verwendung dieser Datei ist jedoch nicht zuverlässig, da Angreifer verlangen könnten, dass die Shell-Initialisierungsdateien überhaupt nicht gelesen werden.
Antwort3
Aus der SSHD-Manpage, Abschnitt „authorized_keys“:
command="Befehl"
Gibt an, dass der Befehl ausgeführt wird, wenn dieser Schlüssel zur Authentifizierung verwendet wird. Der vom Benutzer angegebene Befehl (sofern vorhanden) wird ignoriert. Der Befehl wird auf einem PTY ausgeführt, wenn der Client ein PTY anfordert; andernfalls wird er ohne TTY ausgeführt. Wenn ein sauberer 8-Bit-Kanal erforderlich ist, darf kein PTY angefordert werden oder es sollte no-pty angegeben werden. Ein Anführungszeichen kann in den Befehl eingefügt werden, indem es mit einem Backslash zitiert wird. Diese Option kann nützlich sein, um bestimmte öffentliche Schlüssel auf die Ausführung nur einer bestimmten Operation zu beschränken. Ein Beispiel könnte ein Schlüssel sein, der Remote-Backups zulässt, aber sonst nichts. Beachten Sie, dass der Client TCP- und/oder X11-Weiterleitungen angeben kann, sofern diese nicht ausdrücklich verboten sind. Der ursprünglich vom Client angegebene Befehl ist in der Umgebungsvariable SSH_ORIGINAL_COMMAND verfügbar. Beachten Sie, dass diese Option für die Ausführung von Shells, Befehlen oder Subsystemen gilt. Beachten Sie auch, dass dieser Befehl entweder durch eine ForceCommand-Direktive von sshd_config(5) oder einen in ein Zertifikat eingebetteten Befehl ersetzt werden kann.
Sie können diese Option zu Ihrem Schlüssel hinzufügen, so wie Sie die Optionen „Von“ und „Umgebung“ hinzugefügt haben:
cat /root/.ssh/authorized_keys
from="pusher.example.com",environment="SSHKEY=1" ssh-rsa AAAAB3NzaIwAAAxetcetc== root@pusher