ubuntuusers.de

Ich will mit Back in Time Daten vom PC auf ein NAS von Synology sichern. Auf dem NAS ist für ssh ein spezieller Port definiert.

Ich habe auf dem PC mit ssh-keygen ein public/private ed25519 Schlüsselpaar erstellt und mit ssh-copy-id -i ~/.ssh/id_ed25519.pub USER@IP_DES_NAS auf das NAS kopiert. Der Test mit ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USERR@IP_DES_NAS' war offenbar erfolgreich, ich war auf dem NAS eingeloggt.

Dann habe ich habe Back in Time 1.5.5-1 aus den Paketquellen installiert, Modus SSH, Host (IP_DES_NAS), Port und User eingegeben. Chiffre ist Standard, Privater Schlüssel /home/USER/.ssh/id_ed25519. Die Bereiche Passwort, Erweitert und Zeitplan sowie die übrigen Tabs/Reiter habe ich nicht verändert.

Wenn ich mit OK bestätige, soll ich das Passwort von USER eingeben, um den öffentlichen SSH-Schlüssel zum entfernten Rechner zu kopieren. Warum, er ist doch schon da? Und wenn ich das Passwort eingebe, lande ich in einer Dauerschleife.

Was mache ich falsch?

wired2051 schrieb:

Der Test mit ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USERR@IP_DES_NAS' war offenbar erfolgreich, ich war auf dem NAS eingeloggt.

Teste mal so:

1

ssh -p PORT -o PreferredAuthentications=publickey -o IdentityFile=/home/USER/.ssh/id_ed25519 USERR@IP_DES_NAS echo "Hello"

Fragt bei diesem Test, das Terminal nach einem Passwort oder zeigt es evtl. eine Fehlermeldung?

Danke für Deine Hilfsbereitschaft!

Ich danke, das ist eine Fehlermeldung: Permission denied (publickey,password). Was folgt daraus?

wired2051 schrieb:

..., das ist eine Fehlermeldung: Permission denied (publickey,password). Was folgt daraus?

Schau mal auf dem Server, in der zuständigen Zeile der Datei "~/.ssh/authorized_keys" nach, ob es dort eine Einschränkung gibt.

Die Datei

1

-rwxrwxrwx+ 1 USER users 3952 May 31 18:10 authorized_keys

auf dem NAS (geplantes Ziel des Backups) hat 12 Einträge, alle enden mit USER@RECHNER (geplante Quelle des Backups). 7x beginnend mit ssh-rsa, davon 3x Zeichenkette1 und 4x Zeichenkette2. Und 5x ssh-ed25519 mit Zeichenkette3. Ziemlich viel Redundanz. Soll ich manuell aufräumen? Ansonsten sagt mir das alles nichts.

EDIT:

Die ssh-rsa-Einträge sind verm. älter. Ich konnte mich schon vor Erstellung des neuen ssh-ed25519-Schlüsselpaars problemlos mit ssh -p PORT USER@IP_DES_NAS auf dem NAS einloggen, nur Back in Time konnte das nicht.

wired2051 schrieb:

Soll ich manuell aufräumen?

Nein. EDIT folgt.

EDIT:

Schau mal in der /etc/ssh/sshd_config nach, ob für

1
2
3

ForceCommand
# und für
PermitTTY

die default Vorgaben geändert sind. In der /etc/passwd auf dem Server nachschauen ob für den user evtl. eine Pseudo-Shell (/bin/false oder /usr/sbin/nologin) eingetragen ist. Wenn alles nicht zutrifft, dann temporär und zum testen, die jetzigen Schlüsseldateien mit ed25519 für BackinTime, durch id_rsa-Schlüsseldateien temporär "ersetzen" und damit testen.

EDIT 2:

BTW: Ich verstehe nicht, was Du mit deinem EDIT (oben) sagen willst.

Auf dem Server (NAS) ist in /etc/ssh/sshd_config vieles mit # auskommentiert. Von Interesse könnte sein:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
AllowTcpForwarding no
#PermitTTY yes
ChrootDirectory none
Subsystem       sftp    internal-sftp -f DAEMON -u 000
#   PermitTTY no
#   ForceCommand cvs server
Match User root
    AllowTcpForwarding yes
Match User admin
    AllowTcpForwarding yes
Match User anonymous
    AllowTcpForwarding no
    GatewayPorts no

Auf dem NAS in /etc/passwd gibt es /bin/false und /usr/bin/nologin aber nicht für USER.

