ssh-copy-id und Duplikate in authorisierten Schlüsseln

6411
Vi.

Ich möchte das Kennwort nur einmal eingeben, wenn ich eine Verbindung zu SSH herstelle. Ich verwende ssh-copy-id und installiere meinen Pubkey in autorisierten Schlüsseln.

Ich verfolge aber nicht, welche Server bereits meinen Schlüssel haben und welche nicht. Deshalb gebe ich manchmal erneut ssh-copy-id aus, wodurch ein duplizierter Schlüssel zu authorisierten Schlüsseln hinzugefügt wird.

  1. Wie kann verhindert werden, dass ssh-copy-id den Schlüssel installiert, wenn er bereits installiert ist?
  2. / * Wie kann die Schlüsselinstallation automatisch und transparent erfolgen, wenn eine Verbindung zu SSH hergestellt wird (ohne explizite ssh-copy-id? * /
3

3 Antworten auf die Frage

2
grawity

Wie kann verhindert werden, dass ssh-copy-id den Schlüssel installiert, wenn er bereits installiert ist?

Schreibe dein eigenes Skript. Sie ssh-copy-idmüssen lediglich eine Zeile an eine Datei anhängen. Folgendes würde prüfen, ob der Schlüssel vorhanden ist:

#!/bin/bash cat ~/.ssh/id_* | ssh "$@" 'mkdir -pm 0700 ~/.ssh && while read -r ktype key comment; do if ! (grep -Fw "$ktype $key" ~/.ssh/authorized_keys | grep -qsvF "^#"); then echo "$ktype $key $comment" >> ~/.ssh/authorized_keys fi done'

Wie kann die Schlüsselinstallation beim Herstellen einer Verbindung mit SSH automatisch und transparent erfolgen (ohne explizite ssh-copy-id?

Das ist nicht möglich, denn wenn der Server noch nicht über Ihren öffentlichen Schlüssel verfügt, weiß er auch nicht, wo er ihn abrufen kann.

"Sie können nicht" -> Ich kann, es ist wie der Versuch, "ssh-copy-id" jedes Mal auszuführen, bevor eine Verbindung hergestellt wird, oder bestimmte Befehle automatisch auszuführen, nachdem die Verbindung hergestellt wurde. Vi. vor 13 Jahren 0
Gut, Sie können `ssh-copy-id` jedes Mal ausführen, bevor Sie eine Verbindung herstellen - aber meiner Meinung nach ist das faul und ineffektiv. (In meiner $ LOCATION kann ein SSH-Handshake gelegentlich bis zu 5 Sekunden dauern. Deshalb mag ich das nicht.) Das einmalige Kopieren des Schlüssels würde ausreichen. Denken Sie daran, es beim ersten Mal zu machen neuer Server (Wenn Sie Dutzende oder Hunderte von Servern verwalten, verwenden Sie die falsche Authentifizierungsmethode.) grawity vor 13 Jahren 0
"Denken Sie daran, es zu tun, wenn Sie sich zum ersten Mal mit einem neuen Server verbinden" -> diese Dinge sollten sich vom Computer "merken", nicht vom Benutzer. Vi. vor 13 Jahren 0
@Vi: Aber nur der Benutzer weiß, ob der Schlüssel _swould_ auf das Remote-System kopiert werden soll (und wenn ja, welchen Schlüssel: Ich habe vier). Außerdem, wo genau der Schlüssel in welchem ​​Format platziert werden soll - OpenSSH hat einen, aber nicht den einzigen (leider ist RFC 4819 nicht sehr verbreitet). grawity vor 13 Jahren 0
@Vi: [Dieser Hack] (http://pastie.org/1736206) funktioniert möglicherweise als `ProxyCommand` in Ihrer SSH-Client-Konfiguration. grawity vor 13 Jahren 0
1
mivk

Um Duplikate zu vermeiden, können Sie Änderungen vornehmen ssh-copy-id.

Ich habe dies mit der ssh-copy-id gemacht, die mit Debians openssh-client verteilt wurde, was für mich Version 1: 6.0p1-4 war. Kurz gesagt, ich habe modifiziert

cat >> ~/.ssh/authorized_keys

zu

t=$(tempfile); cat ~/.ssh/authorized_keys - | sort -u > $t && mv $t ~/.ssh/authorized_keys

Hier ist ein Patch ( diff -c /usr/bin/ssh-copy-id.orig /usr/bin/ssh-copy-id)

*** /usr/bin/ssh-copy-id.orig 2013-02-08 23:18:09.000000000 +0100 --- /usr/bin/ssh-copy-id 2013-12-12 23:14:48.705964476 +0100 *************** *** 41,47 **** # strip any trailing colon host=`echo $1 | sed 's/:$//'`  ! { eval "$GET_ID" ; } | ssh $host "umask 077; test -d ~/.ssh || mkdir ~/.ssh ; cat >> ~/.ssh/authorized_keys && (test -x /sbin/restorecon && /sbin/restorecon ~/.ssh ~/.ssh/authorized_keys >/dev/null 2>&1 || true)" || exit 1  cat <<EOF Now try logging into the machine, with "ssh '$host'", and check in: --- 41,47 ---- # strip any trailing colon host=`echo $1 | sed 's/:$//'`  ! { eval "$GET_ID" ; } | ssh $host 'sh -c "umask 077; mkdir -p ~/.ssh ; t=$(tempfile); cat ~/.ssh/authorized_keys - | sort -u > \$t && mv \$t ~/.ssh/authorized_keys && (test -x /sbin/restorecon && /sbin/restorecon ~/.ssh ~/.ssh/authorized_keys >/dev/null 2>&1 || true)"' || exit 1  cat <<EOF Now try logging into the machine, with "ssh '$host'", and check in:

Was 2 betrifft (machen Sie es automatisch), können Sie nicht, aber wenn Sie ssh-copy-id patchen, um Duplikate zu vermeiden, ist es egal, ob Sie ssh-copy-idzu viel laufen .

-1
Nestor Urquiza

Funktioniert http://thinkinginsoftware.blogspot.com/2012/07/avoid-duplicates-in-authorizedkeys.html für Sie? Grundsätzlich besteht der Trick darin, dass Sie zuerst den Schlüssel hinzufügen und anschließend alle Vorkommen des Schlüssels mit Ausnahme des letzten (Dollar + Ausrufezeichen) löschen:

#! / bin / bash -ex # ssh-copy-id-uniq.sh  Benutzer = $ 1 host = 2 $ publicKey = $ 3 privateKey = 4 $  LOCAL_HOST_NAME = `hostname`  USAGE = "Usage:` basename $ 0` "  wenn [$ # -ne "4"]  dann Echo $ USGE Ausfahrt 1  fi  su $ user -c "ssh-copy-id -i $ publicKey $ user @ $ host" ssh -i $ privateKey $ user @ $ host "sed -i \" \\\ $! {/ $ user @ $ LOCAL_HOST_NAME / d;} \ "~ / .ssh / authorised_keys"
Nützlicher wäre es, wenn Schlüssel auf der Grundlage des Schlüssels selbst entfernt würden, nicht jedoch des Kommentars. Der Kommentar kann für denselben Schlüssel unterschiedlich sein. Bei OTOH gibt es möglicherweise mehrere Schlüssel mit demselben Kommentar, die aufbewahrt werden sollten. blueyed vor 12 Jahren 2
@blueyed: Nicht sicher, was du meinst, aber ich habe ein paar Klarstellungen hinzugefügt, falls der sed-Befehl nicht klar ist. Die Zeile wird nicht aufgrund eines Kommentars entfernt, sondern anhand der Kombination aus Benutzer- und Hostnamen. Es sollten keine anderen Schlüssel für diesen Benutzer und Hostnamen vorhanden sein, denen wir zustimmen würden. Nestor Urquiza vor 12 Jahren 0

Verwandte Probleme