SSH ohne Passwort mit nicht standardmäßiger Position der Identitätsdatei

16

Als Teil eines Startskripts muss ich automatisch mehrere Gnome-Terminal-Fenster öffnen, von denen eines automatisch sendet:

ssh user@192.168.1.3

Die Einschränkung dabei ist, dass ich noch ein Passwort eingeben muss, um die SSH-Verbindung herzustellen.

Ich möchte, dass mein Skript den Befehl initiiert und die Verbindung herstellt. Insofern habe ich versucht , die Anweisungen zu befolgen , wie in der akzeptierte Antwort skizziert hier .

Von dem System, von dem aus ich eine Verbindung herstellen möchte, lief ich:

ssh-keygen
Enter file in which to save the key: /home/user/ssh/keys/server1key

Anschließend wurde ich aufgefordert, eine Passphrase einzugeben. Ich ließ dieses Feld leer, da ich mir nicht sicher war, wofür es sein würde, und nahm an, dass für die Einstellung eines Felds bei jeder Verwendung dieses Felds das Entsperren des Felds mit der angegebenen Passphrase erforderlich ist.

In Fortsetzung der oben verlinkten Anweisungen lief ich dann und erhielt die folgenden:

ssh-copy-id user@IP
ERROR: No identities found

Eine Schnellsuche ergab, dass ich den Speicherort des Schlüssels angeben musste, da er sich nicht am Standardspeicherort befand. Daher habe ich Folgendes behoben:

ssh-copy-id -i /home/user/ssh/keys/server1key.pub user@192.168.1.3

Nachdem Sie nach dem Kennwort des Servers gefragt wurden, wurde der Schlüssel erfolgreich hinzugefügt. Beim Versuch, mich mit "ssh user @ IP" anzumelden, wurde ich dennoch zur Eingabe des Kennworts aufgefordert.

Soweit mir bekannt ist, habe ich die verknüpften Anweisungen korrekt befolgt, sodass entweder etwas fehlt oder eine vorhandene Konfiguration mich daran hindert, dies zum Laufen zu bringen.

Beide Systeme verwenden 18.04 und openssh.

— Hiigaran
quelle

Muss ich also den Speicherort der PUB-Datei angeben, wenn ich den SSH-Befehl sende?

— Hiigaran

Ich habe eine etwas andere Art, meine Dateien zu organisieren, daher die nicht standardmäßigen Speicherorte, aber ihr habt sehr geholfen. Vielen Dank. Fühlen Sie sich frei, eine Antwort daraus zu machen, die ich akzeptieren kann.

— Hiigaran

35

Es scheitert aus dem gleichen Grund ssh-copy-id fehl, aus dem es beim ersten Mal fehlgeschlagen ist, dh, Sie haben einen nicht standardmäßigen Speicherort für die Identitätsdatei ausgewählt.

Sie können es auf die gleiche Weise beheben, indem Sie -i /home/user/ssh/keys/server1keyIhrem sshBefehl Folgendes hinzufügen : Beachten Sie, dass die Clientseite den Speicherort der privaten Schlüsseldatei benötigt.

Von man ssh

 -i identity_file
         Selects a file from which the identity (private key) for public
         key authentication is read.  The default is ~/.ssh/identity for
         protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
         ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2.

Alternativ können Sie einen ~/.ssh/configDateieintrag für den Host nach dem Muster von erstellen

Host            somename
Hostname        192.168.1.3
User            user
IdentityFile    /home/user/ssh/keys/server1key

— Stahlfahrer
quelle

1

Ich bin immer davon ausgegangen, dass die Konfigurationsdatei Einrückungen erfordert - ich sehe, dass dies nicht der Fall ist. Eindringlich.

— Boris die Spinne

Jeder, der OpenSSH verwendet, sollte ein haben ~/.ssh/config, ansonsten verwendet OpenSSH den systemweiten Standard /etc/ssh/ssh_config. Für den Fall, dass jemand es hilfreich findet, habe ich vor einiger Zeit eine vorgefertigte ssh_config auf meinen GitHub hochgeladen, als Ausgangspunkt für Benutzer, die möglicherweise keine Zeit haben, die ssh_config-Manpage

— JW0914

@ JW0914 Das ist nur zur Hälfte wahr: Einzelne Werte in ~/.ssh/configüberschreiben die globalen Werte ssh_config, aber nur die Datei deaktiviert die systemweite Konfiguration nicht.

— Sebastian Stark

@SebastianStark Vielleicht haben Sie meinen Kommentar falsch gelesen, da ich nie angegeben habe, dass dies die systemweite Konfiguration deaktivieren würde. Was ich angegeben habe, war zu 100% sachlich korrekt.

— JW0914

2

Ein weiterer Grund dafür ssh-copy-id fehlschlägt, ist, dass der Schlüssel nicht zum SSH-Agenten hinzugefügt wurde.

Überprüfen Sie zuerst und starten Sie, ob ausgeführt ssh-agentwird:

eval "$(ssh-agent -s)"

Wenn Sie eine Prozess-ID erhalten, können Sie Ihren Schlüssel hinzufügen:

ssh-add -k /home/user/ssh/keys/server1key

Mit -k fügen Sie den Schlüssel zum Schlüsselbund hinzu.

Überprüfen Sie, ob Schlüssel hinzugefügt wurden mit:

ssh-add -l

ssh-copy-id sollte jetzt arbeiten.

— Martijn
quelle

-1

Ich hoffe, das funktioniert für Sie. "Sshpass -p yourpassword" wird sich automatisch beim Remote-Host anmelden.

[root @ localhost .ssh] # sshpass -p password123 ssh -l root localhost

— JackyChan
quelle

-1

Führen Sie einfach 2 Befehle aus:

ssh-keygen
ssh-copy-id

Lange Antwort:

user@ip:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): temp_file
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in stemp.
Your public key has been saved in stemp.pub.
The key fingerprint is:
SHA256:5**M user@ip
The key's randomart image is:
+---[RSA 2048]----+
|  ...            |
| ...             |
| ..              |
| ..+.    o .     |
|                 |
|    B            |
|                 |
|=      *         |
|=+   o .         |
+----[SHA256]-----+

Und dann:

user@ip:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub ipDestination -p portDest

— Mohsen Abasi
quelle