Discussione:
accedere al nas Synology tramite ssh e senza password
(troppo vecchio per rispondere)
alex
2016-12-15 08:23:02 UTC
Permalink
+ ssh-keygen -f /tmp/le_mie_chiavi/test
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

+ scp /tmp/le_mie_chiavi/test.pub
***@nas:/volume1/homes/fittizio/.ssh/authorized_keys
***@nas's password:
test.pub 100% 392 0.4KB/s
00:00

Adesso vediamo se funziona

+ ssh -i /tmp/le_mie_chiavi/test ***@nas
***@nas's password:
Permission denied, please try again.
Connection to nas closed.

Come vedete viene chiesta la password (e non dovrebbe succedere), e
comunque l'accesso viene rifiutato.
Dov'è il problema?
angelo
2016-12-15 09:26:09 UTC
Permalink
Post by alex
+ ssh-keygen -f /tmp/le_mie_chiavi/test
test.pub 100% 392 0.4KB/s 00:00
Adesso vediamo se funziona
Permission denied, please try again.
Connection to nas closed.
Come vedete viene chiesta la password (e non dovrebbe succedere), e comunque l'accesso
viene rifiutato.
Dov'è il problema?
Da admin se digiti
ls -al /var/services/homes
cosa ti risponde?

L'accesso ssh, di default, viene rifiutato a tutti gli utenti normali mentre e' consentito
agli utenti di sistema per motivi di sicurezza, ma questo gia' lo sai.

angelo
alex
2016-12-15 15:08:58 UTC
Permalink
Post by angelo
Da admin se digiti
ls -al /var/services/homes
cosa ti risponde?
lrwxrwxrwx 1 root root 14 Dec 15 08:33 /var/services/homes -> /volume1/homes
Post by angelo
L'accesso ssh, di default, viene rifiutato a tutti gli utenti normali
mentre e' consentito agli utenti di sistema per motivi di sicurezza, ma
questo gia' lo sai.
Mai dare tutto per scontato.
Perdona come sempre la mia ignoranza...
Cos'è un utente di sistema?
Come si crea?
angelo
2016-12-15 18:15:57 UTC
Permalink
Post by alex
Post by angelo
Da admin se digiti
ls -al /var/services/homes
cosa ti risponde?
lrwxrwxrwx 1 root root 14 Dec 15 08:33 /var/services/homes -> /volume1/homes
Risposta corretta, mi era venuto il dubbio che mancasse la spunta su:
pannello di controllo - utente - avanzate - sede utente - abilita il servizio sede utente
che poteva essere la causa del problema ma a quanto vedo non e' quello.
E' la prima volta che vedo questo tipo di problema dopo anni di applicazioni ssh, quasi
esclusivamente con accesso tramite chiavi, e' strano...
Post by alex
Post by angelo
L'accesso ssh, di default, viene rifiutato a tutti gli utenti normali
mentre e' consentito agli utenti di sistema per motivi di sicurezza, ma
questo gia' lo sai.
Mai dare tutto per scontato.
Perdona come sempre la mia ignoranza...
Cos'è un utente di sistema?
Come si crea?
In /etc/passwd sono elencati tutti gli utenti, quelli che non crei tu sono utenti di
sistema che vengono creati in funzione dei vari servizi per poter accedere ciascuno ai
propri file, in genere hanno userID minore di 1025, admin e' 1024, quelli del gruppo user
partono dal 1025 in su.

angelo
alex
2016-12-15 18:32:55 UTC
Permalink
Post by angelo
In /etc/passwd sono elencati tutti gli utenti, quelli che non crei tu
sono utenti di sistema che vengono creati in funzione dei vari servizi
per poter accedere ciascuno ai propri file, in genere hanno userID
minore di 1025, admin e' 1024, quelli del gruppo user partono dal 1025
in su.
e quindi?
angelo
2016-12-15 20:15:30 UTC
Permalink
Post by alex
Post by angelo
In /etc/passwd sono elencati tutti gli utenti, quelli che non crei tu
sono utenti di sistema che vengono creati in funzione dei vari servizi
per poter accedere ciascuno ai propri file, in genere hanno userID
minore di 1025, admin e' 1024, quelli del gruppo user partono dal 1025
in su.
e quindi?
Non sono stato chiaro?
Sono utenti fittizi creati dal sistema ad uso dei servizi di sistema, l'utente normale non
ne ha alcun controllo.
Alcuni task sono lanciati non come root ma come altri utenti di sistema e hanno accesso
solo alle proprie risorse.
Ad esempio l'aggiornamento dell'ora di sistema e' lanciato dall'user ntp.

