Newsgroup: it.comp.os.linux.iniziare
Titolo: ssh: la fingerprint viene aggiunta a ~/.ssh/known_hosts

$ rsync -nav gdf nas:/volume1/public/abc
The authenticity of host 'nas (192.168.1.120)' can't be established.
ECDSA key fingerprint is BLABLABLA
Are you sure you want
  to continue connecting (yes/no/[fingerprint])? BLABLABLA
Warning: Permanently added 'nas,192.168.1.120' (ECDSA) to the list of 
known hosts.
 
Così da ora in poi non mi vene più chiesta.
Però se lascio il computer a qualche furbetto...
Insomma, non si può evitare?
È una cosa comoda, ma preferisco digitare l'impronta manualmente.

Il 06/11/21 12:26, Happy3D ha scritto:

Questa e' la fingerprint del server a cui ti stai connettendo, serve a 
garantire che ti stai connettendo al server giusto.
Se hai cambiato l'indirizzo IP del NAS nel file ~/.ssh/known_hosts non 
c'e' il riferimento al nuovo indirizzo e quindi chiede conferma della 
identita' del server.
Qual'e' esattamente il tuo problema?
Giusto per farti un'idea di che cosa devi digitare come fingerprint:
 
192.168.111.4 ecdsa-sha2-nistp521 
AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBABK/eC4HKs7G0K1kE/wqtEZcn7b5xL5H2B9TVvKYDT2o7YDwes6cF0R/tX8qNwiYjurWcton0+ck7PJkPpL3rpcPAHFBGahuk1AV/melWOLzN9ydRH8H0r+nl3mULM0bQzmcB/QLTxQoAcJfai/JKRYNrYmk4wc3L8aRsNySHPvm8KEPQ==
 
angelo

 È una cosa comoda, ma preferisco digitare l'impronta manualmente.
 
non ha senso.
 

 Qual'e' esattamente il tuo problema?
 
$ ssh-add
Enter passphrase:
$ rsync ... nas:/...
E fin qui va bene.
 
Ma ho paura che qualche script maligno possa farmi qualche scherzo, 
usando ad esempio rsync in modo distruttivo, ad esempio
 
$ rsync -a --delete /dev/null nas:/...
 
Si, dicono che linux sia relativamente immune ai virus. Ma sinceramente 
non so fino a quanto.
 
Una soluzione sarebbe dare il comando ssh-add -d (che non sempre 
funziona: vedere il thread *chiave ssg non rimossa*) appena possibile.
Oppure rinunciare alle chiavi rsa, ed usare l'autenticazione 
tradizionale, cioè digitare ogni volta user/password.
Una seccatura...

Il 06/11/21 14:08, rootkit ha scritto:

mi sa che hai ragione, vedi l'altra risposta

 Una seccatura...
 
Le chiavi RSA sono considerate il metodo
piu` sicuro.
 
bye,
 
-- 
 
piergiorgio

 piu` sicuro.
 
Dipende sotto quale aspetto, e da chi e come vengono gestite.

 Dipende sotto quale aspetto, e da chi e come vengono gestite.
 
Sotto l'aspetto che sono considerate
piu` sicure.
 
Mi apre molto semplice, come concetto.
 
bye,
 
-- 
 
piergiorgio

 piu` sicure.
 
Sono più robuste agli attacchi da remoto: senza chiave privata si può 
fare ben poco.
Ma se il codice malevolo viene eseguito da locale (previo insediamento) 
eheeheh...
Basta aspettare che qualcuno dia il fatidico comando (di solito facendo 
dei tentativi ad intervalli regolari)
 
$ ssh-add
 
e la porta è aperta

 e la porta è aperta
 
