Kopiere ich die Schlüsseldateien aus dem .ssh-Verzeichnis auf meinen Laptop, klappt die Verbindung nicht mehr: Permission denied (publickey) Liegt das am Fingerprinting? Oder welchen Denkfehler habe ich damit?

Hm. Das ist zu wenig um es zu wissen und die Vermutungen sind zu zahlreich... und der ssh-Client sowie der ssh-Server sind z.B. bezüglich der Rechte an Dateien und Verzeichnissen „begründet kleinlich“. Außerdem wäre es möglich, dass Dein Benutzerverzeichnis auf dem Server verschlüsselt ist. (Dann wäre an den unten gezeigten Vorgehen Einiges zu ändern.)

Frage: Ist das Benutzerverzeichnis verschlüsselt?

Aufschlussreiche Hinweise dazu, warum der Verbindungsaufbau nicht klappt liefert übrigens ein

ssh -vv USER@host

Es wohl ist einfacher, den Weg komplett zu zeigen:

ALTERNATIVE 1

1. Serverseitig (als user „USER“)

Anlegen der Schlüsseldateien für einen normalen Benutzer und den root auf dem Server:

~$ mkdir .ssh
~$ chmod 700 .ssh
~$ keygen -t ed25519 # Erzeugen der Schlüssel
[CHAT, Passwort und so weiter]
# Public Key in authorizes_keys schreiben:
~$ cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys 
# Rechte
~$ chmod 600 ~/.ssh/authorized_keys

Mindestens folgende Dateien müssen auf dem Server danach mit folgenden Rechten zur Verfügung stehen („USER“ ist Platzhalter für Benutzer und Gruppe)

USER@server~$ ls -ld ~/.ssh
drwx------ 2 USER USER 4096  7. Mai 2024  ~/.ssh
USER@server~$ ls -l ~/.ssh
...
-rw------- 1 USER USER   272  6. Mai 2024  authorized_keys
-rw------- 1 USER USER   100  6. Mai 2024  id_ed25519.pub
-rw------- 1 USER USER   411  6. Mai 2024  id_ed25519
-rw------- 1 USER USER 10463  6. Mai 2024  known_hosts

Die Datei „known_hosts“ ist eventuell nicht vorhanden, diese Datei enhält die Public-Keys der Rechner (die Rechner haben eigene Schlüsselpaare, um die man sich im einfachen Fall erst mal nicht kümmeren muss) zu welchen Verbindungen aufgebaut wurden - sofern hierbei einmalig der Public-Key des Servers akzeptiert wurde.)

Anhängen des Public-Keys an die authorized_keys des root

USER@server~$ sudo mkdir /root/.ssh
USER@server~$ sudo chmod 700 /root/.ssh
USER@server~$ cat ~/.ssh/id_ed25519.pub | sudo tee -a /root/.ssh/authorized_keys > /dev/null
USER@server~$ sudo chmod 600 /root/.ssh/authorized_keys
USER@server~$ sudo ls -ld /root/.ssh

drwx------ 2 root root 4096  7. Mai 2024  /root/.ssh

USER@server~$ sudo ls -l /root/.ssh

-rw------- 1 root   root    272  7. Mai 2024  authorized_keys

2. Clientseitig, als user „USER“

Anlegen des Verzeichnisses:

# Verzeichnis anlegen und Rechte auf 700:
USER@client~$ mkdir ~/.ssh
USER@client~$ chmod 700 ~/.ssh
# Privaten(!) Schlüssel kopieren und Rechte auf 600:
USER@client~$ cd ~/.ssh
USER@client~/.ssh$ scp USER@server:/home/user/.ssh/id_ed25519 ./
# [Passwort-Chat]

Danach kannst Du die Verbindung zum Server als USER und als root aufbauen

user@client~$ ssh USER@SERVER
...
exit

user@client~$ ssh root@SERVER
...
exit

und, falls das klappt sodann(also falls der Verbindungsaufbau klappt!) auf dem Server in der Datei /etc/sshd_config folgende Zeilen ändern/ergänzen: (Bei RedHat-basierenden Linuxen (Fedora, CentOs, Rocky,...) steht „PermitRootLogin“ der Default allen Ernstes auf „yes“ - das sollte geändert werden)

# PermitRootLogin prohibit-password
PermitRootLogin prohibit-password

#PasswordAuthentication yes
PasswordAuthentication no

Dazu brauchst Du root-Rechte.

Da steht dann drin, welche Schlüssel der Client überhaupt probiert hat und wie der Server reagierte. Nimmt der Client die Schlüssel nicht - oder akzeptiert dert Server diese nicht liegt es oft an den zu großzügigen Rechten. (und an übersehenen Warnungen).

Oder Du hast gedacht, Du brauchst auf dem Client den Public-Key. Tatsächlich braucht man

a) auf dem Server und für jeden Benutzer, dessen Konto man via ssh benutzen will: den public-key (den mit Endung '.pub'), angehängt (tee -a) an die Datei authorized_keys

b) auf dem Client: den privat-key (den OHNE die Endung '.pub'; alle im Ordner .ssh)

ALTERNATIVE 2

Diese Funktioniert nicht (so einfach¹) unter Windows, weil Windows das Programm „ssh-copy-id“ fehlt(¹)**

Man kann die Schlüssel auch auf dem Client erzeugen:

user@client:~$ keygen -t ed25519 # Erzeugen der Schlüssel
[CHAT]

sodann mit ssh-copy-id kopieren - dazu muss die Passwort-Authentifikation noch erlaubt sein:

user@client~$ ssh-copy-id USER@server

nun die Verbindung aufbauen und die Datei an die authorized_keys des root anhängen:

user@client~$ ssh USER@HOST
[Passwort-CHAT, jetzt mit Passwort für den KEY]
user@server~$ sudo mkdir /root/.ssh
user@server~$ sudo chmod 700 /root/.ssh
user@server~$ sudo chown root:root /root/.ssh/*
user@server~$ cat ~/.ssh/id_ed25519.pub | sudo tee -a /root/.ssh/authorized_keys > /dev/null
user@server~$ sudo chmod 600 /root/.ssh/authorized_keys
exit

sodann sollte ...

user@client~$ ssh root@server
[Passwort-CHAT, jetzt mit Passwort für den KEY]
root@server~#

funktionieren.

¹) Freilich gibt es für das fehlende Programm ssh-copy-id einen Workarround:

c:\USER\benutzer\.ssh> ssh USER@server "mkdir ~/.ssh"
c:\USER\benutzer\.ssh> ssh USER@server "chmod 700 ~/.ssh"
c:\USER\benutzer\.ssh> cat id_ed25519.pub | ssh USER@server "tee -a > ~/.ssh/authorized_keys"
c:\USER\benutzer\.ssh> ssh USER@server "chmod 600 ~/.ssh/authorized_keys"