How to Restrict SSH Users to Specific Directories in Ubuntu 24.04

The safest way to restrict SSH users to a specific directory on Ubuntu 24.04 is to use OpenSSH's ChrootDirectory with ForceCommand internal-sftp. This is ideal when the account only needs file transfer. It gives the user an SFTP view whose filesystem root is the directory you choose, while blocking an interactive shell and SSH forwarding.

If the user genuinely needs a normal shell, the decision is different. A chrooted interactive shell needs its own shell binary, libraries, device nodes, and supporting files inside the jail. OpenSSH documents this explicitly. For most upload, backup, agency, vendor, and shared-hosting accounts, SFTP-only chroot is far simpler and less error-prone. For untrusted users who need a full command environment, a container or dedicated VM is usually easier to maintain than hand-building a shell chroot.

This guide uses Ubuntu 24.04 LTS and an example user named alice. The user will be restricted to /srv/sftp/alice and will be allowed to write only inside /files. Replace the names and paths to suit your server.

Before you start: understand the ownership rule

The most common chroot failure is caused by permissions. OpenSSH requires every component of the ChrootDirectory path to be owned by root and not writable by group or other users. This requirement is checked unconditionally. That means you should not make /srv/sftp/alice writable by alice.

Instead, make the jail root root-owned and create a writable child directory:

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

This design follows the behavior documented in the Ubuntu 24.04 sshd_config(5) manual. The same manual notes that internal-sftp needs no extra runtime files inside the chroot, which is why it is the best fit for a restricted file-transfer account.

Step 1: Verify that OpenSSH Server is installed

Install the server package if necessary:

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

Ubuntu's official OpenSSH documentation uses openssh-server for the daemon package and ssh.service for service management. See the Ubuntu Server OpenSSH guide.

If this is a remote machine and SSH is your only administrative path, keep your existing administrator session open while making changes. A bad SSH configuration can lock you out.

Step 2: Create a group and add the restricted user

Create a group for restricted users. If alice already exists, only add her to the group:

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

이미 SSH 공개 키를 사용하고 있다면 계속 사용하십시오. chroot 구성은 인증 후 발생하는 작업을 제어하므로 키 인증에서 암호 인증으로 전환할 필요가 없습니다.

일반적으로 계정별로 개별 차단을 설정하는 것보다 그룹 기반 규칙이 더 효과적입니다 Match User. 정책을 한 곳에 관리할 수 있기 때문입니다. 하지만 서로 다른 사용자를 관련 없는 레이아웃에 제한해야 하는 경우에는 사용자별 규칙도 여전히 유용합니다.

3단계: 루트 소유의 jail과 쓰기 가능한 하위 디렉터리를 생성합니다.

디렉토리 계층 구조를 생성합니다.

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

소유권을 확인하세요:

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

만약 /srv해당 /srv/sftp디렉터리가 그룹 쓰기 가능 또는 사용자 쓰기 가능 상태라면, 그것도 수정해야 합니다. OpenSSH는 최종 디렉터리뿐만 아니라 경로의 모든 구성 요소를 확인합니다.

4단계: sshd_config.d에 일치 규칙을 추가합니다.

Ubuntu의 최신 서버 문서에서는 사용자 지정 SSH 설정을 /etc/ssh/sshd_config.d/패키지된 메인 파일에 섞지 않고 별도의 파일에 보관하는 것을 권장합니다. 다음 코드 조각을 생성하세요.

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

추가하다:

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

Match all

%u인증된 사용자 이름으로 확장되므로 alice에 배치됩니다 /srv/sftp/alice. -d /files인수는 내부 SFTP 서버가 쓰기 가능한 하위 디렉터리 내에서 시작하도록 지시합니다. DisableForwarding yes하나의 지시문으로 X11, 에이전트, TCP 및 StreamLocal 포워딩을 비활성화합니다. 이는 제한된 구성을 단순화하기 위해 특별히 문서화되어 있습니다.

코드 조각에서 마지막 부분은 Match all조건부 컨텍스트를 종료시킨 후 이후의 구성이 분석되기 때문에 중요합니다.

5단계: 그룹 기반 제한과 사용자별 제한 중 하나를 선택합니다.

동일한 레이아웃을 사용하는 여러 사용자의 경우 위에서 설명한 그룹 규칙을 그대로 유지하세요. 특정 계정 하나만 예외적으로 제한해야 하는 경우에는 사용자별 차단 규칙을 사용하세요.

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

Match all

관리 비용을 기준으로 선택하세요:

6단계: 재시작하기 전에 SSH 구성을 검증하십시오.

파일을 편집한 직후에는 절대 SSH를 재시작하지 마십시오. 먼저 Ubuntu에서 권장하는 구문 테스트를 실행하십시오.

sudo sshd -t

출력이 없으면 구문 검사가 성공한 것입니다. 특정 사용자의 실제 구성도 확인할 수 있습니다.

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

예상되는 chroot 경로와 강제 SFTP 명령이 표시될 것입니다. 이는 특히 Ubuntu에서 유용한데, 설정이 `/usr/chroot` /etc/ssh/sshd_config및 `/usr/chroot` 파일 모두에서 가져올 수 있기 때문입니다 /etc/ssh/sshd_config.d/. Ubuntu에서는 OpenSSH가 대부분의 지시문에 대해 일반적으로 처음 얻은 값을 사용하므로, 어떤 파일이 우선하는지 추측하기보다는 실제 구성을 확인하는 것이 더 안전하다고 설명합니다.