Di nuovo, se e` in locale, hai gia`
perso, puo` fare quello che vuole.
Al punto che la chiave condivisa e`
_ancora_ piu` sicura della password.
 
bye,
 
-- 
 
piergiorgio

 e la porta è aperta
 
No, se non metti nel server in  ~/.ssh/authorized_keys la chiave 
pubblica id_rsa.pub
Basta che utilizzi solo chiavi private protette da password in modo che 
quando lanci ssh-add <chiave_privata_protetta> ti chiede la password e 
anche quando lanci rsync te la chiede.
 
angelo

Il 07/11/21 09:56, angelo ha scritto:

Per la precisione, se lanci rsync con una chiave che non e' passata per 
  ssh-add ti chiede la password.
 
angelo

Il 07/11/21 09:59, angelo ha scritto:

Post-precisazione, con ssh-keygen puoi anche proteggere con password la 
id-rsa.
 
angelo

 Di solito? Quanti ne hai visti?
 
Oh ma sono metodologie che esistono, che c'è da vedere?
Per capire come funzionano certe cose non c'è sempre bisogno di un 
osservazione diretta, per l'appunto.
Può bastare anche una buona conoscenza teorica.
 
"Due più due fa quattro.
Dove l'hai visto?"
o_o
 

 spiegato nell'altro post).
 
Qui pero' siamo all'ABC della sicurezza, se lasci le directory remote 
sempre montate, se lasci le chiavi nell'agent se lasci un PC incustodito 
senza blocco a tempo dello schermo nemmeno Linux ti salva...
 
angelo

 anche quando lanci rsync te la chiede.
 
Si.
Ma solo la prima volta.
Se poi non ti ricordi di rimuovere la chiave (o non disattivi del tutto 
la memorizzazione) la porta rimane aperta.

 Dove l'hai visto?"
 
Tu hai proprio capito tutto.
2+2=4 non e` assiomatico, si dimostra.
Senza contare che 2+2=11 potrebbe anche
essere corretto.
Ma questa e` matematica, non informatica,
dove, citando Knuth, si deve testare la
correttezza, la dimostrazione non basta.
 
bye,
 
-- 
 
piergiorgio

 la memorizzazione) la porta rimane aperta.
 
Non usare ssh-add allora, indichi la chiave nel parametro "-i <user>" e 
usi una chiave protetta.
Puoi anche decidere di selezionare a quali chiavi sia consentito 
l'accesso da locale e quali da remoto con la direttiva:
 
     Match Address 
192.168.1.0/24
 
     AuthorizedKeysFile	.ssh/authorized_local_keys
 
nel file di configurazione: /etc/ssh/sshd_config; nel file 
"authorized_local_keys" metti le chiavi pubbliche degli utenti locali 
autorizzati mentre in authorized_keys limitare solo quelle per l'accesso 
remoto. O anche lasciarlo vuoto se non vuoi accessi da remoto.
 
angelo

 e la porta è aperta
 
beh io ad esempio pur essendo comodo evito di caricare le identità 
sull'agent specie quelle che mi fanno accedere a server importanti. c'è 
l'opzione -i e in più le chiavi più sensibili sono protette da pwd. 
 
certo l'uso dell'agent è un abbassamento della sicurezza, tant'è vero che 
uno dovrebbe limitare il tempo di permanenza allo stretto necessario (c'è 
l'apposita opzione, sia sull'agent che ssh-add).

 Non mi sembra una strategia sana...
 
Cerco di difendermi da entrambi
 

 Io no.
 
La sperimentazione esiste, non personale,
ma esiste.
 
Tu, invece, non hai risposto alla domanda.
Hai solo scritto che "e` possibile in teoria",
ma non hai portato alcuni caso pratico in
cui sia successo a qualcuno.
Infatti la domanda era "quanti ne hai visti",
non "quanti ti sono capitati personalmente".
 
Se qualcuno e` in grado di eseguire un programma
qualunque a nome dell'utente, ancora una volta,
si e` gia` perso.
Quindi tutto il discorso che fai e` inutile.
 
Password o chiave condivisa od altro non ti
salvano.
Devi evitare l'accesso in primis.
 
bye,
 
-- 
 
piergiorgio

 Si. Con un certo numero di sonde.
 
Ma non di persona: per il momento l'abbiamo fatto in sicurezza.
 

 privata non serve a niente.
 
Naturalmente però il discorso non vale se è proprio il server ad essere 
infettato (come ho detto più volte).
Se nella sua pancia è già attivo qualche batterio (script che è stato 
iniettato in qualche modo).


e vabbeh, se il server è già compromesso il discorso diventa proprio lana 
caprina.
 

 
 
L'opzione sarebbe -t?
In questo caso non sarebbe necessario neanche usare autofs, no?

 iniettato in qualche modo).
 
Ma di che cosa stai parlando? Di un attacco da remoto su un server gia' 
compromesso? Che senso ha?
 
angelo

 In questo caso non sarebbe necessario neanche usare autofs, no?
 
scusa mi sono perso qualcosa: che c'azzecca autofs?

Il 08/11/21 11:01, angelo ha scritto:

Di attacchi remoti non ho mai parlato, o meglio, la questione è sorta 
durante la discussione, ma non è partita da me, se non sbaglio...

Il 08/11/21 10:37, rootkit ha scritto:

E appunto.
Infatti queste discussione verte prima di tutto sulla sicurezza locale.
Poi ci siamo allargati sugli attacchi interstellari :)

 In questo caso non sarebbe necessario neanche usare autofs, no?
 
Scusate questa è un'altra cosa (riguarda il montaggio) :)

 Poi ci siamo allargati sugli attacchi interstellari :)
 
chiaro. ma se parliamo di sicurezza delle chiavi ssh è fisiologico 
parlare di sicurezza sugli accessi a server remoti, perché a quello 
servono...
 
 

 accedere ad un server.
 
O volendo anche con rsync
 
$ rsync -e 'ssh -i <chiave-privata>'
 
Giusto?
 


si.

 funziona: vedere il thread *chiave ssg non rimossa*) appena possibile.
 
 
In quel thread ti ho scritto che ssh-add -D non cancella le chiavi
caricate automaticamente dall'agent ma le blocca, il che vuol dire che
dopo aver dato quel comando non puoi più usare le chiavi presenti in
.ssh . Hai verificato o no se quanto ho scritto è vero?
 

 
 
Che devo verificare?
Come ho già detto, secondo me dipende dalla giornata.
Se piove le cosa funzionano in un modo, se c'è il sole, in un altro.
Se è giovedì ad esempio, la passphrase rimane memorizzata anche se 
riavvio il computer.
Ma anche se non è memorizzata a volte l'accesso è garantito ugualmente.
 
E se dovessi rinascere farei l'artigiano o il contadino. Questa 
tecnologia serve solo a complicare la vita.

 forse...
 
Nel thread 'rsync: ssh non chiede la passphrase' ti avevo suggerito di
provare con
ssh-agent -k
e poi quando vuoi nuovamente l'agent
eval $(ssh-agent -s)
ma anche in quel caso scena muta da parte tua ...
 

 
 
Proverò anche così.
Ma anche qui ci vorrebbe un po' di trasparenza.
Mica si capisce bene come le gestisce (le chiavi) questo *fantomatico* 
agente.