Buondi' Alessandro,

non sono certo di aver capito correttamente il quesito, quindi ti chiedo

a) i due host sono raggiungibili via SSH SOLO tramite scambio di certificati quindi tutti gli host autorizzati hanno la chiave in locale

o

b) l'accesso SSH e' libero tramite pw ?

se a) a mio avviso ti stai complicando la vita per niente

se b) la faccenda e' diversa e merita una riflessione piu' approfondita oppure una gabola del tipo

sia pluto l'utente di manutenzione

sia pippo l'utente che fa rsync da host1 a host2

crea utente topolino che fa il rsync alla rovescia usando i tuoi comandi

Quanto sopra ammesso che abbia capito giusto e non fischi per fiaschi

Cordialita'


Il 22/01/26 18:38, Alessandro Baggi ha scritto:
Un saluto a tutta la lista.

Ho un piccolo server remoto sul quale carico dei file tramite rsync+ssh utilizzando una chiave privata con utente diverso da quello con cui effettuo la manutenzione.

I due nodi sono entrambi con Debian 13.

Volevo rendere l'accesso con questa chiave più ristretto, ovvero poter lanciare solo il comando desiderato. Quando rsync invia i dati richiama sull'host remoto "rsync --server -slHogDtpArze.iLsfxCIvu" e l'ho inserito in command="..." all'interno di authorized_keys. Quindi quando lancio rsync+ssh con quella specifica chiave mi permette solo di lanciare il comando "rsync --server...." e tutto funziona bene

Ogni tanto, risincronizzo al contrario il dataset, ma in questo caso rsync richiama sull'host remoto "rsync --server --sender -slHogDtpArze.iLsfxCIvu" che non corrisponde al comando riportato sulla chiave in authorized_keys.

Considerato che a ogni chiave ssh può essere associato un singolo comando, dovrei usare una chiave separata per il push e una per il pull dei dati utilizzando sempre lo stesso utente.

A questo punto mi chiedo: ha senso creare due chiavi private per lo stesso utente con restrizione sul comando (questo migliora la sicurezza?) oppure mi sto complicando la vita e basta?

Grazie a tutti per la pazienza.

Saluti,
Alessandro.

--
Mario Vittorio Guenzi
E-mail [email protected]
Si vis pacem, para bellum

Rispondere a