3상 전압, 전류, kW, kVA 및 역률 변환 방법
균형 잡힌 3상 공식을 배우고, 선간 전압, 전류, kW, kVA 및 역률을 단계별로 변환하는 방법을 예제와 함께 확인하고 점검 범위를 살펴보세요.
계약자에게 몇 개의 파일을 업로드할 수 있는 권한을 부여한다고 해서 자동으로 서버 전체에 접근할 수 있는 터미널 세션을 제공해서는 안 됩니다. Ubuntu 24.04 LTS에서는 OpenSSH가 ChrootDirectory내장 internal-sftp서버와 규칙을 사용하여 파일 전송 계정을 특정 디렉터리로 제한할 수 있습니다. 중요한 점은 이것이 SFTP에만 적용되는 제한 이며 , 단순히 제한된 Bash 셸을 제공하는 방식이 아니라는 것입니다.
이 가이드에서는 설정이 실제로 무엇을 보호하는지 설명하고, 각 계정에 고유한 디렉터리를 할당하는 8단계 설정 과정을 안내합니다. 명령어는 라는 샘플 계정 contractor과 라는 샘플 호스트를 사용하므로 server.example.com, 실제 값으로 대체하십시오. 이는 구성 예시일 뿐이며, 실제 서버 테스트 결과를 보장하는 것은 아닙니다.
리눅스 권한 설정은 계정이 읽거나 수정할 수 있는 파일을 결정하고, 계정의 홈 디렉터리를 변경하면 초기 위치가 설정되며, chroot는 프로세스에 제공되는 파일 시스템 루트를 변경합니다. 이 세 가지는 서로 바꿔 사용할 수 없습니다.
| 목표 | 적절한 시작점 | 중요한 제한 사항 |
|---|---|---|
| 지정된 폴더 내에서만 업로드 및 다운로드가 가능합니다. | ChrootDirectory와 함께ForceCommand internal-sftp | 대화형 리눅스 셸을 제공하지 않습니다. |
| 셸 접근은 허용하되 읽기/쓰기 권한은 제어하도록 합니다. | 유닉스 소유권, 그룹, ACL 및 최소 권한 | 일반 셸 사용자는 여전히 다른 읽기 가능한 경로를 탐색할 수 있습니다. |
| 격리된 명령줄 환경을 제공합니다. | 보안 제어 기능이 별도로 구성된 chroot 환경 또는 컨테이너/VM | 훨씬 더 많은 설정 및 격리 검토가 필요합니다. |
오해: 홈 디렉토리를 설정 /home/contractor하면 사용자가 해당 디렉토리에만 머무르게 된다는 생각은 잘못된 것입니다. 일반 셸 사용자는 파일 시스템 내 접근 가능한 다른 디렉토리로 이동할 수 있습니다. 파일 교환이 실제 요구 사항이라면 셸 프롬프트를 사용하여 디렉토리를 숨기는 대신 아래의 SFTP 전용 방식을 사용하는 것이 좋습니다.
OpenSSH 문서 ChrootDirectory, Match, 및 ForceCommand공식 Ubuntu 24.04 sshd_config 설명서를 참조하십시오 .
SSH를 통해 원격으로 수정하기 전에 기존 관리자 세션을 열어두고 콘솔 또는 복구 액세스 권한이 있는지 확인하십시오. 전송에는 별도의 권한이 없는 계정을 사용하고, 관리자 계정을 제한된 그룹에 추가하지 마십시오.
서버에 필요한 경우 OpenSSH를 설치하고, 서비스를 확인한 후 주요 설정을 저장하십시오. Ubuntu 공식 서버 설명서에서는 이러한 서비스 및 설정 경로를 지원합니다.
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

SSH를 통해서만 시스템을 관리할 수 있는 경우, 편집 또는 테스트 중에 현재 세션을 닫지 마십시오. 데몬을 변경하기 전에 Ubuntu OpenSSH 서버 구성 가이드를 참조하십시오.
그룹은 제한된 계정이 둘 이상 있을 것으로 예상될 때 유용합니다. 이 예제에서는 %u토큰을 사용하여 각 구성원에게 별도의 jail을 할당하며, OpenSSH는 이 토큰을 접속하는 사용자 이름으로 확장합니다. 홈 경로는 향후 생성될 chroot 환경 내부에/upload 존재해야 하므로 호스트 수준 디렉터리는 생성하지 마십시오./upload
sudo groupadd sftpclients
sudo adduser --home /upload --no-create-home --shell /usr/sbin/nologin contractor
sudo usermod -aG sftpclients contractor
id contractor
이 adduser과정에서 암호를 지정하라는 메시지가 나타날 수 있습니다. SSH 암호 인증이 비활성화된 설치 환경에서는 공개 키를 생성하고 인증하십시오. 단순히 예시를 따라 하기 위해 암호 로그인을 전역적으로 활성화하지 마십시오. 셸도 nologin또 다른 보안 장치이지만, 강제로 적용되는 internal-sftp명령이 이 구성을 데이터 전송 전용으로 만드는 핵심입니다. 사용 중인 인증 스택에서 이 조합을 테스트해 보십시오.