Dort steht:

1

USER:x:1026:100:Gruppe administrators:/var/services/homes/USER:/bin/sh

lubux schrieb:

Wenn alles nicht zutrifft, dann temporär und zum testen, die jetzigen Schlüsseldateien mit ed25519 für BackinTime, durch id_rsa-Schlüsseldateien temporär "ersetzen" und damit testen.

Kannst Du mir bitte sagen wie? Mit der Konsole auf dem NAS? In Back in Time? ich habe Angst etwas kaputt zu machen.

lubux schrieb:

BTW: Ich verstehe nicht, was Du mit deinem EDIT (oben) sagen willst.

Ist dann auch nicht wichtig. Mich hat irritiert, dass ich mich in der Konsole mit ssh auf dem NAS einloggen kann, Back in Time es jedoch nicht schafft.

wired2051 schrieb:

Kannst Du mir bitte sagen wie? Mit der Konsole auf dem NAS? In Back in Time? ich habe Angst etwas kaputt zu machen.

Na so wie Du das id_ed25519-Schlüsselpaar generiert hast, machst du es für id_rsa und benutzt diese Schlüssel dann nur temporär zum testen, mit BackinTime für deine NAS.

EDIT:

Z. B. für einen "wichtigen" Host 😉 benutze ich 2 Schlüssel (mit verschiedenen Passwörter) gleichzeitig:

1
2
3

:~$ ssh <Host>
Enter passphrase for key '/home/$USER/.ssh/id_rsa_ax': 
Enter passphrase for key '/home/$USER/.ssh/id_ed25519':

Ich könnte jederzeit den einen oder anderen Schlüssel auch weglassen bzw. nicht benutzen.

Ehrlich, ich bin am verzweifeln und fürchte, ich mache etwas grundsätzlich falsch.

Das ist meine Backup Quelle:

1
2
3
4
5
6
7
8
9

USER@RECHNER:~/.ssh$ ls -l
total 24
-rw------- 1 USER USER  411 May 30 22:33 id_ed25519
-rw-r--r-- 1 USER USER   97 May 30 22:33 id_ed25519.pub
-rw------- 1 USER USER 2602 May 30 20:13 id_rsa
-rw-r--r-- 1 USER USER  569 May 30 20:13 id_rsa.pub
-rw------- 1 USER USER  317 Mar  8 20:15 known_hosts
-rw-rw-r-- 1 USER USER   95 Feb  5 23:12 known_hosts.old
USER@RECHNER:~/.ssh$ 

