[Gelöst] Kann kein passwortloses ssh zu einer Debian-VM (KVM) einrichten

[juribel]

Hallo,

auf meinem Debian-Laptop (Bookworm 12.8 mit Xfce) habe ich mit QEMU/KVM eine virtuelle Maschine (ebenfalls Debian, dieselbe Version) eingerichtet. Nach Installation des ssh-Dienstes in der VM kann ich mich vom Host auch an dieser VM per ssh anmelden. Auf dieser VM laufen ausserdem Apache2, PHP und Mariadb, um eine Webseite zu testen. Ich benutze hierfür eine VM, damit ich nicht versehentlich meinen Host kaputt konfiguriere. Es klappt auch alles soweit.

Jetzt versuche ich, passwortloses ssh einzurichten. Dafür habe ich auf dem Host die einschlägigen Befehle keygen und ssh-copy-id eingesetzt, mit dem Erfolg, dass auf dem Host und in der VM alle notwendigen Dateien mit den erforderlichen Rechten erstellt wurden, aber ich werde immer noch zur Eingabe des Passworts aufgefordert, auch nach reboot der VM.

Mit demselben Verfahren habe ich bereits passwortloses ssh zu einem anderen Laptop eingerichtet, das funktioniert auch. Übersehe ich irgend etwas, gibt es bei ssh zu virtuellen Maschinen irgendwelche Besonderheiten?

Bin für jeden Hinweis dankbar.

[heisenberg]

Das sind eigentlich immer wieder typischen gleichen Sachen wie "Zugriffsrechte/Eigentümer von manchen Dateien/Verzeichnissen passen nicht (auf dem Client oder dem Server oder beidem)", "Inkompatibilität von irgendwelchen Verschlüsselungsalgorithmen,", "Schlüssel kaputt in die authorized_keys eingetragen", ...

Lass mal ein Terminal auf dem Server (=der VM) auf mit einem journalctl -u ssh --follow --no-pager und beobachte, was passiert, wenn Du Dich per SSH einloggen möchtest. Da sollte dann schon eine Fehlermeldung zu sehen sein.

[MSfree]

Übersehe ich irgend etwas

Ja.

gibt es bei ssh zu virtuellen Maschinen irgendwelche Besonderheiten?

Nein.

Führ mal

Code: Alles auswählen

ssh -vvv benutzer@vmhost

aus, damit du mehr Fehlermeldungen siehst. Ich würde aber mal darauf tippen, daß das Verzeichnis ~/.ssh zu freizügige Berechtigungen hat, bzw. die Dateien unter ~/.ssh zu offen sind.

[juribel]

Oh... ihr seid ja schneller als der Schall, danke

Das Verzeichnis ~/.ssh hat die Berechtigungen 700, das müsste eigentlich OK sein.

journalctl zeigt nichts an, bzw. erst, nachdem ich das Passwort eingegeben habe ("Accepted password...")

ssh -vv hatte ich schon mal gemacht, da kommen irrsinnig viele Meldungen, die ich nicht verstehe bzw. die so aussehen, als würden verschiedene Verfahren ausprobiert, die alle fehlschlagen, bis dann die Aufforderung zur Passworteingabe kommt.

Bei ssh -vvv kommt nach vielen Ausgaben die Meldung

Code: Alles auswählen

ED25519 key fingerprint is SHA256:jfprl/K/He/dUNL19CsU722aZylhDT/XxrmWGK2K5qY.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?.

[heisenberg]

Stelle mal den Output von ssh -vvv und die Ausgabe von journalctl vom Server mit sshd_config-Einstellung "LogLevel DEBUG" hier ins nopaste. Das müsste reichen, um das zu diagnostizieren.

Das Verzeichnis ~/.ssh hat die Berechtigungen 700, das müsste eigentlich OK sein.

Ok. Das ist das Verzeichnis auf dem Client. Wie sieht's aus mit dem Verzeichnis auf dem Server? Wie sieht's aus mit den Dateien im Verzeichnis .ssh ? Auf Client und Server? Passen Eigentümer und Gruppe? Wie sind Rechte, Eigentümer und Gruppe im jeweiligen Home-Verzeichnis?

[juribel]

Kann sein, dass ich das heute nicht mehr hinbekomme.

Aber (nur um das klarzustellen): in diesem Fall spreche ich lieber von Host und Gast. Der Host ist sozusagen mein "Haupt-Debian". Der Gast ist die Virtuelle Maschine, in der Debian mit dem Apache-Server läuft.

