Come limitare l'accesso degli utenti SSH a directory specifiche su Ubuntu 24.04 (Guida SFTP Chroot)

Concedere a un collaboratore esterno l'accesso per caricare alcuni file non dovrebbe automaticamente garantirgli una sessione terminale con accesso all'intero server. Su Ubuntu 24.04 LTS, OpenSSH può limitare un account di trasferimento file a una directory specifica tramite una ChrootDirectoryregola e il server integrato internal-sftp. La differenza fondamentale è che si tratta di una restrizione valida solo per SFTP , non di un semplice metodo per fornire una shell Bash completamente funzionale ma isolata.

Questa guida spiega cosa proteggono realmente le impostazioni, quindi illustra una configurazione reversibile in otto fasi per più account, ognuno con la propria directory. I comandi utilizzano un account di esempio chiamato contractore un host di esempio chiamato server.example.com; sostituiteli con i vostri valori. Questi sono esempi di configurazione, non risultati dichiarati di un test su un server reale.

Di che tipo di restrizione hai effettivamente bisogno?

Spesso si confondono tre comandi. I permessi di Linux determinano quali file un account può leggere o modificare; la modifica della directory home dell'account imposta una posizione iniziale; un chroot modifica la directory radice del filesystem presentata a un processo. Non sono intercambiabili.

Errore comune: impostare /home/contractoruna directory come home confina l'utente in quella posizione. Non è così. Un normale utente della shell può spostarsi in qualsiasi altra directory accessibile sul filesystem. Se l'esigenza effettiva è lo scambio di file, scegliete il metodo SFTP descritto di seguito, anziché tentare di nascondere le directory tramite il prompt della shell.

Documenti OpenSSH ChrootDirectorye Matchnel ForceCommandmanuale ufficiale di sshd_config di Ubuntu 24.04 .

Configura un jail di directory solo SFTP in otto fasi

Prima di modificare SSH da remoto, mantieni aperta la sessione di amministratore corrente e assicurati di avere accesso alla console o alla modalità di ripristino. Utilizza un account separato senza privilegi per i trasferimenti; non aggiungere il tuo account di amministratore al gruppo con restrizioni.

1. Verifica OpenSSH e mantieni una sessione di ripristino

Sul server, installa OpenSSH se necessario, verifica il servizio e salva la configurazione principale. La documentazione ufficiale di Ubuntu per i server supporta questi percorsi di servizio e configurazione.

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.pre-sftp

Se puoi amministrare la macchina solo tramite SSH, non chiudere la sessione corrente durante la modifica o il test. Consulta la guida alla configurazione del server OpenSSH di Ubuntu prima di modificare il demone.

2. Creare un utente dedicato e un gruppo di accesso SFTP

Un gruppo è utile quando si prevede più di un account con restrizioni. Questo esempio assegna a ciascun membro un ambiente isolato (jail) separato utilizzando il %utoken, che OpenSSH espande nel nome utente di connessione. Il /uploadpercorso home dovrebbe trovarsi all'interno del futuro ambiente chroot, quindi non creare una /uploaddirectory a livello di host.

sudo groupadd sftpclients
sudo adduser --home /upload --no-create-home --shell /usr/sbin/nologin contractor
sudo usermod -aG sftpclients contractor
id contractor

Il adduserflusso potrebbe richiedere l'assegnazione di una password. Nelle installazioni che disabilitano l'autenticazione tramite password SSH, creare e autorizzare invece una chiave pubblica; non abilitare l'accesso tramite password a livello globale solo per seguire un esempio. La nologinshell rappresenta un'ulteriore misura di sicurezza, ma internal-sftpè il comando imposto che rende questa configurazione trasferibile. Testare la combinazione sul proprio stack di autenticazione.

3. Creare una directory chroot di proprietà di root

È qui che molte guide sbagliano. OpenSSH richiede che ogni componente del percorso chroot sia di proprietà di root e non scrivibile da altri utenti o gruppi. Non rendere mai scrivibile la directory root del jail dall'account SFTP.

sudo install -d -o root -g root -m 0755 /srv/sftp
sudo install -d -o root -g root -m 0755 /srv/sftp/contractor
namei -l /srv/sftp/contractor

Controlla anche i componenti esistenti /; /srvi comandi sopra riportati non riparano automaticamente le autorizzazioni padre non sicure. Se un componente è scrivibile dal gruppo o di proprietà dell'utente, correggine la proprietà e la modalità solo dopo aver verificato se altre applicazioni dipendono da esso.

4. Aggiungere una sottocartella scrivibile all'interno della prigione

L'account può scrivere in una directory figlia senza essere autorizzato a modificare la directory radice chroot. Creare /srv/sftp/contractor/uploadper i file effettivi dell'account; dall'interno di SFTP, questo apparirà come /upload.