많은 가이드가 이 부분에서 오류를 범합니다. OpenSSH는 chroot 경로의 모든 구성 요소가 root 소유여야 하며 다른 사용자나 그룹이 쓰기 권한을 갖지 않아야 합니다. 절대로 jail 자체를 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
기존 구성 요소도 확인하십시오 /. /srv위의 명령은 안전하지 않은 상위 권한을 자동으로 복구하지 않습니다. 구성 요소가 그룹 쓰기 가능하거나 사용자 소유인 경우, 다른 응용 프로그램이 해당 구성 요소에 의존하는지 확인한 후에만 소유권과 모드를 수정하십시오.

해당 계정은 chroot 루트를 변경할 권한 없이 하위 디렉터리에 쓰기 권한을 가집니다. /srv/sftp/contractor/upload계정의 실제 파일에 대한 디렉터리를 생성하세요. SFTP 내부에서 이 디렉터리는 다음과 같이 표시됩니다 /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
예상되는 소유권은 의도적으로 다릅니다. 이는 root:rootjail 루트와 contractor:contractor쓰기 가능한 업로드 폴더에 적용됩니다. chmod 777불필요한 노출을 초래하고 jail 루트에 적용될 경우 거부될 수 있는 `<property>` 속성은 사용하지 마십시오.

/etc/ssh/sshd_config기존 지시문 및 블록 뒤에 다음 블록을 추가하십시오 . 또는 Match와 같은 텍스트 편집기를 사용하십시오 . 먼저 기존 규칙을 검토하십시오. 여러 개의 일치하는 블록이 동일한 키워드를 할당하는 경우 OpenSSH는 첫 번째로 적용되는 항목을 사용합니다. Ubuntu는 초기 버전부터 하위 디렉터리의 파일도 처리합니다. 해당 디렉터리의 규칙은 우선순위에 영향을 줄 수 있습니다.sudoeditsudo nanoMatch/etc/ssh/sshd_config.d/Include
Match Group sftpclients
ChrootDirectory /srv/sftp/%u
ForceCommand internal-sftp -d /upload
PermitTTY no
DisableForwarding yes
Match Groupsftpclients. 의 구성원을 대상으로 하며, ChrootDirectory각 사용자를 . 아래에 배치합니다 /srv/sftp/USERNAME. ForceCommand internal-sftp -d /upload인프로세스 SFTP 서비스를 실행하고 쓰기 가능한 디렉터리 내에서 시작합니다. PermitTTY no터미널 할당을 방지하고, DisableForwarding yes일치하는 연결에 대한 SSH 포워딩 기능을 비활성화합니다.
Ubuntu에서 제공하는 전역 Subsystem sftp지시문을 그대로 사용하세요. 특별한 이유로 변경할 필요가 없는 한, 강제로 실행되는 내부 SFTP 명령은 해당 전역 줄을 바꿀 필요가 없습니다. Match All어떤 영향을 미칠지 이해하지 못한 채 단순히 블록을 끝내기 위해 추가적인 전역 지시문을 추가하지 마세요.

구문 분석이 성공했다고 해서 감옥 권한이 올바르거나 의도한 계정이 정책과 일치한다는 것을 보장하는 것은 아닙니다. 두 가지 검사를 모두 명시적으로 수행하십시오.
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
효과적인 구성에는 의도된 chroot 경로, 강제 SFTP 명령, 비활성화된 TTY 할당 및 전달 제한이 명시되어야 합니다. 예시 주소 192.0.2.10는 설명용일 뿐이며 Match, 주소에 따라 규칙이 달라지는 경우 실제 클라이언트 소스 주소로 대체해야 합니다. 형식은 Ubuntu 24.04 sshd 설명서-T -C 에 나와 있습니다 .
유효성 검사에 실패하면 SSH를 다시 시작하기 전에 구성을 수정하십시오. 유효 값이 예상과 다르면 최근에 편집한 줄뿐만 아니라 포함된 코드 조각과 기존 조건부 블록의 순서를 검사하십시오.
확인이 완료되면 SSH 서비스를 재시작하여 새 연결이 수정된 정책을 사용하도록 하십시오. 현재 관리자 연결을 유지하면서 두 번째 터미널을 열어 정상적인 관리자 액세스가 여전히 작동하는지 확인하십시오.
sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