7단계: SSH를 재시작하고 SFTP로 테스트합니다.

변경 사항을 적용하세요:

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

그런 다음 다른 터미널에서 연결하세요.

sftp alice@server.example.com

SFTP 내부에서 테스트:

pwd
ls
put test.txt
ls -l

위와 같은 설정으로 초기 SFTP 디렉터리는 입니다 /files. SFTP에서 표시되는 슬래시는 chroot 환경의 루트 디렉터리이며, 실제 서버 루트 디렉터리가 아닙니다.

일반적인 셸 실행 시도에서는 무제한 셸이 생성되어서는 안 됩니다.

ssh alice@server.example.com

ForceCommand internal-sftp요청된 세션을 프로세스 내 SFTP 서버로 대체하기 때문에 이 계정은 명령 실행보다는 파일 전송용으로 의도적으로 만들어졌습니다.

8단계: 사용자가 감옥에서 탈출할 수 없는지 확인합니다.

최상위 루트 경로보다 상위 경로로 이동하여 민감한 호스트 경로를 검사해 보세요.

cd ..
ls /
ls /etc
ls /root

chroot 환경 내부에서는 호스트의 /실제 주소가 사용됩니다 . 만약 해당 jail 내부에 디렉토리 나 디렉터리를 생성하지 않았다면, 사용자는 호스트의 실제 주소 나 디렉터리 에 접근할 수 없습니다 ./srv/sftp/aliceetcroot/etc/root

또한 업로드를 테스트해 보세요 /files. 탈출을 차단하지만 실수로 전체 jail을 읽기 전용으로 만들어 버리는 구성은 안전하지만 업로드 계정에는 유용하지 않습니다.

문제 해결: "chroot 디렉터리의 소유권 또는 모드가 잘못되었습니다"

로그인이 즉시 실패하는 경우 SSH 서비스 로그를 확인하십시오.

sudo journalctl -fu ssh.service

Ubuntu의 OpenSSH 가이드에서는 문제 해결을 위해 SSH 서비스 저널을 확인하도록 권장합니다. 소유권 또는 모드 오류가 발생하는 경우 모든 상위 디렉터리를 검사하십시오.

namei -l /srv/sftp/alice

chroot 경로는 루트 소유여야 하며, 그룹이나 다른 사용자가 쓰기 권한을 갖지 않아야 합니다. 흔히 저지르는 실수는 다음과 같습니다.

sudo chown alice:alice /srv/sftp/alice

OpenSSH 검사를 약화시켜 문제를 해결하지 마십시오. 대신 사용자의 쓰기 가능 영역을 chroot 루트 아래에 배치하십시오.

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

사용자가 SFTP 접근뿐만 아니라 SSH 셸 접근도 필요한 경우는 어떻게 해야 할까요?

ChrootDirectoryOpenSSH는 대화형 셸과 함께 사용할 수도 있지만, 설정이 훨씬 더 복잡합니다. OpenSSH에 따르면 대화형 chroot 환경에는 최소한 셸과 기본 /dev노드, 그리고 허용하는 명령에 필요한 바이너리, 라이브러리, 이름 확인 파일 및 기타 종속 파일이 필요합니다.

엄격하게 통제되는 어플라이언스 계정의 경우 이러한 격리된 환경(jail)을 구축하는 것이 타당할 수 있습니다. 하지만 일반적인 Linux 명령 접근의 경우, 도구 및 라이브러리에 대한 보안 업데이트도 격리된 환경 내에 반영해야 하므로 유지 관리 부담이 커지는 경우가 많습니다. 만약 실제 요구 사항이 "이 사용자가 명령을 실행하되 호스트와 격리"라면 컨테이너, 가상 머신 또는 특정 용도로 구축된 제한된 서비스가 일반적으로 감사하기 더 쉽습니다.

추가할 만한 보안 개선 사항

디렉터리 제한은 단지 한 단계일 뿐입니다. 인터넷에 연결된 서버의 경우 다음 사항도 고려해야 합니다.

• 가능한 경우 사람 계정과 자동화 계정 모두에 SSH 공개키 인증을 사용하십시오.
• 파일 전송이 제한된 사용자에게는 sudo접근 권한을 부여하지 마십시오.
• SFTP 전용 계정에만 사용하도록 설정하여 DisableForwarding yesSSH 연결이 터널 또는 에이전트 포워딩 용도로 재사용되지 않도록 합니다.
• 쓰기 가능한 디렉터리를 워크플로에 필요한 최소 영역으로 제한하십시오.
• journalctl -u ssh.service사용자 추가 후 파일 소유권을 검토하세요 .
• 원격 SSH 구성 변경을 테스트하는 동안 관리자 세션을 열어 두십시오.

ChrootDirectory, Match, ForceCommand, 및 의 정확한 동작에 대해서는 Ubuntu 24.04 OpenSSH 서버 구성 설명서를DisableForwarding 참조하십시오 . Ubuntu 관련 구성 레이아웃, 유효성 검사, 재시작 명령 및 로깅에 대해서는 Ubuntu OpenSSH 서버 공식 문서를 참조하십시오 .

결론적으로

목표가 "이 SSH 계정은 특정 디렉토리 내에서만 파일을 업로드 및 다운로드할 수 있다"라면 ChrootDirectory, 루트 소유의 디렉토리를 사용하고, 쓰기 가능한 콘텐츠는 사용자 소유의 하위 디렉토리에 배치한 다음, 강제 internal-sftp로 sshd -t접근 권한을 부여하십시오. 재시작하기 전에 `sudo ...