Provided by: manpages-de_4.21.0-2_all 
BEZEICHNUNG
ssh-copy-id — lokal verfügbare Schlüssel zur Autorisierung von Anmeldungen an fernen Maschinen verwenden
ÜBERSICHT
[-f] [-n] [-s] [-x] [-i [Identitätsdatei]] [-p Port] [-o SSH-Option] [-t Zielpfad] [Benutzer@]Rechnername
-h | -?
BESCHREIBUNG
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 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 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:
Benutzer@NeuerClient$ ssh-add
Benutzer@NeuerClient$ ssh -A alter.Client
Benutzer@alter$ ssh-add -c
Keine … Abfrage für Passphrase …
Benutzer@alter$ logoff
Benutzer@NeuerClient$ ssh Irgendeinserver
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:
Benutzer@NeuerClient$ ssh-copy-id -i Irgendeinserver
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:
https://www.gnu.org/licenses/gpl-3.0.html 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 .
Debian 17. Juni, 2010 SSH-COPY-ID(1)