BEZEICHNUNG

ssh-copy-id — lokal verfügbare Schlüssel zur Autorisierung von Anmeldungen an fernen Maschinen verwenden

ÜBERSICHT

ssh-copy-id [-f] [-n] [-s] [-x] [-i [Identitätsdatei]] [-p Port] [-o SSH-Option] [-t Zielpfad] [Benutzer@]Rechnername ssh-copy-id -h | -?

BESCHREIBUNG

ssh-copy-id ist ein Skript, das ssh(1) zur Anmeldung an fernen Maschinen verwendet (vermutlich mittels eines Anmeldepasswortes, daher sollte Passwort-Authentifizierung aktiviert sein, außer Sie haben mehrere Identitäten geschickt eingesetzt). Es stellt eine Liste von einem oder mehreren Fingerabdrücken zusammen (wie nachfolgend beschrieben) und versucht, sich mit jedem Schlüssel anzumelden, um zu prüfen, ob einer von ihnen bereits installiert wurde (wenn sie natürlich ssh-agent(1) nicht verwenden, kann dies dazu führen, dass sie wiederholt nach einer Passphrase gefragt werden). Es stellt dann eine Liste derer zusammen, bei denen keine Anmeldung gelang und ermöglicht dann mit ssh(1) Anmeldungen mit diesen Schlüsseln auf den fernen Servern. Standardmäßig fügt es die Schlüssel hinzu, indem es sie an die Datei ~/.ssh/authorized_keys des Benutzers auf dem fernen Rechner anhängt (und dabei, falls notwendig, die Datei und das Verzeichnis erstellt). Es ist auch in der Lage zu erkennen, ob das ferne System ein NetScreen ist, um dann stattdessen seinen Befehl ‘set ssh pka-dsa key …’ zu verwenden.

Folgende Optionen stehen zur Verfügung:

-i Identitätsdatei

Verwendet nur Schlüssel, die in der Identitätsdatei enthalten sind (statt mittels ssh-add(1) oder in der Vorgabekennungsdatei nach Identitäten zu schauen). Falls der Dateiname nicht auf .pub endete, wird diese Endung hinzugefügt. Falls der Dateiname nicht angegeben wird, wird Vorgabekennungsdatei verwandt.

Beachten Sie, dass dies dazu verwandt werden kann, sicherzustellen, dass die kopierten Schlüssel die bevorzugten Kommentare und/oder zusätzlichen Optionen gesetzt haben, indem sichergestellt wird, dass die Schlüsseldatei diese wie gewünscht gesetzt hat, bevor das Kopieren versucht wird.

-f

Zwangsmodus: Überprüft nicht, ob die Schlüssel auf dem fernen Server vorhanden sind. Dies bedeutet, dass es nicht den privaten Schlüssel benötigt. Natürlich kann dies dazu führen, dass auf dem fernen System mehr als eine Kopie des Schlüssels installiert wird.

-n

Führt einen Probleauf aus. Statt Schlüssel auf dem fernen System zu installieren, werden lediglich der oder die Schlüssel ausgegeben, die installiert würden.

-s

SFTP-Modus: normalerweise werden die öffentlichen Schlüssel installiert, indem auf der fernen Seite Befehle ausgeführt werden. Mit dieser Option wird die Datei ~/.ssh/authorized_keys des Benutzers heruntergeladen, lokal verändert, und mit Sftp hochgeladen. Diese Option ist nützlich, falls auf dem fernen Server die ausführbaren Befehle eingeschränkt sind.

-t Zielpfad

Der Pfad auf dem Zielsystem, zu dem die Schlüssel hinzugefügt werden sollen (standardmäßig ».ssh/authorized_keys«)

-p Port, -o SSH-Option

Diese zwei Optionen werden einfach unverändert zusammen mit ihren Argumenten durchgereicht. Sie erlauben das Setzen des Ports bzw. anderer Optionen von ssh(1).

Statt diese als Befehlszeilenoptionen anzugeben, ist es oft besser, (rechnerbezogene) Einstellungen in der Konfigurationsdatei von ssh(1) zu verwenden: ssh_config(5).

