Come limitare l'accesso degli utenti SSH a directory specifiche in Ubuntu 24.04

Il modo più sicuro per limitare gli utenti SSH a una directory specifica su Ubuntu 24.04 è utilizzare OpenSSH ChrootDirectorycon ForceCommand internal-sftp. Questa soluzione è ideale quando l'account necessita solo del trasferimento di file. Fornisce all'utente una vista SFTP la cui radice del filesystem è la directory scelta, bloccando al contempo una shell interattiva e l'inoltro SSH.

Se l'utente ha effettivamente bisogno di una shell normale, la decisione è diversa. Una shell interattiva in un ambiente chroot necessita di un proprio binario shell, librerie, nodi dispositivo e file di supporto all'interno del jail. OpenSSH lo documenta esplicitamente. Per la maggior parte degli account di upload, backup, agenzie, fornitori e hosting condiviso, un chroot con solo SFTP è molto più semplice e meno soggetto a errori. Per gli utenti non attendibili che necessitano di un ambiente di comando completo, un container o una macchina virtuale dedicata sono generalmente più facili da gestire rispetto alla creazione manuale di un chroot shell.

Questa guida utilizza Ubuntu 24.04 LTS e un utente di esempio chiamato alice. L'utente avrà accesso limitato /srv/sftp/alicee potrà scrivere solo all'interno di /files. Sostituisci i nomi e i percorsi in base alle esigenze del tuo server.

Prima di iniziare: comprendere la regola di proprietà

Il problema più comune con i chroot è causato dai permessi. OpenSSH richiede che ogni componente del ChrootDirectorypercorso sia di proprietà di root e non scrivibile da gruppi o altri utenti . Questo requisito viene verificato incondizionatamente. Ciò significa che non dovresti rendere /srv/sftp/alicescrivibile da alice.

Invece, rendi la directory principale del jail di proprietà di root e crea una sottodirectory scrivibile:

/srv/sftp/alice        root:root   755
└── files              alice:alice 755

Questa configurazione segue il comportamento documentato nel manuale di Ubuntu 24.04sshd_config(5) . Lo stesso manuale specifica che internal-sftpnon sono necessari file di runtime aggiuntivi all'interno del chroot, motivo per cui è la soluzione ideale per un account con restrizioni al trasferimento di file.

Passaggio 1: Verificare che OpenSSH Server sia installato

Installare il pacchetto server se necessario:

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh.service

La documentazione ufficiale di Ubuntu per OpenSSH utilizza openssh-serveril pacchetto daemon e ssh.servicela gestione dei servizi. Vedi la guida di Ubuntu Server per OpenSSH .

Se si tratta di una macchina remota e SSH è l'unico accesso amministrativo disponibile, mantieni aperta la sessione amministrativa corrente mentre apporti le modifiche. Una configurazione SSH errata può bloccare l'accesso.

Passaggio 2: crea un gruppo e aggiungi l'utente con restrizioni

Crea un gruppo per gli utenti con restrizioni. Se aliceesiste già, aggiungila semplicemente al gruppo:

sudo groupadd sftpusers
sudo adduser alice
sudo usermod -aG sftpusers alice
id alice

Se utilizzi già le chiavi pubbliche SSH, continua a farlo. La configurazione chroot controlla ciò che accade dopo l'autenticazione ; non è necessario passare dall'autenticazione tramite chiave a quella tramite password.

Una regola basata sui gruppi è generalmente preferibile a un Match Userblocco separato per ogni account. Permette di centralizzare le policy. Una regola per singolo utente rimane comunque utile quando è necessario limitare l'accesso a layout diversi e non correlati.

Passaggio 3: Creare una prigione di proprietà di root e una sottocartella scrivibile

Crea la gerarchia delle directory:

sudo mkdir -p /srv/sftp/alice/files
sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files
sudo chmod 755 /srv/sftp/alice/files

Verificare la proprietà:

ls -ld /srv /srv/sftp /srv/sftp/alice /srv/sftp/alice/files
namei -l /srv/sftp/alice

Se /srvla /srv/sftpdirectory è scrivibile dal gruppo o dall'utente, correggi anche quello. OpenSSH controlla tutti i componenti del percorso, non solo la directory finale.

Passaggio 4: Aggiungere una regola di corrispondenza in sshd_config.d

La documentazione attuale di Ubuntu Server consiglia di mantenere le impostazioni SSH personalizzate /etc/ssh/sshd_config.d/anziché integrarle nel file principale del pacchetto. Crea uno snippet:

sudo nano /etc/ssh/sshd_config.d/90-sftp-restricted.conf

Aggiungere:

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

Match all

%usi espande al nome utente autenticato, quindi aliceviene posizionato in /srv/sftp/alice. L' -d /filesargomento indica al server SFTP interno di avviarsi all'interno della directory figlio scrivibile. DisableForwarding yesdisabilita l'inoltro di X11, agente, TCP e StreamLocal in un'unica direttiva; è specificamente documentato per semplificare le configurazioni con restrizioni.

La parte finale Match allè importante in un frammento di codice perché termina il contesto condizionale prima che la configurazione successiva venga analizzata.

Passaggio 5: Decidere tra restrizioni basate sui gruppi e restrizioni per singolo utente

Per più utenti con lo stesso layout, mantieni la regola di gruppo mostrata sopra. Per un singolo account eccezionale, utilizza invece un blocco specifico per l'utente:

Match User vendor1
    ChrootDirectory /srv/vendor/vendor1
    ForceCommand internal-sftp -d /incoming
    DisableForwarding yes
    PermitTTY no

Match all

Scegli in base ai costi amministrativi:

Passaggio 6: Convalidare la configurazione SSH prima del riavvio

Non riavviare mai SSH immediatamente dopo aver modificato il file. Esegui prima il test di sintassi consigliato da Ubuntu:

sudo sshd -t

L'assenza di output indica che il controllo della sintassi è andato a buon fine. È inoltre possibile verificare la configurazione effettiva per un utente specifico:

sudo sshd -T -C user=alice,host=localhost,addr=127.0.0.1   | grep -E 'chrootdirectory|forcecommand|disableforwarding|permittty'

Dovresti visualizzare il percorso chroot previsto e il comando SFTP forzato. Questo è particolarmente utile su Ubuntu perché le impostazioni possono provenire da entrambi /etc/ssh/sshd_configi file presenti in /etc/ssh/sshd_config.d/. Ubuntu fa notare che OpenSSH generalmente utilizza il primo valore ottenuto per la maggior parte delle direttive, quindi verificare la configurazione effettiva è più sicuro che presumere quale file prevalga.

Passaggio 7: riavviare SSH e testare con SFTP

Applica la modifica:

sudo systemctl restart ssh.service
sudo systemctl status ssh.service

Quindi, connettiti da un altro terminale:

sftp alice@server.example.com

All'interno di SFTP, eseguire il test:

pwd
ls
put test.txt
ls -l

Con la configurazione sopra descritta, la directory SFTP iniziale dovrebbe essere /files. La barra mostrata da SFTP è la radice del chroot, non la radice reale del server.

Un normale tentativo di accesso alla shell non dovrebbe produrre una shell senza restrizioni:

ssh alice@server.example.com

Poiché ForceCommand internal-sftpsostituisce la sessione richiesta con il server SFTP in-process, questo account è destinato intenzionalmente al trasferimento di file piuttosto che all'esecuzione di comandi.

Passaggio 8: Verificare che l'utente non possa evadere dalla prigione

Provate a spostarvi al di sopra della radice apparente e a ispezionare i percorsi host sensibili:

cd ..
ls /
ls /etc
ls /root