sudo install -d -o contractor -g contractor -m 0750 /srv/sftp/contractor/upload
sudo stat -c '%U:%G %a %n' /srv/sftp/contractor /srv/sftp/contractor/upload

La proprietà prevista è volutamente diversa: root:rootper la directory principale del jail e contractor:contractorper la cartella di caricamento scrivibile. Evitare chmod 777, che introdurrebbe un'esposizione non necessaria e verrebbe rifiutato se applicato alla directory principale del jail.

5. Aggiungi una regola di corrispondenza a sshd_config

Apri /etc/ssh/sshd_confige aggiungi il seguente blocco alla fine, dopo eventuali direttive e Matchblocchi esistenti. Usa un editor di testo come sudoedito sudo nano. Rivedi Matchprima le regole esistenti: se più blocchi corrispondenti assegnano la stessa parola chiave, OpenSSH usa la prima istanza applicabile. Ubuntu elabora anche i file in /etc/ssh/sshd_config.d/da una versione precedente di Include; le regole lì presenti potrebbero influire sulla precedenza.

Match Group sftpclients
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /upload
    PermitTTY no
    DisableForwarding yes

Match Groupprende di mira i membri di sftpclients. ChrootDirectoryposiziona ogni utente sotto /srv/sftp/USERNAME. ForceCommand internal-sftp -d /uploadesegue un servizio SFTP in-process e inizia all'interno della directory scrivibile. PermitTTY noimpedisce l'allocazione del terminale, mentre DisableForwarding yesdisabilita le funzionalità di inoltro SSH per le connessioni corrispondenti.

Mantieni la direttiva globale Subsystem sftpgià fornita da Ubuntu, a meno che tu non abbia un motivo specifico per modificarla; il comando SFTP interno forzato non richiede la sostituzione di quella riga globale. Non aggiungere una direttiva globale extra Match Allsolo per terminare un blocco senza comprenderne le conseguenze.

6. Verificare la sintassi e le impostazioni effettive prima di ricaricare

Il successo del parsing non dimostra che i permessi del jail siano corretti, né che l'account previsto corrisponda alla policy. Eseguire entrambi i controlli esplicitamente.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=contractor,host=localhost,addr=192.0.2.10 | grep -E '^(chrootdirectory|forcecommand|permittty|disableforwarding) '
namei -l /srv/sftp/contractor

La configurazione corretta dovrebbe specificare il percorso chroot desiderato, il comando SFTP forzato, l'allocazione TTY disabilitata e le restrizioni di inoltro. L'indirizzo di esempio 192.0.2.10è solo a scopo documentativo; se si utilizzano regole dipendenti dall'indirizzo Match, sostituirlo con l'indirizzo sorgente del client reale. Il -T -Cformato è documentato nel manuale di sshd per Ubuntu 24.04 .

Se la convalida fallisce, correggi la configurazione prima di ricaricare SSH. Se i valori effettivi non sono quelli previsti, esamina gli snippet inclusi e l'ordine dei blocchi condizionali esistenti, non solo le ultime righe che hai modificato.

7. Ricarica SSH e mantieni l'accesso di amministratore

Dopo aver effettuato i controlli con successo, riavvia il servizio SSH in modo che le nuove connessioni utilizzino i criteri modificati. Mantieni attiva la connessione amministratore corrente mentre apri un secondo terminale per verificare che il normale accesso amministratore funzioni ancora.

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

Un riavvio completo potrebbe applicare le modifiche, ma è preferibile un ricaricamento quando supportato e si desidera evitare interruzioni non necessarie. L'output dei comandi di servizio e i messaggi di log variano a seconda dell'host, quindi è consigliabile esaminare il risultato effettivo anziché presumere che un ritorno al prompt con esito positivo garantisca l'accesso.

8. Testare i trasferimenti consentiti e l'accesso alla shell bloccato.

Da un altro computer, connettiti come utente con restrizioni. Usa il nome host effettivo del server e un file di test appropriato. La prima directory SFTP dovrebbe essere /uploade la directory radice chroot dovrebbe apparire come /anziché il percorso host /srv/sftp/contractor.

sftp contractor@server.example.com
sftp> pwd
sftp> cd /
sftp> ls
sftp> cd /upload
sftp> put sample.txt
sftp> cd /etc
sftp> exit

Il caricamento di un file di test innocuo dovrebbe essere consentito /upload. Raggiungere la directory root effettiva dell'host /etcnon dovrebbe essere possibile: il chroot definisce una directory root diversa e /etcsarebbe accessibile solo se si creasse o si esponesse deliberatamente tale directory all'interno del jail. Il testo esatto dell'errore del client non è importante.

ssh contractor@server.example.com

