BEZEICHNUNG

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

ÜBERSICHT

     ssh-copy-id [-f] [-n] [-s] [-i [Identitätsdatei]] [-p Port] [-o SSH-Option]
     [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 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.

     -h, -?  Gibt eine Benutzungszusammenfassung aus.

     -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).

     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 .