Ich habe alle id* in BiT unter privater Schlüssel ausprobiert. In meiner Verzweiflung unter privater ssh Schlüssel auch mit und ohne Passwort. Ich komme nicht weiter. ;(

lubux schrieb:

Z. B. für einen "wichtigen" Host 😉 benutze ich 2 Schlüssel (mit verschiedenen Passwörter) gleichzeitig:

1 2 3

:~$ ssh <Host> Enter passphrase for key '/home/$USER/.ssh/id_rsa_ax': Enter passphrase for key '/home/$USER/.ssh/id_ed25519':

Ich könnte jederzeit den einen oder anderen Schlüssel auch weglassen bzw. nicht benutzen.

Wirklich interessant aber zu früh für mich. Ich scheitere noch an der Pflicht.

wired2051 schrieb:

Ich habe alle id* in BiT unter privater Schlüssel ausprobiert.

Wie sind auf dem sshd-Server (NAS) die Ausgaben von:

pwd
ls -la .ssh
ls -la | grep .ssh

Den Schlüssel:

-rw------- 1 USER USER 2602 May 30 20:13 id_rsa
-rw-r--r-- 1 USER USER  569 May 30 20:13 id_rsa.pub

hast Du für die "Benutzung ohne Passwort", generiert, oder? Kannst Du dich z. Zt. mit diesem rsa-Schlüssel und ohne Passwort, auf dem NAS per ssh anmelden?
Wenn ja, Du musst in:

ssh -p PORT -o PreferredAuthentications=publickey -o IdentityFile=/home/USER/.ssh/id_ed25519 USERR@IP_DES_NAS echo "Hello"

"id_ed25519" durvh "id_rsa" ersetzen und testen:

ssh -p PORT -o PreferredAuthentications=publickey -o IdentityFile=/home/USER/.ssh/id_rsa USERR@IP_DES_NAS echo "Hello"

Danke für Deinen Geduld!

lubux schrieb:

Den Schlüssel:

-rw------- 1 USER USER 2602 May 30 20:13 id_rsa
-rw-r--r-- 1 USER USER  569 May 30 20:13 id_rsa.pub

hast Du für die "Benutzung ohne Passwort", generiert, oder?

Ehrlicherweise bin ich mir nicht mehr sicher. Soll ich id_rsa und id_ed25519 noch mal ohne Passwort erstellen oder kommt dann alles durcheinander? (Auf dem NAS hat ~/.ssh/authorized_keys inzwischen 19 Zeilen mit viel Redundanz.)

Der Login scheitert wieder:

USER@RECHNER:~$ ssh -p PORT -o PreferredAuthentications=publickey -o IdentityFile=/home/USER/.ssh/id_ed25519 USER@IP_DES_NAS echo "Hello"
USER@IP_DES_NAS: Permission denied (publickey,password).
USER@RECHNER:~$ ssh -p PORT -o PreferredAuthentications=publickey -o IdentityFile=/home/USER/.ssh/id_rsa USER@IP_DES_NAS echo "Hello"
USER@IP_DES_NAS: Permission denied (publickey,password).

Der Test aus dem OP funktioniert allerdings immer noch (was mich irritiert):

USER@RECHNER:~$ ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USER@IP_DES_NAS'
USER@IP_DES_NAS's password: 

Using terminal commands to modify system configs, execute external binary
files, add files, or install unauthorized third-party apps may lead to system
damages or unexpected behavior, or cause data loss. Make sure you are aware of
the consequences of each command and proceed at your own risk.

Warning: Data should only be stored in shared folders. Data stored elsewhere
may be deleted when the system is updated/restarted.

USER@DS420:~$ 

So kann ich mich auf dem NAS einloggen:

USER@RECHNER:~$ ssh -p PORT USER@IP_DES_NAS
USER@IP_DES_NAS's password: 

Using terminal commands to modify system configs, execute external binary
files, add files, or install unauthorized third-party apps may lead to system
damages or unexpected behavior, or cause data loss. Make sure you are aware of
the consequences of each command and proceed at your own risk.

Warning: Data should only be stored in shared folders. Data stored elsewhere
may be deleted when the system is updated/restarted.

USER@NAS:~$

Und das sind die Ausgaben:

USER@NAS:~$ pwd
/var/services/homes/USER
USER@NAS:~$ ls -la .ssh
total 8
drwxrwxrwx+ 1 USER users   30 May 31 21:55 .
drwxrwxrwx+ 1 USER users  526 May 31 22:54 ..
-rwxrwxrwx+ 1 USER users 5575 Jun  2 18:14 authorized_keys
USER@NAS:~$ ls -la | grep .ssh
drwx------  1 USER users               62 Sep  5  2021 2021-05-09.ssh
drwxrwxrwx+ 1 USER users               30 May 31 21:55 .ssh
USER@NAS:~$ 

wired2051 schrieb:

Soll ich id_rsa und id_ed25519 noch mal ohne Passwort erstellen oder kommt dann alles durcheinander?

Ja, wir reden hier von einem Passwort für die Benutzung des Schlüssels, ... und das willst Du nicht haben.

wired2051 schrieb:

Und das sind die Ausgaben:

USER@NAS:~$ ls -la .ssh
total 8
drwxrwxrwx+ 1 USER users   30 May 31 21:55 .
drwxrwxrwx+ 1 USER users  526 May 31 22:54 ..
-rwxrwxrwx+ 1 USER users 5575 Jun  2 18:14 authorized_keys

USER@NAS:~$ ls -la | grep .ssh
drwx------  1 USER users               62 Sep  5  2021 2021-05-09.ssh
drwxrwxrwx+ 1 USER users               30 May 31 21:55 .ssh

Die Datei "authorized_keys" soll chmod 600 haben und das Unterverzeichnis ".ssh" soll chmod 700 haben. Das ist bei dir nicht so. Das Pluszeichen am Ende zeigt an, dass für die Datei bzw. für das Unterverzeichnis, eine ACL aktiv ist. Ist das wegen dem NAS so?

BTW: Wenn Du acl evtl. installiert hast:

apt policy acl
apt show acl

kannst mit z. B.:

getfacl <Dateiname>

die Rechte detailliert anzeigen lassen.

lubux schrieb:

Die Datei "authorized_keys" soll chmod 600 haben und das Unterverzeichnis ".ssh" soll chmod 700 haben. Das ist bei dir nicht so.

Ich habe die Rechte auf dem NAS geändert:

1
2

drwx------  1 USER users               30 Jun  3 00:12  .ssh
-rw-------  1 USER users 5575 Jun  2 18:14 authorized_keys

lubux schrieb:

Ja, wir reden hier von einem Passwort für die Benutzung des Schlüssels, ... und das willst Du nicht haben.

Neues id_ed25519 Schlüsselpaar lokal erstellt:

1
2
3
4
5
6
7
8

USER@RECHNER:~/.ssh$ ls -l
total 24
-rw------- 1 USER GRUPPE  411 Jun  8 23:15 id_ed25519
-rw-r--r-- 1 USER GRUPPE   97 Jun  8 23:15 id_ed25519.pub
-rw------- 1 USER GRUPPE 2602 May 30 20:13 id_rsa
-rw-r--r-- 1 USER GRUPPE  569 May 30 20:13 id_rsa.pub
-rw------- 1 USER GRUPPE  317 Mar  8 20:15 known_hosts
-rw-rw-r-- 1 USER GRUPPE   95 Feb  5 23:12 known_hosts.old

Pub key auf NAS kopiert und getestet:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

USER@RECHNER:~/.ssh$ ssh-copy-id -i ~/.ssh/id_ed25519.pub -p PORT USER@IP_DES_NAS
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/USER/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
USER@IP_DES_NAS's password: 

Number of key(s) added: 1

Now try logging into the machine, with: "ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USER@IP_DES_NAS'"
and check to make sure that only the key(s) you wanted were added.

USER@RECHNER:~/.ssh$ ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USER@IP_DES_NAS'
USER@IP_DES_NAS's password: 

Using terminal commands to modify system configs, execute external binary
files, add files, or install unauthorized third-party apps may lead to system
damages or unexpected behavior, or cause data loss. Make sure you are aware of
the consequences of each command and proceed at your own risk.

Warning: Data should only be stored in shared folders. Data stored elsewhere
may be deleted when the system is updated/restarted.

USER@NAS:~$ 

lubux schrieb:

Das Pluszeichen am Ende zeigt an, dass für die Datei bzw. für das Unterverzeichnis, eine ACL aktiv ist. Ist das wegen dem NAS so?

Ich habe mich erkundigt: ACL ist wohl standardmässig von Synology aktiviert und kann nicht deaktiviert werden.

Mehr habe ich nicht herausgefunden:

USER@NAS:~/.ssh$ apt show acl
-sh: apt: command not found
USER@NAS:~/.ssh$ getfacl authorized_keys 
-sh: getfacl: command not found

Back in Time hat mich wieder gefragt, ob der id_ed255519.pub auf das NAS kopiert werden soll. Nach Passworteingabe war ich wieder in der Dauerschleife. Immerhin wurde authorized_keys auf dem NAS aktualisiert. Die Datei enthält nun 22 Zeilen.

Ein Backup wurde nicht erstellt.

wired2051 schrieb:

Pub key auf NAS kopiert und getestet:

1 2 3 4 5 6

USER@RECHNER:~/.ssh$ ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USER@IP_DES_NAS' USER@IP_DES_NAS's password: ... USER@NAS:~$

Hast Du in der sshd_config (oder gleichwertig) des NAS, die Passwort-Authentication deaktiviert? Was wird mit "-vv" zusätzlich angezeigt?

ssh -vv -i /home/USER/.ssh/id_ed25519 -p PORT 'USER@IP_DES_NAS'

Hallo

Ich verfolge euere Diskussion schon eine Weile, weil ich auch backups über ssh mache

Now try logging into the machine, with: "ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USER@IP_DES_NAS'" Zitierter Textand check to make sure that only the key(s) you wanted were added.

Hast du das gemacht und funktioniert es? Oder habe ich es übersehen, dass du das gepostet hast?

Bei mir schaut das so aus, wenn ich mich einlogge und beim key generieren kein PW erstellt habe (mit Enter)

testuser@raspi-u4:~ $ ssh 192.168.1.40
Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-106-generic x86_64)
You have new mail.
Last login: Tue Jun  9 20:00:43 2026 from 192.168.1.53
testuser@asrock:~ $ 

ps: den port habe ich sowohl in der ssh als auch in der sshd config auf den gleichen Wert (nicht standart) gestellt