angelo
alex
2016-12-15 20:19:32 UTC
Permalink
Post by angelo
Non sono stato chiaro?
Sono utenti fittizi creati dal sistema ad uso dei servizi di sistema,
l'utente normale non ne ha alcun controllo.
Alcuni task sono lanciati non come root ma come altri utenti di sistema
e hanno accesso solo alle proprie risorse.
Ad esempio l'aggiornamento dell'ora di sistema e' lanciato dall'user ntp.
quindi un utente normale non può usare ne ssh, ne chiavi crittografiche?
angelo
2016-12-15 21:01:33 UTC
Permalink
Post by alex
Post by angelo
Non sono stato chiaro?
Sono utenti fittizi creati dal sistema ad uso dei servizi di sistema,
l'utente normale non ne ha alcun controllo.
Alcuni task sono lanciati non come root ma come altri utenti di sistema
e hanno accesso solo alle proprie risorse.
Ad esempio l'aggiornamento dell'ora di sistema e' lanciato dall'user ntp.
quindi un utente normale non può usare ne ssh, ne chiavi crittografiche?
SSH e' il protocollo di connessione cifrata per la connessione remota su un altro host.
Serve, tra l'altro, ad aprire una shell di comandi e la possibilita' di poter permettere
l'autenticazione utente solo con la chiave e non con password la rende particolarmente
sicura.
Nel caso particolare di synology l'accesso con shell di comandi ssh e telnet e' consentita
solo a root e admin e vietata agli user normali per motivi di sicurezza e per impedire
l'accesso alle directory degli altri utenti.
Un utente normale puo' invece lanciare un task rsync attraverso ssh (anche con chiave)
perche' non apre una shell ma non gli e' consentito appunto aprire una shell.
Il tuo problema e' apparentemente dovuto alla impossibilita' di accedere alla chiave
pubblica per un motivo che non comprendo.
Per come la vedo io dovresti provare a resettare tutto e ripartire da zero.

angelo
alex
2016-12-16 07:23:36 UTC
Permalink
Post by angelo
Nel caso particolare di synology l'accesso con shell di comandi ssh e
telnet e' consentita solo a root e admin e vietata agli user normali per
motivi di sicurezza e per impedire l'accesso alle directory degli altri
utenti.
Quindi è normale che, se tento di accedere alla shell come utente
normale (fittizio, test2, mionomeutente...), l'accesso viene rifiutato?
Post by angelo
Un utente normale puo' invece lanciare un task rsync attraverso ssh
(anche con chiave) perche' non apre una shell ma non gli e' consentito
appunto aprire una shell.
Ho notato una cosa esaminando il file che contiene la chiave pubblica,
che ho generato col solito comando "ssh-keygen -f fittizio".
La chiave finisce con ***@comex (comex è il nome del mio computer,
cioè il nome che ovviamente compare tra le risorse di rete).
Non è che comex dovrebbe essere sostituito col nome del mio nas (nas)
oppure con il rispettivo IP (192.168.0.120)?
Post by angelo
Il tuo problema e' apparentemente dovuto alla impossibilita' di accedere
alla chiave pubblica per un motivo che non comprendo.
Non c'è una tecnica apposita per verificare l'accessibilità?
Post by angelo
Per come la vedo io dovresti provare a resettare tutto e ripartire da zero.
Dovrei riformattare e reinstallare il DSM?
o_O
angelo
2016-12-16 11:05:25 UTC
Permalink
...
Quindi è normale che, se tento di accedere alla shell come utente normale (fittizio,
test2, mionomeutente...), l'accesso viene rifiutato?
Esatto! Non solo e' normale ma e' pericoloso il contrario.
...
Ho notato una cosa esaminando il file che contiene la chiave pubblica, che ho generato col
solito comando "ssh-keygen -f fittizio".
ovviamente compare tra le risorse di rete).
Non è che comex dovrebbe essere sostituito col nome del mio nas (nas) oppure con il
rispettivo IP (192.168.0.120)?
No, e' solo una stringa, l'identificativo della chiave. Puoi cambiarlo senza problemi.
Post by angelo
Il tuo problema e' apparentemente dovuto alla impossibilita' di accedere
alla chiave pubblica per un motivo che non comprendo.
Non c'è una tecnica apposita per verificare l'accessibilità?
C'e', ma occorrerebbe modificare file di sistema col rischio di mandare tutto a donnine
allegre. Oltretutto, verificato che non hai l'accesso, resta il problema di capire il
motivo e consentirlo...
Post by angelo
Per come la vedo io dovresti provare a resettare tutto e ripartire da zero.
Dovrei riformattare e reinstallare il DSM?
Puoi cominciare a verificare la validita' della coppia di chiavi sul tuo stesso PC,
creando un secondo utente e copiando sulla sua home la stessa chiave pubblica e loggandoti
dal tuo utente principale col comando:

