table of contents
- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
SSH-COPY-ID(1) | General Commands Manual | SSH-COPY-ID(1) |
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, wirdVorgabekennungsdatei
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:
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¶
Ü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
$Mdocdate: 17. Juni 2010 $ | Debian |