SSH-Problem (vom Pi auf Server)

NextcloudPi auf Raspberry, V 1.36.3

Szenario:

Die Daten von meinem Nextcloudpi sollen auf meinem Backupserver (192.168.2.100) per rsyc gesichert werden. Das ganze möchte mich mittels ssh und einem passwortfreiem Schlüssellogin ermöglichen.

Problem: Der ssh-login klappt nicht, ich werde nach einem PW gefragt.

Was ich gemacht habe:

  1. Testen, ob der SSH-Login grundsätzlich vom pi aus mit dem sync-User (syncer) funktioniert:

    pi@nextcloudpi:~$ ssh -l syncer 192.168.2.100
    syncer@server’s password: *******
    syncer@server:~$ exit
    pi@nextcloudpi:~$

Hat funktioniert!

  1. Auf dem Pi ein Passwortfreies Schlüsselpaar erstellen:

    pi@nextcloudpi:~$ cd .ssh
    pi@nextcloudpi:.ssh$ ssh-keygen -t rsa -f syncer.identity
    Generating public/private rsa key pair.
    Enter passphrase (empty for no passphrase): hier wurde KEIN PW eingeben, nur mit Return bestätigt
    Enter same passphrase again:
    Your identification has been saved in syncer.identity.
    Your public key has been saved in syncer.identity.pub.

  2. Public-Key auf server übertragen:

    pi@nextcloudpi:~$ scp syncer.identity.pub syncer@192.168.2.100:~
    pi@nextcloudpi:~$ ssh -l syncer 192.168.2.100

  3. … und diesen Schlüssel an die Datei ~/.ssh/authorized_keys anhängen:

    syncer@server:~$ ! [ -e .ssh ] && mkdir .ssh
    syncer@server:~$ chmod 700 .ssh
    syncer@server:~$ cat syncer.identity.pub >> .ssh/authorized_keys
    syncer@server:~$ chmod 600 .ssh/authorized_keys
    syncer@server:~$ exit

  4. Passwort-freien Login testen:

pi@nextcloudpi:~$ ssh syncer@192.168.2.100

… und ab hier läufts nicht mehr wie erwartet: Ich werde aufgefordert, das PW einzugeben.

Ich hab das genau so mit drei Clients schon gemacht (auf dem gleichen Server) - das hat überall geklappt, nur die Nectcloud macht Probleme.

Hier die Ausgabe von ssh -v syncer@192.168.2.100

OpenSSH_7.9p1 Raspbian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.2.100 [192.168.2.100] port 22.
debug1: Connection established.
debug1: identity file /home/pi/.ssh/id_rsa type -1
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: identity file /home/pi/.ssh/id_dsa type -1
debug1: identity file /home/pi/.ssh/id_dsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa type -1
debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519 type -1
debug1: identity file /home/pi/.ssh/id_ed25519-cert type -1
debug1: identity file /home/pi/.ssh/id_xmss type -1
debug1: identity file /home/pi/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.2.100:22 as 'syncer'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
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: Server host key: ecdsa-sha2-nistp256 SHA256:xxx
debug1: Host '192.168.2.100' is known and matches the ECDSA host key.
debug1: Found key in /home/pi/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/pi/.ssh/id_rsa 
debug1: Will attempt key: /home/pi/.ssh/id_dsa 
debug1: Will attempt key: /home/pi/.ssh/id_ecdsa 
debug1: Will attempt key: /home/pi/.ssh/id_ed25519 
debug1: Will attempt key: /home/pi/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pi/.ssh/id_rsa
debug1: Trying private key: /home/pi/.ssh/id_dsa
debug1: Trying private key: /home/pi/.ssh/id_ecdsa
debug1: Trying private key: /home/pi/.ssh/id_ed25519
debug1: Trying private key: /home/pi/.ssh/id_xmss
debug1: Next authentication method: password
syncer@192.168.2.100's password:

Das Problem ist wohl, dass dein Benutzer “pi” nicht den zugehörigen Private-Key verwendet. Die Idee mit den Namen “syncer.identity” war wohl nicht so toll.

Versuche den Public Key mal mit folgenden Befehl auf den Remote Host zu übertragen:

ssh-copy-id -i ~/.ssh/syncer.identity.pub syncer@192.168.2.100

An den Berechtigungen auf dem Remote Host musst du dann imho eigentlich nichts ändern.

Die Berechtigungen auf dem lokalen Host sehen bei mir folgendermasen aus:

chmod 700 ~/.ssh
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts
chmod 644 ~/.ssh/config
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

Hi,

mit dem von dir genannten Befehl klappt es leider auch nicht. Übertragung funktioniert, aber wenn ich mich per SSH verbinde wird wieder nach dem PW gefragt.

Ich hab den pub-Key vom pi mit dem Key in der Datei authorized_keys auf dem Server verglichen - das passt.

Die Berechtigungen des .ssh Verzeichnisses auf dem pi sind wie deine, allerdings fehlt bei mir die config Datei. Brauche ich die?

THX
bronxx

Wie sehen auf dem Server die folgende Optionen in der Datei/etc/ssh/sshd_config aus?

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

Ansonsten fällt mir gearde auch nichts mehr ein…

Nein die ist optional. Du kannst dort aber nette Dinge machen, wenn z.B. sehr viele Server verwalten musst oder mehrer public Keys verwendest usw… Ist für dein Problem hier jetzt aber nicht relevant, ausser vielleicht wenn sie vorhanden wäre…

Hallo nochmal,

sshd_config auf dem Server passt auch.

Ich habs jetzt nach der Anleitung hier gemacht und es funktioniert: http://linuxproblem.org/art_9.html

Unterschied ist eigentlich nur, dass ich dem Schlüssel keinen anderen Namen gegeben habe. Bei drei anderen Clients hat das ohne Probleme geklappt, nur der pi macht hier Mucken.

Anyway, Danke für eure Hilfe.