전체 재시작을 통해 변경 사항을 적용할 수도 있지만, 불필요한 중단을 피하려면 지원되는 경우 재로드를 사용하는 것이 좋습니다. 서비스 명령 출력 및 로그 메시지는 호스트마다 다르므로 프롬프트로 성공적으로 돌아갔다고 해서 액세스가 보장되는 것은 아니므로 실제 결과를 확인하십시오.
다른 컴퓨터에서 제한된 사용자로 접속하십시오. 서버의 실제 호스트 이름과 적절한 테스트 파일을 사용하십시오. 첫 번째 SFTP 디렉터리는 이어야 하며 /upload, chroot 루트는 /호스트 경로가 아닌 로 표시되어야 합니다 /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
무해한 테스트 파일 업로드는 허용되어야 합니다 /upload. 호스트의 실제 /etc루트 디렉터리에 접근하는 것은 불가능해야 합니다. chroot 환경은 다른 루트 디렉터리를 정의하며, /etc사용자가 의도적으로 jail 내부에 해당 디렉터리를 생성하거나 노출하지 않는 한 접근이 불가능합니다. 정확한 클라이언트 오류 메시지는 중요하지 않습니다.

ssh contractor@server.example.com
이 계정으로는 일반적인 대화형 SSH 셸이 열리면 안 됩니다. 대신 연결이 끊어지거나 프로토콜 관련 메시지가 표시될 수 있습니다. 메시지 문구가 정확하지 않을 수 있으니 주의하십시오. 셸이 열리는 경우, 해당 구성은 안전하지 않은 것으로 간주하고 계정을 사용하기 전에 그룹 구성원 자격, Match우선순위 및 실제 출력 설정을 다시 검토해야 합니다.sshd -T -C

