accedere al nas Synology tramite ssh e senza password

[alex]

+ 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
admin@nas:/volume1/homes/fittizio/.ssh/authorized_keys
admin@nas's password:
test.pub 100% 392 0.4KB/s
00:00

Adesso vediamo se funziona

+ ssh -i /tmp/le_mie_chiavi/test fittizio@nas
fittizio@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]

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]

Il 15/12/2016 10:26, angelo ha scritto:
>
> 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

> 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]

Il 15/12/2016 16:08, alex ha scritto:
> Il 15/12/2016 10:26, angelo ha scritto:
>>
>> 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...

>> 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]

Il 15/12/2016 19:15, angelo ha scritto:
>
> 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]

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]

Il 15/12/2016 21:15, angelo ha scritto:
>
> 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]

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]

Il 15/12/2016 22:01, angelo ha scritto:
> 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?

> 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 fittizio@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)?

> 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à?

> Per come la vedo io dovresti provare a resettare tutto e ripartire da zero.

Dovrei riformattare e reinstallare il DSM?
o_O

[angelo]

Il 16/12/2016 08:23, alex ha scritto:
> ...

>
> 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".
> La chiave finisce con fittizio@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)?

No, e' solo una stringa, l'identificativo della chiave. Puoi cambiarlo senza problemi.

>> 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...

>> 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]

Il 16/12/2016 12:05, angelo ha scritto:
> Il 16/12/2016 08:23, alex ha scritto:
>> ...
>>
>> 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 fitt...@192.168.0.120

per vedere cosa succede?

>> ...
>> 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 fittizio@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)?
>
> 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'è?

> 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.

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 test@localhost
ssh: connect to host localhost port 22: Connection refused

[angelo]

Il 16/12/2016 12:34, alex ha scritto:
...

>
> OK.
> Ma allora perchè su it.*iniziare mi avevi chiesto di dare il comando
>
> ssh -i /home/xxx/Documenti/fittizio_keys/id_rsa fitt...@192.168.0.120
>
> 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.

>
>>> ...

>>
>> 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.

>> 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 test@localhost
> 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]

Il 16/12/2016 13:00, angelo ha scritto:
> Il 16/12/2016 12:34, alex ha scritto:
> ...
>>
>> OK.
>> Ma allora perchè su it.*iniziare mi avevi chiesto di dare il comando
>>
>> ssh -i /home/xxx/Documenti/fittizio_keys/id_rsa fitt...@192.168.0.120
>>
>> 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.

>>> 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 test@localhost
>> 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]

Il 16/12/2016 13:25, alex ha scritto:
> ...

> 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.

>
> 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]

Il 16/12/2016 14:42, angelo ha scritto:
> Il 16/12/2016 13:25, alex ha scritto:
>> ...
>> 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.

>> 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 test@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
test@localhost's password:

[angelo]

Il 16/12/2016 17:02, alex ha scritto:
> Il 16/12/2016 14:42, angelo ha scritto:

...

> Almeno vorrei capire se il file
> /volume1/homes/fittizio/.ssh/authorized_keys
> viene preso in considerazione, o la sua presenza viene ignorata totalmente.

> ...

>
> $ ssh -i ~/.ssh/id_rsa test@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
> test@localhost's password:

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]

Il 16/12/2016 17:31, angelo ha scritto:
>
> 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 test@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]

Il 16/12/2016 17:54, alex ha scritto:
> Il 16/12/2016 17:31, angelo ha scritto:
>>
>> 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...
>
> $ ssh -i ~/.ssh/id_rsa test@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.

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).
Niente di che, ti dice anche come rimediare:

> remove with:
> ssh-keygen -f "/home/rino/.ssh/known_hosts" -R localhost

Pero' non hai lanciato prima il comando "ssh-add" come avevo suggerito...

angelo

[alex]

Il 16/12/2016 18:22, angelo ha scritto:
>
> 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).
> Niente di che, ti dice anche come rimediare:
>
>> remove with:
>> 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 test@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.

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

Per sicurezza riproviamo...

$ ssh -i ~/.ssh/id_rsa test@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]

Il 16/12/2016 19:00, alex ha scritto:
>>...

>> Pero' non hai lanciato prima il comando "ssh-add" come avevo
>> suggerito...
>
> Adesso forse ci siamo.

...
>
> $ ssh -i ~/.ssh/id_rsa test@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?

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]

Il 16/12/2016 19:16, angelo ha scritto:
>
> 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

> Giusto per capire se puo' essere la causa dell'errore sul NAS.

+ scp ~/.ssh/id_rsa.pub
admin@nas:/volume1/homes/fittizio/.ssh/authorized_keys

OK!!!

+ ssh -i ~/.ssh/id_rsa fittizio@nas

fittizio@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/
fittizio@nas:/volume1/homes/fittizio
fittizio@nas's password:

OK!!!
Funziona ma chiede la solita password :(

[angelo]

Il 16/12/2016 19:37, alex ha scritto:
...

> Ed infine
>
> $ rsync -a -e 'ssh -i /home/rino/.ssh/id_rsa' /tmp/
> fittizio@nas:/volume1/homes/fittizio
> fittizio@nas's password:
>
> 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]

Il 16/12/2016 23:03, angelo ha scritto:
>
> 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]

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]

Il 17/12/2016 10:45, angelo ha scritto:
>
> 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.

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 fittizio@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-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@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:
curve255...@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-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed2551...@openssh.com,ssh-rsa-...@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos:
chacha20...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc:
chacha20...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos:
umac-...@openssh.com,umac-1...@openssh.com,hmac-sha...@openssh.com,hmac-sha...@openssh.com,hmac-s...@openssh.com,uma...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-...@openssh.com,umac-1...@openssh.com,hmac-sha...@openssh.com,hmac-sha...@openssh.com,hmac-s...@openssh.com,uma...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zl...@openssh.com,zlib
debug2: compression stoc: none,zl...@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:
curve255...@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,aes12...@openssh.com,aes25...@openssh.com,chacha20...@openssh.com
debug2: ciphers stoc:
aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com,chacha20...@openssh.com
debug2: MACs ctos:
umac-...@openssh.com,umac-1...@openssh.com,hmac-sha...@openssh.com,hmac-sha...@openssh.com,hmac-s...@openssh.com,uma...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-...@openssh.com,umac-1...@openssh.com,hmac-sha...@openssh.com,hmac-sha...@openssh.com,hmac-s...@openssh.com,uma...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zl...@openssh.com
debug2: compression stoc: none,zl...@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve255...@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
fittizio@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 hostk...@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 e...@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