ssh -i ~/.ssh/id_rsa <utente2>@localhost

e vedi cosa ti risponde.
Se ti risponde qualcosa tipo:

ssh: connect to host localhost port 22: Network is unreachable

dovrai prima avviare il servizio sshd sul PC.

angelo
alex
2016-12-16 11:34:48 UTC
Permalink
Post by angelo
...
Quindi è normale che, se tento di accedere alla shell come utente normale (fittizio,
test2, mionomeutente...), l'accesso viene rifiutato?
Esatto! Non solo e' normale ma e' pericoloso il contrario.
OK.
Ma allora perchè su it.*iniziare mi avevi chiesto di dare il comando

ssh -i /home/xxx/Documenti/fittizio_keys/id_rsa ***@192.168.0.120

per vedere cosa succede?
Post by angelo
...
Ho notato una cosa esaminando il file che contiene la chiave pubblica,
che ho generato col
solito comando "ssh-keygen -f fittizio".
computer, cioè il nome che
ovviamente compare tra le risorse di rete).
Non è che comex dovrebbe essere sostituito col nome del mio nas (nas) oppure con il
rispettivo IP (192.168.0.120)?
No, e' solo una stringa, l'identificativo della chiave. Puoi cambiarlo senza problemi.
Quindi lo devo cambiare (in che cosa?), o lo devo lasciare com'è?
Post by angelo
Puoi cominciare a verificare la validita' della coppia di chiavi sul tuo
stesso PC, creando un secondo utente e copiando sulla sua home la stessa
e vedi cosa ti risponde.
ssh: connect to host localhost port 22: Network is unreachable
dovrai prima avviare il servizio sshd sul PC.
1989 ssh-keygen
1993 sudo mkdir /home/test/.ssh
1995 sudo cp ~/.ssh/id_rsa.pub /home/test/.ssh/authorized_keys
1996 ssh -i ~/.ssh/id_rsa ***@localhost
ssh: connect to host localhost port 22: Connection refused
angelo
2016-12-16 12:00:02 UTC
Permalink
Il 16/12/2016 12:34, alex ha scritto:
...
Post by alex
OK.
Ma allora perchè su it.*iniziare mi avevi chiesto di dare il comando
per vedere cosa succede?
Per vedere come risponde: chiede la password se non riconosce la chiave, se rifiuta subito
la connessione significa che la chiave e' valida ma viene negata la shell.
Post by alex
Post by angelo
...
No, e' solo una stringa, l'identificativo della chiave. Puoi cambiarlo senza problemi.
Quindi lo devo cambiare (in che cosa?), o lo devo lasciare com'è?
Come vuoi, e' ininfluente ai fini della validita'. Io di solito le do un nome associato
alla chiave privata.
Post by alex
Post by angelo
ssh: connect to host localhost port 22: Network is unreachable
dovrai prima avviare il servizio sshd sul PC.
1989 ssh-keygen
1993 sudo mkdir /home/test/.ssh
1995 sudo cp ~/.ssh/id_rsa.pub /home/test/.ssh/authorized_keys
ssh: connect to host localhost port 22: Connection refused
Probabilmente il servizio sshd non e' avviato perche' altrimenti quantomeno avrebbe dovuto
chiederti la password.
Io non ho dimestichezza con ubuntu ma qui puoi trovare aiuto su come installare/avviare il
servizio.

http://help.ubuntu-it.org/10.04/ubuntu/serverguide/it/openssh-server.html