In meinem vorigen Post habe ich von dem .ssh-Verzeichnis in der Gast-VM gesprochen, die ich vom Host aus mit ssh erreichen möchte.

Das .ssh-Verzeichnis auf dem Host hat die Berechtigungen 755. Das sollte in Ordnung sein, da ich meinen zweiten Laptop damit ohne Passwort ansprechen kann. Das lokale .ssh-Verzeichnis auf dem zweiten Laptop hat übrigens auch 755, was mich jetzt wundert und vielleicht zuviel des Guten ist. Das wurde aber automatisch eingerichtet.

Gerade habe ich in der Gast-VM auch mal 755 eingestellt und sshd neu gestartet, aber wie vermutet hat dies keine positive Wirkung, passwortloses ssh funktioniert auch damit nicht. Also natürlich wieder rückgängig gemacht.

Alle Klarheiten beseitigt?

[heisenberg]

Eine Befehlsausgabe sagt mehr als 1000 Worte und 100 Forenaugen sehen mehr als zwei. Also auch bzgl. der Rechte vielleicht nochmal eine ls - Ausgabe von Gast und Host wie das:

Code: Alles auswählen

$ cd $HOME
$ ls -ld . .ssh .ssh/*
drwxr-xr-x 28 rumpelstilzchen rumpelstilzchen   4096 Oct 16 15:57 .
drwx------  2 rumpelstilzchen rumpelstilzchen   4096 May 21 14:25 .ssh
-rw-rw-r--  1 rumpelstilzchen rumpelstilzchen   2696 Mar  6  2024 .ssh/authorized_keys
-rw-rw-r--  1 rumpelstilzchen rumpelstilzchen   9393 Dec 10  2022 .ssh/config
-rw-------  1 rumpelstilzchen rumpelstilzchen    883 Jul 11  2012 .ssh/id_rsa
-rw-r--r--  1 rumpelstilzchen rumpelstilzchen    223 Jan 29  2016 .ssh/id_rsa.pub
-rw-------  1 rumpelstilzchen rumpelstilzchen 680448 Aug 20 10:05 .ssh/known_hosts

[juribel]

Heute ist es mir zu spät. Morgen werde ich alles rückgängig machen und ssh komplett neu aufsetzen. Ist vielleicht erst einmal der sauberste Weg.

Aber die ls -l Ausgaben krieg ich noch hin

Auf dem Host:

Code: Alles auswählen

$>ls -al ~/ | grep .ssh
drwxr-xr-x   2 juergen juergen     4096 11. Nov 22:56 .ssh

$>ls -l ~/.ssh
insgesamt 36
-rw------- 1 juergen juergen  583 16. Feb 2023  authorized_keys
-rw------- 1 juergen juergen 2622 16. Feb 2023  id_rsa
-rw-r--r-- 1 juergen juergen  582 16. Feb 2023  id_rsa.pub
-rw------- 1 juergen juergen 2622 11. Nov 22:56 id_rsa_virtualCope
-rw-r--r-- 1 juergen juergen  582 11. Nov 22:56 id_rsa_virtualCope.pub
-rw------- 1 juergen juergen 6142 11. Nov 22:50 known_hosts
-rw------- 1 juergen juergen 5306 11. Nov 22:50 known_hosts.old

Datei ist "id_rsa" für meinen zweiten Laptop zuständig, mit dem die passwortlose Verbindung funktioniert. "id_rsa_virtualCope" bezieht sich auf die Gast-VM, die die passwortlose Verbindung nicht akzeptiert.

Auf dem Gast:

Code: Alles auswählen

juergen@virtualCope:~$ ls -al ~/ | grep .ssh
drwx------  2 juergen juergen  4096 11. Nov 22:56 .ssh

juergen@virtualCope:~$ ls -l ~/.ssh
total 4
-rw------- 1 juergen juergen 582 11. Nov 22:56 authorized_keys

Bis dahin erstmal Danke!

[mat6937]

Auf dem Gast:

Code: Alles auswählen

juergen@virtualCope:~$ ls -al ~/ | grep .ssh
drwx------  2 juergen juergen  4096 11. Nov 22:56 .ssh

Das ist ok so (d. h. 700 beim sshd-Server). Wenn Du dich nicht aussperrst, dann versuch mal in der config vom sshd-Server (Gast) mit:

Code: Alles auswählen

AuthenticationMethods publickey
PubkeyAuthentication yes
PasswordAuthentication no

und in der config vom ssh-Client (Host) oder via Kommandozeile, mit:

Code: Alles auswählen

PubkeyAuthentication yes
PreferredAuthentications publickey
PasswordAuthentication no
IdentityFile ~/.ssh/<private-key>

(private-key anpassen und ohne spitze Klammern).

[MSfree]

Das .ssh-Verzeichnis auf dem Host hat die Berechtigungen 755. Das sollte in Ordnung sein

Die Schlüsseldateien dürfen aber nur für den einen Benutzer lesbar sein. Die müssen also 400 haben, 600 ist auch erlaubt, dann sind sie les- und beschreibbar. 700 ist Blödsinn für normale Dateien, die brauchen kein Ausführbarkeitsrecht.

Das gilt übrigens für Host und Gast.

da ich meinen zweiten Laptop damit ohne Passwort ansprechen kann.

Das sind die Schlüsseldateien vermutlich korrekt geschützt.

Dennoch sollte das .ssh-Verzeichnis nur für den Benutzer lesbar und betretbar sind, also 700 haben, und zwar auf Host und Gast.

[juribel]

Hallo, moin, und danke für die Antworten.

@MSfree: du hast sicherlich Recht, und ich werde die Dateiberechtigungen auch korrigieren, aber zuviele Rechte sollten eigentlich nicht verhindern, dass ich mich überhaupt einloggen kann, im Gegenteil.

@mat6937: In der VM habe ich die sshd-Konfigdatei kontrolliert und ergänzt. Fortschritt oder Rückschritt: jetzt resultiert ein Anmeldeversuch mit ssh in der Fehlermeldung "Permission denied (publickey)". Mein nächster Schritt wäre jetzt, die Schlüsseldateien zu überprüfen. Vielleicht geht es jetzt ja doch etwas voran.

[mat6937]

...: jetzt resultiert ein Anmeldeversuch mit ssh in der Fehlermeldung "Permission denied (publickey)". Mein nächster Schritt wäre jetzt, die Schlüsseldateien zu überprüfen. Vielleicht geht es jetzt ja doch etwas voran.

Hast du dem ssh-client auch gesagt, er soll nur pubkey-authentication und mit welchem key, benutzen?

[MSfree]

aber zuviele Rechte sollten eigentlich nicht verhindern, dass ich mich überhaupt einloggen kann, im Gegenteil.

Du irrst.

SSH verweigert das Login, wenn die Dateirechte zu freizuegig gesetzt wurden. SSH geht dann naemlich von einer kompromitierten Datei aus und laesst dich nicht rein.

[heisenberg]

SSH verweigert das Login, wenn die Dateirechte zu freizuegig gesetzt wurden. SSH geht dann naemlich von einer kompromitierten Datei aus und laesst dich nicht rein.

Und deswegen habe ich auch nach dem Home-Verzeichnis gefragt, was bei Deinen (@juribel) Ausgaben noch fehlt. Das wird nämlich bei StrictModes YES - was per Vorgabe aktiviert ist - auch geprüft. Allerdings würde ich die Wahrscheinlichkeit als gering ansehen, dass das Homeverzeichnis mit Schreibberechtigung für o (other) gesetzt ist.

Aber das wichtigere sind die oben angeforderten Debugging-Ausgaben, die Du noch nicht geliefert hast.

[juribel]

Hallo zusammen,

ich hab jetzt nochmal neu aufgesetzt, d. h. in der VM den ssh-Server und die zugehörigen Dateien entfernt. Neu installiert. Auf dem Host (dem ssh-Client) den vorigen Schlüssel mit "ssh-keygen -f..." entfernt, mit "ssh-keygen" einen neuen erstellt und mit "ssh-copy-id -f -i ~/.ssh/id_rsa_virtualCope.pub virtualCope.local" auf den ssh-Server in der VM übertragen.

Alles ohne Erfolg. Es wird immer noch ein Passwort verlangt. Ich weiss jetzt nicht mehr weiter und poste nun doch mal die längliche Ausgabe von "ssh -vv ...". Mir fällt dabei auf, dass offensichtlich einige Dateien auf Existenz abgefragt werden, z. B. die Datei .ssh/id_rsa. Die neu angelegte Schlüsseldatei für diesen ssh-Server (id_rsa_virtualCope) wird aber gar nicht abgefragt. Kurz bevor das Passwort verlangt wird, scheint es mir, als würde die Datei id_rsa zur Authentifizierung herangezogen. Das ist aber die für meinen zweiten Laptop gültige Datei.

Code: Alles auswählen

juergen@juergen-thinkpad-p50:/media/juergen/intern2/ISO-Images/Linux/Debian
$>ssh -vv virtualCope.local
OpenSSH_9.2p1 Debian-2+deb12u3, OpenSSL 3.0.15 3 Sep 2024
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "virtualcope.local" port 22
debug1: Connecting to virtualcope.local [192.168.122.16] port 22.
debug1: Connection established.
debug1: identity file /home/juergen/.ssh/id_rsa type 0
debug1: identity file /home/juergen/.ssh/id_rsa-cert type -1
debug1: identity file /home/juergen/.ssh/id_ecdsa type -1
debug1: identity file /home/juergen/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/juergen/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/juergen/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/juergen/.ssh/id_ed25519 type -1
debug1: identity file /home/juergen/.ssh/id_ed25519-cert type -1
debug1: identity file /home/juergen/.ssh/id_ed25519_sk type -1
debug1: identity file /home/juergen/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/juergen/.ssh/id_xmss type -1
debug1: identity file /home/juergen/.ssh/id_xmss-cert type -1
debug1: identity file /home/juergen/.ssh/id_dsa type -1
debug1: identity file /home/juergen/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u3
debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u3 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to virtualcope.local:22 as 'juergen'
debug1: load_hostkeys: fopen /home/juergen/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-v00@openssh.com
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,kex-strict-s-v00@openssh.com
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:m/+SwYTchNYdT5vQVvXEamsR7yqlO/ECxCb8/974kiE
debug1: load_hostkeys: fopen /home/juergen/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'virtualcope.local' is known and matches the ED25519 host key.
debug1: Found key in /home/juergen/.ssh/known_hosts:19
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug2: ssh_set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug2: ssh_set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /home/juergen/.ssh/id_rsa RSA SHA256:xJehd/973EYBcpzIpP0bUeWcznnz6yEJvX6P9+99/HI
debug1: Will attempt key: /home/juergen/.ssh/id_ecdsa 
debug1: Will attempt key: /home/juergen/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/juergen/.ssh/id_ed25519 
debug1: Will attempt key: /home/juergen/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/juergen/.ssh/id_xmss 
debug1: Will attempt key: /home/juergen/.ssh/id_dsa 
debug2: pubkey_prepare: done
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com=<0>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/juergen/.ssh/id_rsa RSA SHA256:xJehd/973EYBcpzIpP0bUeWcznnz6yEJvX6P9+99/HI
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/juergen/.ssh/id_ecdsa
debug1: Trying private key: /home/juergen/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/juergen/.ssh/id_ed25519
debug1: Trying private key: /home/juergen/.ssh/id_ed25519_sk
debug1: Trying private key: /home/juergen/.ssh/id_xmss
debug1: Trying private key: /home/juergen/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
juergen@virtualcope.local's password: 

[mat6937]

... Das ist aber die für meinen zweiten Laptop gültige Datei.

Warum versuchst Du nicht mit:

Code: Alles auswählen

IdentityFile ~/.ssh/<private-key>

& Co., dem ssh-Client zu sagen was er wie benutzen soll?

[heisenberg]

Mir fällt dabei auf, dass offensichtlich einige Dateien auf Existenz abgefragt werden, z. B. die Datei .ssh/id_rsa. Die neu angelegte Schlüsseldatei für diesen ssh-Server (id_rsa_virtualCope) wird aber gar nicht abgefragt.

Die Keys, die geprüft werden sind die Standard-Dateinamen. Wenn Du einen anderen Dateinamen verwendest, musst Du den bei dem SSH-Kommando oder in der Konfigurationsdatei ($HOME/.ssh/config) angeben.

[juribel]

Danke ihr beiden! Das waren die entscheidenden Tipps, diese config-Datei kannte ich bis jetzt noch nicht, und dass man da die vom Standard abweichenden Dateien eintragen kann.

"Bin drin!"

Ich musste diese Datei anlegen und für jede meiner beiden ssh-Gegenstellen einen Eintrag vornehmen, bestehend aus dem ssh-Hostnamen und dem Dateinamen. Ausserdem musste ich für meinen Zweit-Laptop einen neuen Schlüssel generieren.

Jetzt kann ich mich auf dem Zweit-Laptop wieder und jetzt auch an der virtuellen Maschine ohne Passwort anmelden.

Danke für eure Geduld!