Passwortlos per ssh auf den Server zugreifen

Server
1

Hallo,

ich versuche gerade einen passwortlosen Zugriff auf den lmn7-Server einzurichten.

Dazu habe ich auf dem Server ein user backupuser angelegt. dieser hat in seinem Heimatverzeichnis den Ordner .ssh und darin die Datei authorized_keys Die Rechte sind richtig:

-rw------- 1 backupuser backupuser  179 Aug 27 22:08 authorized_keys
drwx------ 2 backupuser backupuser 4096 Aug 27 22:08 .
drwxr--r-- 6 backupuser backupuser 4096 Aug 27 20:13 ..

Auf dem Rechner, der auf dem lmn-Server zugreifen soll, habe ich
ssh-keygen -t rsa
ausgeführt (keine Passphrase) und den öffentlichen Schlüssel rüber kopiert

 cat /share/homes/admin/.ssh/id_ecdsa.pub | ssh  backupuser@10.16.1.1 'cat >> .ssh/authorized_keys'

Danach werde ich aber immer noch nach dem Passwort gefrag.

Starte ich den ssh-Server auf dem lmn7 im debugmode erhalte ich

trying public key file /home/backupuser/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: trying public key file /home/backupuser/.ssh/authorized_keys2
debug1: Could not open authorized keys '/home/backupuser/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for backupuser from 10.16.1.5 port 42950 ssh2: RSA SHA256:UMqLEhj1o/Dmg2+62Kt/DYyo5eXPRpke3Yg4xBw04SE

Der Client wirft im debugmode folgendes aus

debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Interessant ist, dass ich dasselbe Vorgehen schon mit einem debian-Server gemacht habe, und da klappt es. Gibt es irgendeine Besonderheit bei Ubuntu oder lmn7 Server?

Vielen Dank, Martin

2

Hallo Martin,

Das ist das Problem : die Datei sollte im Home des Users backupuser liegen.
Lieber :

cat >> /home/backupuser/.ssh/authorized_keys2

Am bestens eher ssh-copy-id verwenden :

ssh-copy-id -i ~/.ssh/KEY.pub user@host

Gruß

Arnaud

3

Da liegt sie ja, der Pfad ist doch relativ zum Home-Verzeichnis des backupusers, der für ssh-Verbindung zum Übertragen des Schlüssels verwendet wird

cat /share/homes/admin/.ssh/id_ecdsa.pub | ssh  backupuser@10.16.1.1 'cat >> .ssh/authorized_keys'
4

Ok, ich verwende in diesem Fall immer absolute Pfade da ich schon schlechte Erfahrungen hatte, aber anscheinend ist se nicht das Problem.

Auf dem Client steht es /root/.ssh/id_ecdsa in den Log, aber anscheinend war der Schlüssel aus dem Pfad /share/homes/admin/.ssh/id_ecdsa.pub, kann es sein, dass diese beide id_ecdsa unterschied sind ?

Ich meine : wenn ich ssh als admin ausführe, sucht ssh den Schlüssel in /home/admin/.ssh, und es kann sein, dass /root/.ssh/id_ecdsa und /home/admin/.ssh/id_ecdsa anders sind.

Gruß

Arnaud

5

Hallo Martin,

das sieht nicht gut aus:

‚/home/backupuser/.ssh/authorized_keys2‘: No such file or directory

Hast Du denn mal auf dem Server nachgesehen, ob im Homeverzeichnis des backupusers (wie ist da der Pfad?) die Datei existiert?

Beste Grüße

Jörg

6

Auch das ist nicht schlimm, da der öffentliche Schlüssel ja in /home/backupuser/.ssh/authorized_keys steht, die hat er gefunden, konnte aber nichts damit anfangen.

Das Problem war ein anderes: Der Zugriff erfolgt von eine QNAP, auf der bei uns die Backups liegen. Dort war ich auf der Konsole als „admin“ eingeloggt und habe das Schlüsselpaar erzeugt, dass dann unter /share/homes/admin/.ssh/id_ecdsa.pub liegt. Für den Abgleich beim Aufbau der ssh-Verbindung wird dann allerdings /root/.ssh/id_ecdsa verwendet. Der dazu gehörende öffentliche Schlüssel musste dann auf den Server /root/.ssh/id_ecdsa.pub