angelo
alex
2016-12-16 12:25:28 UTC
Permalink
Post by angelo
...
Post by alex
OK.
Ma allora perchè su it.*iniziare mi avevi chiesto di dare il comando
per vedere cosa succede?
Per vedere come risponde: chiede la password se non riconosce la chiave,
se rifiuta subito la connessione significa che la chiave e' valida ma
viene negata la shell.
Quindi secondo te la chiave non viene riconosciuta o non è valida?
Naturalmente a prescindere dal fatto che un utente normale non può
accedere alla shell ssh.
Post by angelo
Post by alex
Post by angelo
ssh: connect to host localhost port 22: Network is unreachable
dovrai prima avviare il servizio sshd sul PC.
1989 ssh-keygen
1993 sudo mkdir /home/test/.ssh
1995 sudo cp ~/.ssh/id_rsa.pub /home/test/.ssh/authorized_keys
ssh: connect to host localhost port 22: Connection refused
Probabilmente il servizio sshd non e' avviato perche' altrimenti
quantomeno avrebbe dovuto chiederti la password.
Io non ho dimestichezza con ubuntu ma qui puoi trovare aiuto su come
installare/avviare il servizio.
http://help.ubuntu-it.org/10.04/ubuntu/serverguide/it/openssh-server.html
Aspetta che preferisco chiedere a qualcuno per evitare di fare pasticci.
angelo
2016-12-16 13:42:23 UTC
Permalink
Post by alex
...
Quindi secondo te la chiave non viene riconosciuta o non è valida?
Naturalmente a prescindere dal fatto che un utente normale non può accedere alla shell ssh.
Il server ssh alla richiesta di connessione fa la verifica delle credenziali, verifica per
prima cosa la chiave, se non corrisponde chiede la password e poi chiude la connessione se
lo user non ha accesso alla shell.
Se chiude subito la connessione e' perche' ha accettato la chiave.
Post by alex
Aspetta che preferisco chiedere a qualcuno per evitare di fare pasticci.
Sto seguendo il tuo thread su *.linux.iniziare, ti consiglio pero' di dare qualche
informazione in piu', per esempio quale OS stai usando e il link dove hai cercato: avrai
risposte piu' rapidamente.

angelo
alex
2016-12-16 16:02:44 UTC
Permalink
Post by angelo
Post by alex
...
Quindi secondo te la chiave non viene riconosciuta o non è valida?
Naturalmente a prescindere dal fatto che un utente normale non può
accedere alla shell ssh.
Il server ssh alla richiesta di connessione fa la verifica delle
credenziali, verifica per prima cosa la chiave, se non corrisponde
chiede la password e poi chiude la connessione se lo user non ha accesso
alla shell.
Se chiude subito la connessione e' perche' ha accettato la chiave.
Almeno vorrei capire se il file
/volume1/homes/fittizio/.ssh/authorized_keys
viene preso in considerazione, o la sua presenza viene ignorata totalmente.
Post by angelo
Post by alex
Aspetta che preferisco chiedere a qualcuno per evitare di fare pasticci.
Sto seguendo il tuo thread su *.linux.iniziare, ti consiglio pero' di
dare qualche informazione in piu', per esempio quale OS stai usando e il
link dove hai cercato: avrai risposte piu' rapidamente.
$ ssh -i ~/.ssh/id_rsa ***@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is SHA256:IqSuv7TlSguCnSXTveJAf9/Oe8OEytT7bMiGbvFdu8M.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
sign_and_send_pubkey: signing failed: agent refused operation
***@localhost's password:
angelo
2016-12-16 16:31:05 UTC
Permalink
...
Post by alex
Almeno vorrei capire se il file
/volume1/homes/fittizio/.ssh/authorized_keys
viene preso in considerazione, o la sua presenza viene ignorata totalmente.
...
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is
SHA256:IqSuv7TlSguCnSXTveJAf9/Oe8OEytT7bMiGbvFdu8M.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
sign_and_send_pubkey: signing failed: agent refused operation
Il servizio sshd funziona, non conosce localhost, ti chiede se
continuare quindi lo aggiunge agli host fidati.
Poi da l'errore.
Prova a dare il comando "ssh-add" e ripeti il comando precedente.

angelo
alex
2016-12-16 16:54:29 UTC
Permalink
Post by angelo
Il servizio sshd funziona, non conosce localhost, ti chiede se
continuare quindi lo aggiunge agli host fidati.
Poi da l'errore.
Prova a dare il comando "ssh-add" e ripeti il comando precedente.
Allora andiamo con ordine

$ sudo apt-get install openssh-server
$ sudo service sshd start

Come mi hai indicato sull'altro ng, al posto di *sudo service ssh start*
ho dato il seguente comando:

$ sudo service sshd status
ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor
preset: enabled)
Active: active (running) since ven 2016-12-16 17:33:05 CET; 12min ago
Main PID: 22510 (sshd)
CGroup: /system.slice/ssh.service
└─22510 /usr/sbin/sshd -D

dic 16 17:33:05 comex systemd[1]: Starting OpenBSD Secure Shell server...
dic 16 17:33:05 comex sshd[22510]: Server listening on 0.0.0.0 port 22.
dic 16 17:33:05 comex sshd[22510]: Server listening on :: port 22.
dic 16 17:33:05 comex systemd[1]: Started OpenBSD Secure Shell server.
dic 16 17:33:23 comex systemd[1]: Started OpenBSD Secure Shell server.
dic 16 17:34:15 comex sshd[22603]: Connection closed by 127.0.0.1 port
46296 [preauth]
dic 16 17:45:31 comex systemd[1]: Started OpenBSD Secure Shell server.

Proviamo...

$ ssh -i ~/.ssh/id_rsa ***@localhost
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:tz+czJA3q9TTBkHUIl51/k160YaLEiAQch64VC2N5A8.
Please contact your system administrator.
Add correct host key in /home/rino/.ssh/known_hosts to get rid of this
message.
Offending ECDSA key in /home/rino/.ssh/known_hosts:3
remove with:
ssh-keygen -f "/home/rino/.ssh/known_hosts" -R localhost
ECDSA host key for localhost has changed and you have requested strict
checking.
Host key verification failed.
angelo
2016-12-16 17:22:44 UTC
Permalink
Post by alex
Post by angelo
Il servizio sshd funziona, non conosce localhost, ti chiede se
continuare quindi lo aggiunge agli host fidati.
Poi da l'errore.
Prova a dare il comando "ssh-add" e ripeti il comando precedente.
Allora andiamo con ordine
...
Proviamo...
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:tz+czJA3q9TTBkHUIl51/k160YaLEiAQch64VC2N5A8.
Please contact your system administrator.
Add correct host key in /home/rino/.ssh/known_hosts to get rid of this
message.
Offending ECDSA key in /home/rino/.ssh/known_hosts:3
ssh-keygen -f "/home/rino/.ssh/known_hosts" -R localhost
ECDSA host key for localhost has changed and you have requested strict
checking.
Host key verification failed.
Sono le paturnie di ssh: dopo che lo hai riavviato ha cambiato la sua
"fingerprint" e adesso teme un attacco (man-in-the-middle attack).
Post by alex
ssh-keygen -f "/home/rino/.ssh/known_hosts" -R localhost
Pero' non hai lanciato prima il comando "ssh-add" come avevo suggerito...

angelo
alex
2016-12-16 18:00:54 UTC
Permalink
Post by angelo
Sono le paturnie di ssh: dopo che lo hai riavviato ha cambiato la sua
"fingerprint" e adesso teme un attacco (man-in-the-middle attack).
Post by alex
ssh-keygen -f "/home/rino/.ssh/known_hosts" -R localhost
Pero' non hai lanciato prima il comando "ssh-add" come avevo suggerito...
Adesso forse ci siamo.

$ ssh -i ~/.ssh/id_rsa ***@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is SHA256:tz+czJA3q9TTBkHUIl51/k160YaLEiAQch64VC2N5A8.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-53-generic x86_64)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

49 pacchetti possono essere aggiornati.
34 sono aggiornamenti di sicurezza.


The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

***@comex:~$ exit
logout
Connection to localhost closed.

Per sicurezza riproviamo...

$ ssh -i ~/.ssh/id_rsa ***@localhost
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-53-generic x86_64)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

49 pacchetti possono essere aggiornati.
34 sono aggiornamenti di sicurezza.

Last login: Fri Dec 16 18:49:10 2016 from 127.0.0.1

Sembra funzionare.

Quindi abbiamo capito che le chiavi vanno bene?
angelo
2016-12-16 18:16:20 UTC
Permalink
Post by alex
Post by angelo
...
Pero' non hai lanciato prima il comando "ssh-add" come avevo
suggerito...
Adesso forse ci siamo.
...
Post by alex
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-53-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
49 pacchetti possono essere aggiornati.
34 sono aggiornamenti di sicurezza.
Last login: Fri Dec 16 18:49:10 2016 from 127.0.0.1
Sembra funzionare.
Quindi abbiamo capito che le chiavi vanno bene?
Direi che ci siamo. Hai lanciato prima il comando "ssh-add"?
Giusto per capire se puo' essere la causa dell'errore sul NAS.