Per questo account non deve aprirsi una normale shell SSH interattiva. La connessione potrebbe invece chiudersi o visualizzare un messaggio relativo al protocollo; non fare affidamento su una frase esatta. Se si apre una shell, considera la configurazione non sicura e rivedi l'appartenenza al gruppo, Matchla precedenza e sshd -T -Cl'output effettivo prima di utilizzare l'account.

E se si utilizzassero chiavi pubbliche SSH?

L'autenticazione tramite chiave pubblica funziona con un jail SFTP, ma posizionare la home a livello host di un utente in questo modo /uploadsignifica che il percorso predefinito ~/.ssh/authorized_keyspotrebbe non esistere al di fuori del jail. Un'alternativa pratica è quella di consentire a SSH di leggere un file di chiave controllato da root prima di avviare il chroot. Aggiungi questo codice all'interno dello stesso Match Group sftpclientsblocco se scegli l'archiviazione centralizzata delle chiavi:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Quindi crea un /etc/ssh/authorized_keys/contractorfile contenente la chiave pubblica autorizzata dell'appaltatore, con proprietà root e senza permessi di scrittura per gruppi o utenti globali. Ad esempio, dopo aver copiato in modo sicuro un file di chiave pubblica verificato denominato contractor.pubin una directory di staging amministrativa:

sudo install -d -o root -g root -m 0755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 0644 contractor.pub /etc/ssh/authorized_keys/contractor
sudo /usr/sbin/sshd -t

Non copiare la chiave privata sul server. L'impostazione del percorso della chiave, le impostazioni predefinite di autenticazione e i controlli dell'account dipendono dalla policy SSH in uso; verifica l'accesso tramite chiave pubblica prima di disabilitare un metodo di autenticazione funzionante.

Errori comuni e il loro significato

Controlla i log con sudo journalctl -u ssh -n 80 --no-pager. L'errore esatto dipende dalle impostazioni PAM, dalla configurazione SSH, dall'accesso al filesystem e dal metodo di autenticazione. OpenSSH 9.0 e versioni successive utilizzano SFTP per scpi trasferimenti standard per impostazione predefinita, mentre la modalità legacy richiede una shell, come spiegato nel manuale scp di Ubuntu 24.04 .

È possibile limitare una shell SSH interattiva a una sola cartella?

Non con una modifica della directory home o con l'esempio solo SFTP di cui sopra. OpenSSH ChrootDirectorypuò essere utilizzato anche per sessioni shell, ma il jail deve includere una shell utilizzabile, le sue librerie condivise e i nodi di dispositivo richiesti, nonché tutte le dipendenze dei comandi. Creare un ambiente sicuro richiede più che impostare una riga in sshd_config. È facile creare una configurazione fragile o fuorviante, soprattutto quando sono coinvolti comandi shell o mount arbitrari.

Se un utente necessita realmente di comandi interattivi, è necessario innanzitutto specificare con precisione quali comandi e file gli servono. Per un set di comandi limitato, è consigliabile utilizzare comandi remoti con ambito ristretto o un endpoint applicativo dedicato. Per ambienti indipendenti più ampi, è opportuno valutare un container o una macchina virtuale con mount espliciti del filesystem, controlli dei privilegi e restrizioni di rete. Un ambiente chroot da solo non sostituisce l'isolamento completo del sistema, e né chroot né i permessi dei file Unix proteggono da un utente con privilegi elevati che potrebbe modificare il sistema sottostante.

Lista di controllo di sicurezza prima di concedere l'accesso

• L'account di trasferimento non è un amministratore e appartiene solo ai gruppi necessari.
• Ogni componente che conduce alla prigione è di proprietà dell'utente root e non è scrivibile dal gruppo o da tutti gli utenti.
• La posizione di caricamento scrivibile si trova all'interno del jail, non nella directory principale del jail stesso.
• L'utente previsto corrisponde a ChrootDirectory, ForceCommand internal-sftp, e l'inoltro disabilitato nella configurazione effettiva.
• Un caricamento SFTP effettivo ha successo, un tentativo di accedere a file presenti solo sull'host fallisce e il normale accesso alla shell SSH è bloccato.
• Backup, conservazione, quote, monitoraggio e revoca degli account vengono gestiti separatamente; un jail di directory non implementa automaticamente queste politiche.

Per maggiori dettagli tecnici, consultare la documentazione di configurazione di OpenSSH per Ubuntu 24.04 e il manuale del server SFTP di Ubuntu . Queste istruzioni sono pensate per Ubuntu 24.04 LTS; le build dei pacchetti e gli snippet SSH esistenti potrebbero modificarne il comportamento effettivo, pertanto la configurazione finale e i test di connessione effettivi sul proprio sistema host sono da considerarsi attendibili.