![사람들이 Systemd의 네임스페이스 기능 대신 SSH chroot 기반 SFTP 감옥을 계속 사용하는 이유는 무엇입니까? [폐쇄]](https://linux55.com/image/116193/%EC%82%AC%EB%9E%8C%EB%93%A4%EC%9D%B4%20Systemd%EC%9D%98%20%EB%84%A4%EC%9E%84%EC%8A%A4%ED%8E%98%EC%9D%B4%EC%8A%A4%20%EA%B8%B0%EB%8A%A5%20%EB%8C%80%EC%8B%A0%20SSH%20chroot%20%EA%B8%B0%EB%B0%98%20SFTP%20%EA%B0%90%EC%98%A5%EC%9D%84%20%EA%B3%84%EC%86%8D%20%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%20%EC%9D%B4%EC%9C%A0%EB%8A%94%20%EB%AC%B4%EC%97%87%EC%9E%85%EB%8B%88%EA%B9%8C%3F%20%5B%ED%8F%90%EC%87%84%5D.png)
이 아이디어는 어리석거나 실행 불가능할 수도 있지만 이에 대한 참고 자료를 찾을 수 없습니다.
아시다시피(SE는 확실히 그렇습니다!) SSH 보안을 강화하는 일반적인 단계 중 하나는 파일 액세스 권한이 충분한 경우 chroot에서 사용자를 잠그는 것입니다. OpenSSH는 수년 동안 이러한 chroot 기반 감옥을 제공해 왔습니다.
그러나 이 접근 방식은 유연성이 부족하고(전부 아니면 전무, SFTP만 등) 시스템 호출의 오용으로 귀결됩니다(보안에 영향을 미치므로 "감옥은 루트가 소유해야 함" 및 기타 제안은 거의 이해되지 않음).
이제 OpenSSH를 sshd.socket사용할 수 있으므로 [email protected]Linux 네임스페이스(당시 무료로 제공됨)를 사용하여 사용자를 제한하고 싶은 유혹이 듭니다.
놀랍게도 이 대안에서는 거의 아무것도 발견하지 못했습니다. 그래서 제 질문은 이 목적으로 chroot 대신 네임스페이스를 사용하지 않을 이유가 있느냐는 것입니다.
답변1
당신은 그것을 시도하고 그것이 어떻게 작동하는지보고해야합니다. 모든 일에는 항상 누군가가 먼저입니다!
하지만 내 걱정은 이것이 작동하지 않을 것이라는 점이다. OpenSSH는 chroot모든 키 교환, 인증 및 모든 작업이 완료된 후에 호출되지만 Systemd는 sshd 프로세스를 시작하기 전에도 네임스페이스를 강제로 적용하고(동작을 올바르게 이해한 경우) 사용자 인증을 처리하지 못할 수 있습니다. 또한 서비스 파일에서는 연결된 사용자를 구별할 수 없으므로 모두를 위해 네임스페이스를 지정할 수 있습니까? 이 시스템을 유지하려면 일반 관리자로 어떻게 연결합니까? 나는 이것이 확실히 좋은 아이디어이고 다른 서비스에 유용하다고 생각하지만 OpenSSH 요구 사항을 위해 (무료로) 이를 "남용"할 수는 없다고 생각합니다.