angelo
alex
2016-12-16 18:37:03 UTC
Permalink
Post by angelo
Direi che ci siamo. Hai lanciato prima il comando "ssh-add"?
Si, ma mi pare che il comando che ha risolto sia stato
ssh-keygen -f ~/.ssh/known_hosts -R localhost
Post by angelo
Giusto per capire se puo' essere la causa dell'errore sul NAS.
+ scp ~/.ssh/id_rsa.pub
***@nas:/volume1/homes/fittizio/.ssh/authorized_keys

OK!!!

+ ssh -i ~/.ssh/id_rsa ***@nas
***@nas's password:
Permission denied, please try again.
Connection to nas closed.

OK, perchè giustamente non è un utente di sistema!!!

Ed infine

$ rsync -a -e 'ssh -i /home/rino/.ssh/id_rsa' /tmp/
***@nas:/volume1/homes/fittizio
***@nas's password:

OK!!!
Funziona ma chiede la solita password :(
angelo
2016-12-16 22:03:34 UTC
Permalink
Il 16/12/2016 19:37, alex ha scritto:
...
Post by alex
Ed infine
$ rsync -a -e 'ssh -i /home/rino/.ssh/id_rsa' /tmp/
OK!!!
Funziona ma chiede la solita password :(
Forse dovresti mettere in conto l'opzione di installare tutto daccapo.
Verificato che il PC non ha problemi con ssh, il problema sta sul nas e
io sono del parere che se una applicazione ha problemi non c'e' garanzia
del funzionamento al 100% di tutto il resto.

angelo
alex
2016-12-17 08:59:46 UTC
Permalink
Post by angelo
Forse dovresti mettere in conto l'opzione di installare tutto daccapo.
Verificato che il PC non ha problemi con ssh, il problema sta sul nas e
io sono del parere che se una applicazione ha problemi non c'e' garanzia
del funzionamento al 100% di tutto il resto.
Dovrei riformattare l'hard-disk del nas e reinstallare tutto?
angelo
2016-12-17 09:45:30 UTC
Permalink
Post by alex
Post by angelo
Forse dovresti mettere in conto l'opzione di installare tutto daccapo.
Verificato che il PC non ha problemi con ssh, il problema sta sul nas e
io sono del parere che se una applicazione ha problemi non c'e' garanzia
del funzionamento al 100% di tutto il resto.
Dovrei riformattare l'hard-disk del nas e reinstallare tutto?
Non necessariamente, qui indica come ripristinare il sistema operativo
senza perdere i dati, puoi cominciare da qui:

https://goo.gl/DtIVai

Comunque prima di partire metti in conto la possibilita' di non poterli
recuperare.

angelo
alex
2016-12-17 10:08:19 UTC
Permalink
Post by angelo
Non necessariamente, qui indica come ripristinare il sistema operativo
https://goo.gl/DtIVai
Comunque prima di partire metti in conto la possibilita' di non poterli
recuperare.
Sinceramente per ora non me la sento di trafficare su queste cose.
Continuerò ad usare la password, e magari apro un 3d specifico su rsync
(in combinazione con ssh).

Comunque se ti può servire

$ ssh -i ~/.ssh/id_rsa ***@nas -vvv
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, 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 "nas" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to nas [192.168.0.120] port 22.
debug1: Connection established.
debug1: identity file /home/rino/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/rino/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to nas:22 as 'fittizio'
debug3: hostkeys_foreach: reading file "/home/rino/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file
/home/rino/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from nas
debug3: order_hostkeyalgs: prefer hostkeyalgs:
ecdsa-sha2-nistp256-cert-***@openssh.com,ecdsa-sha2-nistp384-cert-***@openssh.com,ecdsa-sha2-nistp521-cert-***@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-***@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-***@openssh.com,ecdsa-sha2-nistp384-cert-***@openssh.com,ecdsa-sha2-nistp521-cert-***@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-***@openssh.com,ssh-rsa-cert-***@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos:
chacha20-***@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-***@openssh.com,aes256-***@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc:
chacha20-***@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-***@openssh.com,aes256-***@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos:
umac-64-***@openssh.com,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,hmac-sha2-512-***@openssh.com,hmac-sha1-***@openssh.com,umac-***@openssh.com,umac-***@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-***@openssh.com,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,hmac-sha2-512-***@openssh.com,hmac-sha1-***@openssh.com,umac-***@openssh.com,umac-***@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,***@openssh.com,zlib
debug2: compression stoc: none,***@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-***@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos:
aes128-ctr,aes192-ctr,aes256-ctr,aes128-***@openssh.com,aes256-***@openssh.com,chacha20-***@openssh.com
debug2: ciphers stoc:
aes128-ctr,aes192-ctr,aes256-ctr,aes128-***@openssh.com,aes256-***@openssh.com,chacha20-***@openssh.com
debug2: MACs ctos:
umac-64-***@openssh.com,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,hmac-sha2-512-***@openssh.com,hmac-sha1-***@openssh.com,umac-***@openssh.com,umac-***@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-***@openssh.com,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,hmac-sha2-512-***@openssh.com,hmac-sha1-***@openssh.com,umac-***@openssh.com,umac-***@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,***@openssh.com
debug2: compression stoc: none,***@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-***@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-***@openssh.com MAC:
<implicit> compression: none
debug1: kex: client->server cipher: chacha20-***@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:RnhzaaLRdBJCr6vQtPoKjANyWeHEup3AautdnRGnwUM
debug3: hostkeys_foreach: reading file "/home/rino/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file
/home/rino/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from nas
debug3: hostkeys_foreach: reading file "/home/rino/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file
/home/rino/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from 192.168.0.120
debug1: Host 'nas' is known and matches the ECDSA host key.
debug1: Found key in /home/rino/.ssh/known_hosts:1
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
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/rino/.ssh/id_rsa (0x556672370b80), explicit, agent
debug3: send packet: type 5
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/rino/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
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
***@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 nas ([192.168.0.120]: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-***@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-***@openssh.com
want_reply 0
debug3: receive packet: type 4
debug1: Remote: Ignored authorized keys: bad ownership or modes for file
/volume1/homes/fittizio/.ssh/authorized_keys
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 GNOME_KEYRING_PID
debug3: Ignored env UPSTART_INSTANCE
debug3: Ignored env LANGUAGE
debug3: Ignored env USER
debug3: Ignored env XDG_SEAT
debug3: Ignored env SESSION
debug3: Ignored env COMPIZ_CONFIG_PROFILE
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env SHLVL
debug3: Ignored env QT4_IM_MODULE
debug3: Ignored env HOME
debug3: Ignored env OLDPWD
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env XDG_SEAT_PATH
debug3: Ignored env QT_LINUX_ACCESSIBILITY_ALWAYS_ON
debug3: Ignored env GTK_MODULES
debug3: Ignored env INSTANCE
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env GNOME_KEYRING_CONTROL
debug3: Ignored env MANDATORY_PATH
debug3: Ignored env QT_QPA_PLATFORMTHEME
debug3: Ignored env IM_CONFIG_PHASE
debug3: Ignored env SESSIONTYPE
debug3: Ignored env UPSTART_JOB
debug3: Ignored env LOGNAME
debug3: Ignored env GTK_IM_MODULE
debug3: Ignored env WINDOWID
debug3: Ignored env DEFAULTS_PATH
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env TERM
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env GTK2_MODULES
debug3: Ignored env PATH
debug3: Ignored env GDM_LANG
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env XDG_MENU_PREFIX
debug3: Ignored env XDG_SESSION_PATH
debug3: Ignored env DISPLAY
debug3: Ignored env COMPIZ_BIN_PATH
debug1: Sending env LANG = it_IT.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env XAUTHORITY
debug3: Ignored env XDG_SESSION_DESKTOP
debug3: Ignored env XMODIFIERS
debug3: Ignored env XDG_GREETER_DATA_DIR
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env SHELL
debug3: Ignored env GDMSESSION
debug3: Ignored env QT_ACCESSIBILITY
debug3: Ignored env UPSTART_EVENTS
debug3: Ignored env UPSTART_SESSION
debug3: Ignored env GPG_AGENT_INFO
debug3: Ignored env XDG_VTNR
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env PWD
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env CLUTTER_IM_MODULE
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env VTE_VERSION
debug3: Ignored env JOB
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 87380
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Permission denied, please try again.
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 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 ***@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> 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 nas closed.
Transferred: sent 2508, received 2652 bytes, in 0.1 seconds
Bytes per second: sent 36750.5, received 38860.6
debug1: Exit status 1

Loading...