wired2051
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2736
|
Leider kenne ich mich mit SSH nicht wirklich aus, habe ich zuletzt vor über 10 Jahren auf dem alten NAS eingerichtet... Ich will von meinem Kubuntu-PC ein Generationen-Backup auf einem NAS (Synology DS420+ mit DSM 7) erstellen. Beim Backup soll auf dem NAS der eigens eingerichtete Benutzer Backup genutzt werden - also Eigentümer der Daten sein. Da die Daten ohne spezielle Software lesbar sein sollen, geht das offenbar nur mit rsnapshot und Back in Time. Da ich die Backups gerne halbwegs übersichtlich mit GUI prüfen/verwalten möchte, habe ich erst einmal Back in Time 1.3.1 auf dem Quell-PC installiert. Leider scheitere ich bei der Konfiguration von Back in Time: immer, wenn ich das Einstellungen-Fenster mit OK verlasse, reagiert das Programm nicht mehr und nach 5 Minuten kommt die Frage Möchten Sie den öffentlichen SSH-Schlüssel auf den entfernten Rechner kopieren?. Nach JA reagiert das Programm wieder nicht mehr und nach weiteren 5 Minuten bin ich wieder im Einstellungen-Fenster. Es ist auch egal, ob ich als Benutzer LOCAL_USER (User der Backup-Quelle) oder Backup (User des Backup-Ziels) wähle. Mir bleibt nichts übrig als abzubrechen. Bis jetzt habe ich mit ssh-keygen das public/private rsa key pair für LOCAL_USER mit passphrase erstellt. Mit ssh-copy-id -i ~/.ssh/id_rsa.pub LOCAL_USER@IP_DES_NAS habe ich den public key auf das NAS kopiert. LOCAL_USER@DS420:~$ cat ~/.ssh/authorized_keys und LOCAL_USER@LOCAL_RECHNER:~$ cat ~/.ssh/id_rsa.pub sind identisch, d.h. der key wurde kopiert. In der Konsole kann ich mich mit ssh Backup@IP_DES_NAS mit dem Passwort und ssh LOCAL_USER@IP_DES_NAS mit der passphrase auf dem NAS/Backup-Ziel anmelden. Was könnte das Problem sein? Wie kann ich den Fehler suchen? Oder ist das doch kein SSH-Problem sondern eines von Back in Time?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Ist das in der Lage PubKeys MIT Passwort zu nutzen? Ich verwende diese für automatische Dienste immer ohne Passwort, so dass ein ssh benutzer@ziel -i ~/.ssh/schlüssel_für_diesen ohne weitere Eingabe zum Login führt. Wenn du Schlüssel kopierst oder sonstwie an ssh rumfummelst, empfehle ich dir auch die Rechte zu prüfen. Wenn eine Schlüsseldatei zu offene Rechte hat, wird diese von SSH als unsicher interpretiert und verworfen. Rechte darf nur der Eigentümer haben, außer bei PublickKeys. Also Ordner 700, Dateien 600, oder vergleichbar. Zeige mal die Ausgabe von ssh -vvv backup@nas -i ~/.ssh/schlüsselname Wie das mit der GUI funktioniert, weiß ich aber nicht, habe BackInTime noch nie verwendet.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2736
|
Ersteinmal vielen Dank für Deine Hilfsbereitschaft 👍 , ich bin schon am verzweifeln. ChickenLipsRfun2eat schrieb: Hallo! Ist das in der Lage PubKeys MIT Passwort zu nutzen? Ich verwende diese für automatische Dienste immer ohne Passwort, so dass ein ssh benutzer@ziel -i ~/.ssh/schlüssel_für_diesen ohne weitere Eingabe zum Login führt.
Back in Time will unter dem Stichwort Passwort den privaten SSH-Schlüssel, ich habe da schon Passwort und die passphrase verwendet - erfolglos. ChickenLipsRfun2eat schrieb: Wenn du Schlüssel kopierst oder sonstwie an ssh rumfummelst, empfehle ich dir auch die Rechte zu prüfen.
Bis jetzt ist alles so, wie es von ssh-keygen und ssh-copy-id erstellt wurde, ich habe noch nichts verändert. ssh-copy-id wird auch im SSH-Wiki-Artikel angewendet um den öffentliche Schlüssel auf das Zielsystem zu kopieren. ChickenLipsRfun2eat schrieb: Wenn eine Schlüsseldatei zu offene Rechte hat, wird diese von SSH als unsicher interpretiert und verworfen. Rechte darf nur der Eigentümer haben, außer bei PublickKeys. Also Ordner 700, Dateien 600, oder vergleichbar.
Backup-Quelle: | LOCAL_USER@LOCAL_RECHNER:~$ ls -la ~/
insgesamt 8032
drwx------ 2 LOCAL_USER LOCAL_USER 4096 Sep 6 23:45 .ssh
LOCAL_USER@LOCAL_RECHNER:~$ ls -l ~/.ssh/
insgesamt 12
-rw------- 1 LOCAL_USER LOCAL_USER 1766 Sep 2 23:32 id_rsa
-rw-r--r-- 1 LOCAL_USER LOCAL_USER 397 Sep 2 23:32 id_rsa.pub
-rw-r--r-- 1 LOCAL_USER LOCAL_USER 1952 Aug 28 14:57 known_hosts
|
Backup-Ziel: LOCAL_USER 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | LOCAL_USER@DS420:~$ ls -la ~/
total 4
drwxrwxrwx+ 1 LOCAL_USER users 62 Sep 5 22:45 .ssh
LOCAL_USER@LOCAL_RECHNER:~$ ssh LOCAL_USER@IP_DES_NAS
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.
LOCAL_USER@DS420:~$ ls -l ~/.ssh/
total 12
-rwxrwxrwx+ 1 LOCAL_USER users 397 Sep 5 22:45 authorized_keys
-rwxrwxrwx+ 1 LOCAL_USER users 2602 Aug 29 18:13 id_rsa
-rwxrwxrwx+ 1 LOCAL_USER users 568 Aug 29 18:13 id_rsa.pub
|
Backup-Ziel: User Backup | LOCAL_USER@LOCAL_RECHNER:~$ ssh Backup@IP_DES_NAS
Backup@IP_DES_NAS's password:
Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.
Backup@DS420:~$ ls -l ~/.ssh/
ls: cannot access '/var/services/homes/Backup/.ssh/': No such file or directory
|
Dass ich keinen key für den Nutzer Backup habe, ist mir klar, denn der existiert nur auf dem Backup-Ziel. Ich wüsste nicht, wie ich ein Schlüsselpaar für Backup erstellen sollte. Muss ich also chmod 700 auf ~/.ssh/ und chmod 600 auf id_rsa.pub aber nicht auf id_rsa anwenden? Nur auf dem NAS oder auch lokal? ChickenLipsRfun2eat schrieb: Zeige mal die Ausgabe von ssh -vvv backup@nas -i ~/.ssh/schlüsselname
Für den User Backup geht das nicht, da kein SSH-Schlüssel, also für LOCAL_USER: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248 | LOCAL_USER@LOCAL_RECHNER:~$ ssh -vvv LOCAL_USER@IP_DES_NAS -i ~/.ssh/id_rsa.pub
OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "IP_DES_NAS" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to IP_DES_NAS [IP_DES_NAS] port 22.
debug1: Connection established.
debug1: identity file /home/LOCAL_USER/.ssh/id_rsa.pub type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/LOCAL_USER/.ssh/id_rsa.pub-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to IP_DES_NAS:22 as 'LOCAL_USER'
debug3: hostkeys_foreach: reading file "/home/LOCAL_USER/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/LOCAL_USER/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys from IP_DES_NAS
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
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: 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
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,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: curve25519-sha256@libssh.org
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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:65ldlmhspmL4rgYsC6NR+5kY/dpFi63pPMNMzyTxgCc
debug3: hostkeys_foreach: reading file "/home/LOCAL_USER/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/LOCAL_USER/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys from IP_DES_NAS
debug1: Host 'IP_DES_NAS' is known and matches the ECDSA host key.
debug1: Found key in /home/LOCAL_USER/.ssh/known_hosts:6
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /home/LOCAL_USER/.ssh/id_rsa.pub (0x55bd32e44630), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
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>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/LOCAL_USER/.ssh/id_rsa.pub
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:HaG9zxKkiv1p8yIsAtR4M9d3dAJJmhKC1cqwBgeDh0s
debug3: sign_and_send_pubkey: RSA SHA256:HaG9zxKkiv1p8yIsAtR4M9d3dAJJmhKC1cqwBgeDh0s
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/LOCAL_USER/.ssh/id_rsa.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/LOCAL_USER/.ssh/id_rsa.pub": bad permissions
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
LOCAL_USER@IP_DES_NAS's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to IP_DES_NAS ([IP_DES_NAS]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: /var/services/homes/LOCAL_USER/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env XDG_VTNR
debug3: Ignored env PAM_KWALLET5_LOGIN
debug3: Ignored env KDE_MULTIHEAD
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env XDG_GREETER_DATA_DIR
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env GTK2_RC_FILES
debug3: Ignored env KONSOLE_DBUS_SERVICE
debug3: Ignored env KONSOLE_PROFILE_NAME
debug3: Ignored env QT_LINUX_ACCESSIBILITY_ALWAYS_ON
debug3: Ignored env GTK_RC_FILES
debug3: Ignored env GS_LIB
debug3: Ignored env WINDOWID
debug3: Ignored env SHELL_SESSION_ID
debug3: Ignored env KDE_FULL_SESSION
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env QT_ACCESSIBILITY
debug3: Ignored env XDG_SESSION_PATH
debug3: Ignored env XDG_SEAT_PATH
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env DEFAULTS_PATH
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env PATH
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env PWD
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env KONSOLE_DBUS_WINDOW
debug1: Sending env LANG = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env KDE_SESSION_UID
debug3: Ignored env GDM_LANG
debug3: Ignored env MANDATORY_PATH
debug3: Ignored env KONSOLE_DBUS_SESSION
debug3: Ignored env GDMSESSION
debug3: Ignored env COLORFGBG
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env XDG_SEAT
debug3: Ignored env KDE_SESSION_VERSION
debug3: Ignored env LANGUAGE
debug3: Ignored env XCURSOR_THEME
debug3: Ignored env XDG_SESSION_DESKTOP
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env LESSOPEN
debug3: Ignored env PROFILEHOME
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env DISPLAY
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env LESSCLOSE
debug3: Ignored env PAM_KWALLET_LOGIN
debug3: Ignored env XAUTHORITY
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.
LOCAL_USER@DS420:~$ exit
logout
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)
debug3: send packet: type 1
Connection to IP_DES_NAS closed.
Transferred: sent 4708, received 10824 bytes, in 1115.7 seconds
Bytes per second: sent 4.2, received 9.7
debug1: Exit status 0
LOCAL_USER@LOCAL_RECHNER:~$
|
Back in Time funktioniert, wie gesagt, weder mit dem User Backup noch LOCAL_USER.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2736
|
Danke für Deine Geduld. 👍 ChickenLipsRfun2eat schrieb: Also zunächst mal: Wer soll denn nun auf wen zugreifen? Das NAS auf den PC oder der PC aufs NAS?
Benutzer LOCAL_USER soll vom PC aus auf das NAS zugreifen und als Benutzer Backup dort Daten speichern. LOCAL_USER existiert auf dem PC und auf dem NAS. Auf dem NAS ist er Mitglied in Gruppe administrators mit den entsprechenden Rechten. Deshalb soll das Backup von Benutzer Backup erstellt werden - ohne Admin-Rechte. ChickenLipsRfun2eat schrieb:
Entschuldigung, da habe ich mich wohl falsch ausgedrückt. Das Passwort und die passphrase sind natürlich nicht identisch. ChickenLipsRfun2eat schrieb:
Das verstehe ich nicht ganz. Ich kann mich natürlich auf dem NAS als Backup anmelden und dann mit sudo ssh-keygen das Schlüsselpaar erzeugen. Und ich könnte den
public key auch in home/Backup/.ssh/authorized_keys eintragen aber da Benutzer Backup auf dem LOCAL_RECHNER (Backup Quelle) nicht existiert, kann ich da id_rsa nicht ablegen. Oder habe ich das immer noch nicht richtig verstanden? ChickenLipsRfun2eat schrieb:
Jetzt stimmen die Berechtigungen, oder? 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | USER@DS420:~$ chmod 700 ~/.ssh/
USER@DS420:~$ ls -la
total 4
drwxrwxrwx+ 1 USER users 40 Aug 30 23:16 .
drwxrwxrwx+ 1 root root 50 Aug 29 17:55 ..
drwxrwxrwx+ 1 root root 82 Aug 30 23:16 '#recycle'
drwx------ 1 USER users 62 Sep 5 22:45 .ssh
-rwxrwxrwx+ 1 USER users 1129 Aug 30 23:15 .viminfo
USER@DS420:~$ chmod 600 ~/.ssh/id_rsa.pub
USER@DS420:~$ ls -la ~/.ssh/
total 12
drwx------ 1 USER users 62 Sep 5 22:45 .
drwxrwxrwx+ 1 USER users 40 Aug 30 23:16 ..
-rwxrwxrwx+ 1 USER users 397 Sep 5 22:45 authorized_keys
-rwxrwxrwx+ 1 USER users 2602 Aug 29 18:13 id_rsa
-rw------- 1 USER users 568 Aug 29 18:13 id_rsa.pub
USER@DS420:~$
|
ChickenLipsRfun2eat schrieb: Du hast auf LOCAL_USER@DS420 ACL gesetzt, da musst du die Berechtigungen mit getfacl prüfen, da ls nur anzeigt, dass welche da sind (das + am Ende der Berechtigungen)
Die + sind mir gar nicht aufgefallen. Auf jeden Fall nutze ich ACL nicht bewusst, offenbar war es die Synology. Jedenfalls ist getfacl auf der Synology nicht installiert. Offenbar kann ich mit chmod diese ACL Rechte löschen/überschreiben, da ich aber keine Ahnung habe, wozu sie gut sind, bin ich da zurückhaltend... Übrigens: Nun muss ich beim Anmelden mit LOCAL_USER@IP_DES_NAS drei mal die passphrase for key '/home/LOCAL_USER/.ssh/id_rsa' und einmal LOCAL_USER@IP_DES_NAS's password eingeben. Irgendwas stimmt da immer noch nicht.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
von.wert schrieb: KBionic ist außerhalb des Supports seit über 4 Monaten.
👍 wired2051 schrieb: Benutzer LOCAL_USER soll vom PC aus auf das NAS zugreifen und als Benutzer Backup dort Daten speichern.
Also dann erstellst du auf dem PC als local_user das Schlüsselpaar, kopierst den key.pub mit Passwort-Login per ssh-copy-id direkt auf den Nutzer backup, ohne Umwege über local-user und loggst dich danach mit dem Key ein, um ihn zu testen.
| ssh-copy-id -i ~/.ssh/to_nas.pub backup@nas.tld
# benutzerpasswort backup verwenden
ssh -i ~/.ssh/to_nas backup@nas.tld
# Schlüsselpasswort verwenden
|
Du kannst auch den ssh-key ohne Passwort erstellen, dann erfolgt der Login ohne weitere Abfrage(n) direkt. Das verstehe ich nicht ganz. Ich kann mich natürlich auf dem NAS als Backup anmelden und dann mit sudo ssh-keygen das Schlüsselpaar erzeugen.
Warum jetzt sudo ssh-keygen ?
public key auch in home/Backup/.ssh/authorized_keys eintragen aber da Benutzer Backup auf dem LOCAL_RECHNER (Backup Quelle) nicht existiert, kann ich da id_rsa nicht ablegen. Oder habe ich das immer noch nicht richtig verstanden?
Wie der entfernte Benutzer heißt ist irrelevant. Den gibst du ja auf der ssh-Zeile mit an, also bspw. user2345@zielrechner.tld . Der Unterschied ist, du kannst den user@-Teil weglassen, wenn der Name lokal und entfernt gleich ist, weil dann automatisch die Variable $USER verwendet wird. Ich gebe das aber immer mit an, dann muss ich nicht nachdenken 😉
Jetzt stimmen die Berechtigungen, oder?
Kann ich nicht sehen ⇨ ACL Offenbar kann ich mit chmod diese ACL Rechte löschen/überschreiben, da ich aber keine Ahnung habe, wozu sie gut sind, bin ich da zurückhaltend...
Damit änderst du nur die Maske. Den Artikel verstehend lesen kann ich dir leider nicht abnehmen…
Übrigens: Nun muss ich beim Anmelden mit LOCAL_USER@IP_DES_NAS drei mal die passphrase for key '/home/LOCAL_USER/.ssh/id_rsa' und einmal LOCAL_USER@IP_DES_NAS's password eingeben. Irgendwas stimmt da immer noch nicht.
Im Zweifelsfall löschen, bzw. umbenennen. mv ~/.ssh{oldssh} . Dann noch mal von vorne.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2736
|
ChickenLipsRfun2eat schrieb: wired2051 schrieb: Benutzer LOCAL_USER soll vom PC aus auf das NAS zugreifen und als Benutzer Backup dort Daten speichern.
Also dann erstellst du auf dem PC als local_user das Schlüsselpaar, kopierst den key.pub mit Passwort-Login per ssh-copy-id direkt auf den Nutzer backup, ohne Umwege über local-user und loggst dich danach mit dem Key ein, um ihn zu testen.
| ssh-copy-id -i ~/.ssh/to_nas.pub backup@nas.tld
# benutzerpasswort backup verwenden
ssh -i ~/.ssh/to_nas backup@nas.tld
# Schlüsselpasswort verwenden
|
...ich weiss nicht, warum Du die Erweiterung *.tld nutzt. 😳 Aber immerhin ich interpretiere die Ausgabe so, dass es jetzt funktioniert hat: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25 | LOCAL_USER@LOCAL_RECHNER:~$ ssh-copy-id -i ~/.ssh/id_rsa.pub Backup@IP_DES_NAS
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/LOCAL_USER/.ssh/id_rsa.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
Backup@IP_DES_NAS's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'Backup@IP_DES_NAS'"
and check to make sure that only the key(s) you wanted were added.
LOCAL_USER@LOCAL_RECHNER:~$ ssh Backup@IP_DES_NAS
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.
Backup@DS420:~$ ls -la ~/.ssh/
total 4
drwxrwxrwx+ 1 Backup users 30 Sep 19 21:43 .
drwxrwxrwx+ 1 Backup users 52 Sep 19 21:43 ..
-rwxrwxrwx+ 1 Backup users 397 Sep 19 21:43 authorized_keys
Backup@DS420:~$
|
Und wenn ich jetzt Back in Time starte, lande ich auch nicht mehr in dieser Endlosschleife ☺ sondern bekomme eine andere Fehlermeldung ☹ : | sshfs -o ServerAliveInterval=240 -o LogLevel=Error -o IdentityFile=/home/USER/.ssh/id_rsa -p 22 -o idmap=user -o cache_dir_timeout=2 -o cache_stat_timeout=2 Backup@IP_DES_NAS:/volume1/Backups /home/USER/.local/share/backintime/mnt/356E567E/mountpoint kann nicht eingebunden werden
read: Connection reset by peer
|
Ich bin wieder ratlos. /home/USER/.local/share/backintime/mnt/356E567E/mountpoint ist ein leeres Verzeichnes auf dem lokalen PC und /volume1/Backups existiert auf dem NAS: | Backup@DS420:/volume1/Backups$ ls -la
total 0
drwxrwxrwx+ 1 root root 32 Sep 19 22:00 .
drwxr-xr-x 1 root root 398 Sep 3 23:36 ..
drwxrwxrwx+ 1 Backup Backup 62 Sep 27 2019 Daten
drwxrwxrwx+ 1 LOCAL_USER users 36 Oct 11 2014 'LOCAL_RECHNER home'
Backup@DS420:/volume1/Backups$
|
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2736
|
Du meinst ssh -v Backup@IP_DES_NAS auf dem PC (Backup Quelle)? Aber ich komme mit ssh passphrase doch auf das NAS. In Back In Time habe ich die ssh passphrase auch hintgerlegt. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67 | LOCAL_USER@LOCAL_RECHNER:~$ ssh -v Backup@IP_DES_NAS
OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to IP_DES_NAS [IP_DES_NAS] port 22.
debug1: Connection established.
debug1: identity file /home/LOCAL_USER/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/LOCAL_USER/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/LOCAL_USER/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/LOCAL_USER/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/LOCAL_USER/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/LOCAL_USER/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/LOCAL_USER/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/LOCAL_USER/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to IP_DES_NAS:22 as 'Backup'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
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:65ldlmhspmL4rgYsC6NR+5kY/dpFi63pPMNMzyTxgCc
debug1: Host 'IP_DES_NAS' is known and matches the ECDSA host key.
debug1: Found key in /home/LOCAL_USER/.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: 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: Offering RSA public key: /home/LOCAL_USER/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
debug1: Authentication succeeded (publickey).
Authenticated to IP_DES_NAS ([IP_DES_NAS]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /var/services/homes/Backup/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /var/services/homes/Backup/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.
Backup@DS420:~$
|
In Back In Time habe ich keine Möglichkeit gefunden ssh eine Option mitzugeben. Die Fehlermeldung kommt übrigens innerhalb von 3 Sekunden - sieht für mich nicht nach Time out aus. Ich dachte ja erst an ein Rechte-Problem aber auch wenn ich Backup in die Gruppe administrators tue, kommt diese Meldung.
|