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

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:

             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)