All'interno del chroot, /rappresenta /srv/sftp/alicesull'host. Se non hai creato alcuna directory etco rootall'interno di quel jail, l'utente non può raggiungere il reale /etco /root.

Prova anche a caricare qualcosa in /files. Una configurazione che blocca l'escape ma che accidentalmente rende l'intera jail di sola lettura è sicura ma non utile per un account di caricamento.

Risoluzione dei problemi: "proprietà o permessi errati per la directory chroot"

Se l'accesso fallisce immediatamente, controlla il registro del servizio SSH:

sudo journalctl -fu ssh.service

La guida OpenSSH di Ubuntu consiglia di utilizzare il journal del servizio SSH per la risoluzione dei problemi. Se si riscontra un errore di proprietà o di permessi, controllare ogni directory padre:

namei -l /srv/sftp/alice

Il percorso chroot deve essere di proprietà di root e non deve essere scrivibile dal gruppo o da altri. Un errore comune è questo:

sudo chown alice:alice /srv/sftp/alice

Non risolvete il problema indebolendo i controlli di OpenSSH. Posizionate invece l'area scrivibile dell'utente al di sotto della directory root di chroot:

sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files

E se l'utente avesse bisogno di accedere alla shell SSH, e non solo tramite SFTP?

ChrootDirectoryPuò essere utilizzato anche con una shell interattiva, ma la configurazione è sostanzialmente più complessa. OpenSSH afferma che un chroot interattivo necessita almeno di una shell e /devdi nodi di base, oltre a tutti i binari, le librerie, i file di risoluzione dei nomi e le altre dipendenze richieste dai comandi consentiti.

Per un account di un dispositivo strettamente controllato, la creazione di un ambiente isolato (jail) può essere giustificata. Per l'accesso generico ai comandi Linux, spesso comporta un onere di manutenzione: gli aggiornamenti di sicurezza per strumenti e librerie devono essere implementati anche all'interno dell'ambiente isolato. Se l'esigenza effettiva è "consentire a questa persona di eseguire comandi, ma isolandola dall'host", un container, una macchina virtuale o un servizio con restrizioni appositamente creato sono generalmente più facili da controllare.

Miglioramenti alla sicurezza che vale la pena aggiungere

La restrizione delle directory è solo un livello di protezione. Per i server esposti a Internet, è necessario considerare anche:

• Laddove possibile, utilizzare l'autenticazione tramite chiave pubblica SSH per gli account umani e automatizzati.
• Non concedere agli utenti con permessi limitati di trasferimento file sudol'accesso.
• Da utilizzare DisableForwarding yesesclusivamente per account SFTP, in modo che la connessione SSH non possa essere riutilizzata per tunnel o inoltro di agenti.
• Limita le directory scrivibili all'area minima necessaria al flusso di lavoro.
• Revisione journalctl -u ssh.servicee proprietà dei file dopo l'aggiunta degli utenti.
• Mantieni aperta una sessione amministrativa durante il test delle modifiche alla configurazione SSH remota.

Per il comportamento definitivo di ChrootDirectory, Match, ForceCommand, e DisableForwarding, consultare il manuale di configurazione del server OpenSSH di Ubuntu 24.04 . Per la configurazione specifica di Ubuntu, la convalida, i comandi di riavvio e la registrazione, fare riferimento alla documentazione ufficiale del server OpenSSH di Ubuntu .

In conclusione

Se l'obiettivo è "questo account SSH può caricare e scaricare file solo all'interno di una directory", usa un chroot di proprietà di root ChrootDirectory, posiziona il contenuto scrivibile in una sottocartella di proprietà dell'utente e forza l'accesso internal-sftp. Convalida con sshd -tprima di riavviare, quindi testa sia il percorso di caricamento consentito sia il tentativo di accesso dall'esterno del jail. Questo ti fornisce un piccolo e comprensibile confine di sicurezza senza dover costruire un ambiente Linux completo all'interno del chroot.