Sto provando a configurare chroot'd rsync


10

Sto cercando di configurare un server di backup. Voglio chroot ogni utente (client) nella sua home directory e permettergli solo di usare sftp e rsync .

Ho scoperto rapidamente che non ero il solo a provare a fare qualcosa del genere, e ho trovato questa guida e l'ho seguita. Quindi ora ho utenti chroot solo con sftp.

Poi ho scoperto che rsync ha bisogno di ssh per spawnarsi sull'altra macchina e che sftp non è abbastanza. Dare ad ogni utente un login ssh è qualcosa che volevo evitare in primo luogo.

Qualcuno può pensare ad alcune possibili soluzioni?

Grazie,

marchio


Dai

Risposte:


11

Una soluzione sftp richiederebbe anche un login ssh per tutti, quindi non hai davvero perso nulla qui. Concedere l'accesso ssh non implica necessariamente l'accesso completo alla shell, ad esempio, questo mostra come usare il authorized_keysfile ssh per consentire il backup tramite rsync limitando i comandi disponibili solo al ricevitore rsync.

In effetti, se si opta per l'autenticazione basata su chiave, piuttosto che per l'autenticazione tramite password (cosa che si dovrebbe), è quindi possibile eseguire tutto con un account utente anziché richiedere più account. Dovresti usare i tasti per identificare gli utenti remoti e dirigere il ricevitore rsync in una particolare directory.

Qualcosa del genere, nel tuo authorized_keysfile:

command="/usr/bin/rsync --server -a . /tmp/user1" ssh-rsa ... user1
command="/usr/bin/rsync --server -a . /tmp/user2" ssh-rsa ... user2

Qualcuno che utilizza la user1chiave privata eseguirà il backup /tmp/user1e qualcuno che utilizza la user2chiave privata eseguirà il backup /tmp/user2. E così via...


Il link è andato 404.
luckydonald

Ho aggiornato il link.
Larks

6

Esegui normalmente rsyncdal client al server remoto, ma aggiungi ulteriori opzioni dettagliate SSH -v:, quindi grep per Sending command. Vedrai il comando esatto che il client sta inviando al server remoto:

rsync -avz -e'ssh -v -i /ssh-keys/clientprivate.key' --bwlimit=8000 --delete root@server:/path/ /backup/myserver/ 2>&1 | grep "Sending command"

Nel mio caso, lo era

rsync --server -vvlogDtprze.iLsf --bwlimit=8000 --delete . /path

Aggiungilo command="..."al /home/USER/.ssh/authorized_keysfile del server remoto come indicato da @larsks. Aggiungi impostazioni di sicurezza aggiuntive, se necessario:

no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2..CPhIJ+LVULWz arnis@server

Tutti insieme:

command="rsync --server -vvlogDtprze.iLsf --bwlimit=8000 --delete . /backup/path",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2..CPhIJ+LVULWz arnis@server

(Tratto da un ottimo tutorial http://en.positon.org/post/Rsync-command-restriction-over-SSH )


Buona 1a risposta.
slm

2

Sarà necessario fornire una qualche forma di accesso alla shell per poter utilizzare rsync a meno che non ci si colleghi direttamente al server rsync - la porta predefinita è 873 (TCP).

Dalla pagina man di rysnc :

Esistono due modi diversi per rsync di contattare un sistema remoto: usare un programma di shell remota come trasporto (come ssh o rsh) o contattare un demone rsync direttamente tramite TCP. Il trasporto della shell remota viene utilizzato ogni volta che il percorso di origine o destinazione contiene due punti (separatore :) dopo una specifica dell'host. Il contatto con un demone rsync si verifica direttamente quando il percorso di origine o di destinazione contiene due punti (due :) separatore dopo una specifica dell'host, O quando viene specificato un URL rsync: // (vedere anche le funzionalità lqUSING RSYNC-DAEMON VIA UN TELECOMANDO Sezione CONNECTIONrq per un'eccezione a quest'ultima regola).

Per fornire un accesso limitato alla shell, considerare la seguente guida . (Nota: il link originale è morto) Riepilogo:

Questa configurazione combina le migliori funzionalità di rsync, SSH e chroot. Rsync offre la flessibilità e l'efficienza nel trasferimento dei file, SSH protegge i dati trasferiti e chroot protegge i dati sul server da accessi non autorizzati. Il dummysh limita l'accesso solo a rsync.

Mentre il server rsync implementa chroot, manca della protezione SSH che è spesso richiesta. Inoltre, l'apertura di una porta server rsync aggiuntiva presenta un rischio per la sicurezza e talvolta non è possibile né tecnicamente né politicamente. Sftp e scp mancano della flessibilità e dell'efficienza fornite da rsync, specialmente quando è coinvolto un albero di directory, come un sito Web.

Oppure dare un'occhiata a utilizzando rssh (c'è una guida per la creazione di rssh qui ):

rssh è una shell limitata per l'uso con OpenSSH, che consente solo scp e / o sftp. Ora include anche il supporto per rdist, rsync e cvs. Ad esempio, se si dispone di un server per il quale si desidera consentire agli utenti solo di copiare i file tramite scp, senza fornire l'accesso alla shell, è possibile utilizzare rssh per farlo.


1
La notizia attuale è che rssh non viene mantenuto e presenta qualche buco nella sicurezza. Controlla lo stato corrente prima di investire in esso.
Chutz,

2
Puoi usare lo script perl rrsyncinvece di rssh, incluso nel pacchetto ufficiale rsync. Vedi derek.simkowiak.net/backing-up-multiple-servers-with-rsnapshot
unhammer

0

puoi scrivere una shell che avvolge rsync.

guarda l'idea generale qui: https://sixohthree.com/1458/locking-down-rsync-using-ssh

nella tua shell avvolgente puoi fare quello che vuoi e forse chroot l'utente.

Nel mio caso avevo bisogno di attivare l'account virtuale usando lo stesso utente * nix. Riesco a farlo usando questo tipo di shell più molte righe nel file authorized_keys. Non ho eseguito il chrooting dell'utente ma ho aggiunto un livello di cartella utente nel comando server rsync.

guarda l' utente di processo in modo diverso usando il tasto ssh


0

SFTP con funzionalità Rsync, senza shell

È possibile utilizzare LFTP + SFTP in un ambiente chroot e ottenere gli stessi risultati dell'utilizzo di rsync, senza fornire all'utente una shell o eseguire pesanti personalizzazioni in ssh con wrapper.

Questo è più sicuro e può essere sostanzialmente più veloce.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.