-x

Diese Option ist für die Fehlersuche im Skript ssh-copy-id selbst. Sie setzt den Schalter »-x« der Shell selbst, so dass Sie die ausgeführten Befehle sehen werden.

-h, -?

Gibt eine Benutzungszusammenfassung aus.

Ohne -i wird standardmäßig geprüft, ob ‘ssh-add -L’ eine Ausgabe erzeugt. Ist dies der Fall, dann werden diese Schlüssel verwandt. Beachten Sie, dass dieses dazu führt, dass der Kommentar des Schlüssel der Dateiname ist, der an ssh-add(1) übergeben wurde, als der Schlüssel in Ihren ssh-agent(1) geladen wurde, statt der Kommentar, der in dieser Datei enthalten ist, was sehr unschön ist. Andernfalls werden die Inhalte in Vorgabekennungsdatei verwandt, falls ssh-add(1) keine Schlüssel bereitstellt.

Die Vorgabekennungsdatei ist die neuste Datei, die auf folgende passt: ~/.ssh/id*.pub (allerdings ausschließlich solchen, die auf ~/.ssh/*-cert.pub passen). Falls Sie also einen Schlüssel erstellen, der nicht der ist, den Sie ssh-copy-id verwenden lassen wollen, setzen Sie einfach touch(1) auf der .pub -Datei Ihres bevorzugten Schlüssels ein, um diesen wieder als den neusten einzustellen.

BEISPIELE

Falls Sie bereits Schlüssel von einem System auf einer Reihe von fernen Rechnern installiert haben und Sie dann einen neuen Schlüssel auf einer neuen Client-Maschine erstellen, kann es schwierig sein, nachzuverfolgen, auf welchen Systemen Sie den neuen Schlüssel installiert haben. Eine Möglichkeit, damit umzugehen, besteht im Laden des alten und des oder der neuen Schlüssel in Ihren ssh-agent(1). Laden Sie zuerst den neuen Schlüssel, ohne die Option -c, und laden Sie dann einen oder mehrere alte Schlüssel in den Vermittler, möglicherweise indem Sie sich mit Ssh in die Client-Maschine anmelden, die den alten Schlüssel hat, mittels der Option -A, um die Weiterleitung des Vermittlers zu erlauben:

Falls jetzt der neue Schlüssel auf dem Server installiert ist, können Sie sich ohne Passwortabfrage anmelden. Falls aber nur die alten Schlüssel aktiviert sind, werden Sie um Bestätigung gebeten. Dies ist der Hinweis, sich wieder abzumelden und Folgendes auszuführen:

Der Grund für die Angabe der Option -i für diesen Fall liegt darin, sicherzustellen, dass der Kommentar bei dem installierten Schlüssel der aus der .pub -Datei ist und nicht nur der Dateiname, der in Ihren Vermittler geladen wurde. Sie stellt auch sicher, dass nur die beabsichtigten Kennungen installiert werden, statt alle Schlüssel, die sich in Ihrem ssh-agent(1) befinden. Natürlich können Sie eine andere Kennung angeben oder den Inhalt von ssh-agent(1) verwenden, ganz wie Sie möchten.

Sie könnten in Betracht ziehen, die Option -c von ssh-add(1) zu verwenden, immer wenn Sie die Weiterleitung des Vermittlers verwenden, um das Entführen Ihrer Schlüssel zu vermeiden. Allerdings ist es viel besser, stattdessen die Optionen ProxyCommand und -W von ssh-add(1) zu verwenden, um durch ferne Rechner zu springen, aber immer direkte Ende-zu-Ende-Authentifzierung durchzuführen. Auf diese Weise erhalten die zwischenliegenden Systeme keinen Zugriff auf Ihren ssh-agent(1). Eine Websuche nach ‘ssh proxycommand nc’ sollte dazu erhellend wirken (Nebenmerkung: Der modernere Ansatz ist die Verwendung der Option -W statt nc(1)).

SIEHE AUCH

ssh(1), ssh-agent(1), sshd(8)

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org