Schlagwort-Archive: SSH

Dateien mit scp und Key, aber ohne Passphrase übertragen

Schreibe eine Antwort

Man kann scp ganz wunderbar dazu benutzen, um Dateien auf einen anderen Rechner zu übertragen. Allerdings muss man i.d.R. jedes mal das Passwort des Zielbenutzers angeben. Das ist für automatisierte Prozesse ziemlich unpraktisch.
Nun kann man aber auch einen SSH-Key ohne Passphrase erzeugen und diesen auf dem Zielrechner in der authorized_keys des entsprechenden Nutzers hinterlegen. Dann kann zwar nur derjenige User, der im Besitz des privaten Schlüssels ist, ohne Passwort/Passphrase auf diesen Rechner zugreifen, aber ganz so sicher ist das nicht. Allerdings kann man SSH-Keys auch mit einem sog. „forced Command“ verknüpfen, so dass mit diesem Key nur das definierte Kommando ausgeführt wird, unabhängig davon, was auf der Kommandozeile angegeben wurde. Dies geschieht in der authorized_keys auf dem Zielrechner, in dem man in der Zeile mit den entspr. Key vor diesem das gewünschte Kommando angibt, i.d.R. mit weiteren nützlichen Parametern:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="mache_nur_was_ich_will" ssh-rsa AAAAB3NzaC…

Aber wie muss das Kommando auf der Zielseite bei scp nun aussehen? Das lässt sich herausfinden, in dem man ein normalen scp-Befehl mit den Debug-Parameter -v absetzt. In der Ausgabe findet man u.a. dann so was wie (wenn nicht: siehe unten):

debug1: Sending command: scp -v -t myfile.txt

Hier taucht der undokumentierte scp-Parameter -t auf, der auch nur vom Programm auf der Zielseite verwendet wird. Wenn wir also das folgenden in der authorized_keys angeben, können wir mit den entspr. Key Dateien in das Verzeichnis /var/local/Backups kopieren – mehr nicht!

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -t /var/local/Backups/" ssh-rsa AAAAB3NzaC…

Aber das funktioniert nicht …

Es kann passieren, dass die Verbindung zwar aufgebaut wird, danach aber nichts mehr passiert. Die Verbindung „hängt“, es findet keine Datenübertagung statt.

Die Ursache ist, dass scp ab Version 9.0 standardmäßig das SFTP-Protokoll benutzen. Man erkennt es daran, dass in der oben erwähnten Debug-Ausgabe nicht das erwartete scp -v -t … steht, sondern:

debug1: Sending subsystem: sftp

Man muss scp auf der aufrufenden Seite also mit dem Parameter –O (großes O) dazu zwingen, das SCP-Protokoll zu verwenden.

Siehe auch: https://serverfault.com/a/88864

SSH-Key auf einen anderen Rechner übertragen

Schreibe eine Antwort

SSH ist eine feine Sache, um sicher auf einen anderen Rechner zu zugreifen. Häufig wird jedoch die Passwortabfrage genutzt, die aber nicht so sicher und komfortabel wie Key-Methode.

Damit man diese aber nutzen kann, muss der Public-Key auf dem Zielrechner in die Datei authorized_keys eingetragen werden. Aber auch das lässt sich einfach und komfortabel per SSH machen:

cat ~/.ssh/id_dsa.pub | ssh user@zielrechner \n  "cd ~/.ssh && cat >> authorized_keys"

Nun wird man beim nächsten Login nicht mehr nach dem Passwort des Users auf dem Zielrechner gefragt, sondern nach der sog. Passphrase, also dem Passwort, mit dem der private Teil des oben übertragenen öffentlichen Schlüssels verschlüsselt ist.

um die Sicherheit weiter zu erhöhen, kann man nun den Zugang per Passwortabfrage verbieten, indem man in der sshd_config PasswordAuthentication no einträgt. Man sollte dann aber auch UsePAM no setzen, sonst hat PasswordAuthentication kein Effekt.

KDE mit Keychain

Schreibe eine Antwort

Damit man nicht immer ständig die Passphrase für seinen SSH-Key eingeben muss ist keychain das passende Werkzeug. Normalerweise wird der entsprechende Aufruf in die bashrc o.ä. eingetragen. Bei grafischen Oberflächen ist das jedoch nicht die erste Wahl.

Bei KDE speichert man besser ein kleines Shellscript im persönlichen Autostart-Verzeichnis ~/.kde/Autostart

#!/bin/sh
keychain --quiet ~/.ssh/id_dsa
source ~/.keychain/${HOSTNAME}-sh

Wenn dieses Script ausführbar ist, wird der Anwender beim nächsten Start von KDE per Dialog nach der Passphrase gefragt. Dazu darf natürlich kein entspr. Eintrag in der .bashrc oder .profile vorhanden sein, da dieser sonst unserem kleinen Script eventuell zuvor kommt.

Verzeichnisse auf einen anderen Rechner übertragen

2 Antworten

Im vorigen Artikel habe ich gezeigt, wie man mit TAR ein komplettes Verzeichnis so verschieben bzw. kopieren kann, dass alle Rechte erhalten bleiben. Hier kommt nun die erweiterte Fassung zum kopieren von Verzeichnissen auf einen anderen Rechner mittels SSH und TAR. Und als Bonbon gibt’s ein Script zum Erstellen von Backups von anderen Rechnern.

Um das Verzeichnis foo vom eigenen Rechner auf dem Rechner kermit als Unterverzeichnis von /bar zu speichern benutzt man den folgenden Befehl:

tar cpSf - foo | ssh kermit "cd /bar && tar xpSvf -"

Wie man sieht, ähnelt der Aufruf sehr dem Befehl zum kopieren auf dem lokalen Rechner, lediglich das „ssh kermit“ ist neu (und die Klammern brauchen wir hier nicht). Ich gehe hier davon aus, dass der User des lokalen Rechners auch auf dem Rechner kermit bekannt ist. Soll auf kermit ein anderer Account, z.B. klaus, verwendet werden, schreibt man einfach „ssh klaus@kermit“. Der User muss auf jeden Fall ausreichende Rechte im Zielverzeichnis haben. Da ein Ziel ist, die Rechte beizubehalten, sollte das root sein.

Man kann tar die Daten auch komprimieren lassen und bei geringer Bandbreite das Ganze somit beschleunigen:

tar zcpSf - foo | ssh kermit "cd /bar && tar zxpSvf -"

Man kann das Ganze auch umkehren, also Verzeichnisse des entfernten Rechners auf den lokalen kopieren:

ssh kermit tar cSpf - /foo | (cd /bar && tar xpSvf -)

kopiert das Verzeichnis /foo von kermit auf dem lokalen Rechner ins Verzeichnis /bar.

Man kann dem ersten tar-Befehl übrigens auch mehrere Verzeichnisse übergeben. Das eignet sich hervoragend für ein einfaches Backup, insbesondere zusammen mit gzip:

ssh kermit tar cSpf - /foo /bar | gzip -f9 > kermit_backup.tgz

Das sichert die Verzeichnisse /foo und /bar des Rechners kermit als komprimiertes Tar-Archiv in der Datei kermit_backup.tgz auf dem Lokalen Rechner.

Ich mache so täglich Sicherungen von wichtigen Verzeichnissen meiner Server.

Auch hier kann man tar die Komprimierung übernehmen lassen:

ssh kermit tar zcSpf - /foo /bar > kermit_backup.tgz

Diese Variante ist schneller, die andere komprimiert dafür geringfügig besser.