공개 키 인증은 SFTP jail에서 작동하지만, 사용자의 호스트 수준 홈 디렉터리를 /upload특정 위치 에 설정하면 jail 외부에서는 해당 경로가 존재하지 않을 수 있습니다. 실용적인 대안은 SSH가 chroot를 시작하기 전에 루트 사용자가 관리하는 키 파일을 읽도록 하는 것입니다. 중앙 집중식 키 저장소를 선택하는 경우, ~/.ssh/authorized_keys동일한 코드 블록 안에 다음 내용을 추가하세요.Match Group sftpclients
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
그런 다음 /etc/ssh/authorized_keys/contractor, 루트 소유권으로 관리형 스테이징 디렉터리에 계약자의 승인된 공개 키가 포함된 파일을 생성합니다. 예를 들어, 검증된 공개 키 파일을 contractor.pub관리자용 스테이징 디렉터리에 안전하게 복사한 후 다음과 같이 합니다.
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
개인 키를 서버에 복사하지 마십시오. 키 경로 설정, 인증 기본값 및 계정 확인은 기존 SSH 정책에 따라 달라집니다. 이미 작동 중인 인증 방식을 비활성화하기 전에 공개 키 액세스 권한을 확인하십시오.
| 증상 | 가장 가능성이 높은 원인 | 다음 확인 |
|---|---|---|
| SFTP 인증 후 즉시 연결이 끊어집니다. | chroot 경로의 구성 요소가 쓰기 가능하거나 루트 소유가 아니거나, 또는 필요한 시작 디렉터리가 없습니다. | 서비스 로그를 실행 namei -l /srv/sftp/contractor, 확인 /upload및 검토합니다. |
| 사용자가 접속은 되지만 업로드가 되지 않습니다. | 쓰기 가능한 하위 디렉터리의 소유자 또는 모드가 잘못되었습니다. | 업로드 하위 디렉터리의 출력을 검사하십시오 stat. jail 루트의 소유권을 사용자에게 변경하지 마십시오. |
| SSH 셸은 여전히 열립니다. | 그룹 불일치 또는 이전에 적용된 SSH 규칙 | 달리고id contractorsshd -T -C |
| 공개키 로그인이 거부되었습니다. | 인증 키 파일이 구성된 경로에 없거나 권한 유효성 검사에 실패했습니다. | AuthorizedKeysFile키 배치, 파일 소유권 및 SSH 로그를 검사합니다 . |
| 기존 SCP 클라이언트가 실패합니다. | 이는 원격 셸이 필요한 기존 SCP 프로토콜을 예상합니다. | SFTP 또는 SFTP를 사용하는 SCP 클라이언트를 사용하십시오.scp -O |
로그를 확인하세요 sudo journalctl -u ssh -n 80 --no-pager. 정확한 오류는 PAM 설정, SSH 구성, 파일 시스템 접근 권한 및 인증 방법에 따라 다릅니다. OpenSSH 9.0 이상 버전은 기본적으로 표준 전송에 SFTP를 사용하지만 , 레거시 모드는 셸이 필요합니다. 자세한 내용은 Ubuntu 24.04 scp 설명서를scp 참조하세요 .
홈 디렉터리 변경이나 위의 SFTP 전용 예시로는 안 됩니다. OpenSSH는 ChrootDirectory셸 세션에도 사용할 수 있지만, jail에는 사용 가능한 셸, 공유 라이브러리, 필요한 장치 노드 및 모든 명령 종속성이 포함되어야 합니다. 이러한 환경을 안전하게 구축하려면 단순히 한 줄을 설정하는 것 이상의 작업이 필요합니다 sshd_config. 특히 임의의 셸 명령이나 마운트가 관련된 경우, 취약하거나 오해의 소지가 있는 설정을 만들기 쉽습니다.
사용자가 대화형 명령을 정말로 필요로 하는 경우, 먼저 필요한 명령과 파일을 정확하게 지정해야 합니다. 명령 세트가 제한적이라면 범위가 좁은 원격 명령이나 전용 애플리케이션 엔드포인트를 사용하십시오. 더 광범위하고 독립적인 환경을 구축하려면 명시적인 파일 시스템 마운트, 권한 제어 및 네트워크 제한이 있는 컨테이너 또는 가상 머신을 고려하십시오. chroot만으로는 완벽한 시스템 격리를 대체할 수 없으며, chroot나 Unix 파일 권한 모두 기본 시스템을 변경할 수 있는 권한 있는 사용자로부터 시스템을 보호하지 못합니다.
ChrootDirectory, ForceCommand internal-sftp와 일치하며, 유효 구성에서 전달을 비활성화했습니다.더 자세한 기술적 내용은 Ubuntu 24.04 OpenSSH 구성 참조 및 Ubuntu SFTP 서버 설명서를 참조하십시오 . 이 지침은 Ubuntu 24.04 LTS를 대상으로 하며, 패키지 빌드 및 기존 SSH 코드 조각에 따라 실제 동작이 변경될 수 있으므로 최종적인 확인은 사용자 호스트에서의 구성 및 실제 연결 테스트를 통해 이루어져야 합니다.
균형 잡힌 3상 공식을 배우고, 선간 전압, 전류, kW, kVA 및 역률을 단계별로 변환하는 방법을 예제와 함께 확인하고 점검 범위를 살펴보세요.
CPUQuota 및 MemoryMax를 사용하여 systemd 범위 내에서 워크로드를 실행한 다음 cgroup v2를 통해 제한 사항을 확인합니다.
Ubuntu 24.04에서 dnscrypt-proxy를 Pi-hole의 로컬 DoH 브리지로 설정하고, localhost 전용 리스너, 리졸버 선택, DNS 전환 전 검사 기능을 추가합니다.
앱이나 하드웨어 문제를 해결하기 전에 우분투의 터치패드 설정을 확인하고, 웨이랜드(Wayland)가 제대로 작동하는지 확인하고, GNOME에 내장된 스와이프 기능을 테스트해 보세요.
데비안 12에서 디스크 두 개를 사용하여 RAID 1 데이터 어레이를 생성 및 검증하고, 안전하게 포맷한 다음, 재부팅 후 자동으로 구성 및 마운트되도록 설정합니다.
기존 Debian 12 스왑 파티션에 대한 임의 키 암호화를 설정하고, 활성 dm-crypt 매핑을 확인하고, 최대 절전 모드의 장단점을 이해합니다.
Ubuntu 24.04 SSH 계정을 chroot 환경, 적절한 권한, 일치 규칙 및 안전한 테스트를 통해 지정된 SFTP 폴더로 제한하고 셸 액세스 권한은 부여하지 않습니다.
우분투의 dpkg 프런트엔드 잠금을 소유하는 프로세스를 찾아 패키지 작업이 완료될 때까지 기다리고, 잠금 파일을 삭제하지 않고 중단된 설치를 복구합니다.
Timeshift를 사용하여 Ubuntu Desktop에서 Btrfs 시스템 스냅샷을 예약 설정하고, Ubuntu 서브볼륨 레이아웃을 확인하고, 보존 기간을 선택하고, 스냅샷으로 보호할 수 없는 항목을 이해합니다.
보다 안전한 데비안 12에서 테스팅 버전으로의 마이그레이션을 계획하세요: 스테이블 버전을 거쳐 업그레이드하고, 백업하고, APT 소스를 정리하고, 종속성 변경 사항을 시뮬레이션하고, 변경 사항을 확인하세요.