점프 호스트에서 SSH ForceCommand는 얼마나 안전합니까?

네트워크에 다음과 같은 설정이 있습니다.

Internet <--> Bastion <--> Local Network

여러 사용자가 있으며 각 사용자는 특정 컴퓨터에 할당되어 있습니다. 즉, 각 사용자는 해당 서버 중 하나에 만 액세스 할 수 있어야합니다. 예 : User1-> Machine1, User2-> Machine2 등.

이 사용자는 내 네트워크 외부에서 연결하며 배스 천 호스트를 통해 내 네트워크로 연결을 전달하는 방법을 많이 고려했습니다.

결국 나는 Match Blocks와 forcecommand를 선택했습니다.

따라서 요새에 대한 내 / etc / ssh / sshd_config는 다음과 같습니다.

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

User1은 배스 천 호스트에 연결하여 Machine1과 자동으로 연결됩니다.

ForceCommand를 이해하는 한 User1은 요새 호스트에 실제로 액세스 할 수 없습니다. 모든 작업이 일치 블록에서 먼저 처리되므로 Machine1로 다시 라우팅되기 때문입니다. 그러나 이것이 사실입니까? 보안 설정으로 충분합니까? 어쨌든 사용자는 Machine1에 투옥되어 있기 때문에 많은 가능성이 없습니다.

요새 호스트를 사용하는 방법 은이 예와 같이 ProxyCommand및 -W플래그를 사용하는 것입니다 .

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

보안상의 이유로이 방법을 사용합니다. 클라이언트와 대상 시스템 간의 통신은 종단 간 암호화되어 인증되므로 요새가 손상 되더라도 보안 상태를 유지합니다. 감염된 요새 호스트는 요새없이 ssh end-to-end를 사용하는 것보다 더 적은 보안을 제공합니다.

또한 에이전트 전달을 사용할 필요가 없습니다. 클라이언트는 키 기반 인증을 먼저 사용하여 요새에 액세스 한 다음 클라이언트에있는 개인 키를 악용하는 데 사용할 수있는 에이전트 연결이 제공되지 않은 대상 호스트에 다시 액세스 할 수 있습니다.

또한 요새 호스트에 의존하는 코드를 제한합니다. 요새에서 전혀 명령을 실행할 필요가 없습니다. -W하나의 단일 포트 전달뿐만 아니라 no 명령 플래그를 의미하며,이 포트 전달은 허용되는 모든 요새 호스트입니다.

이 접근법을 염두에두고 위의 구조의 명령 만 사용하도록 요새 호스트를 가능한 한 많이 잠그는 것이 좋습니다.

~/.ssh/authorized_keys요새에 파일은 루트가 소유 할 수있다 (그것에 파일 시스템의 루트에서 경로에있는 모든 디렉토리 수로), 이것은 누군가가에 권한이없는 사용자로 휴식을 관리하는 경우에도이 수정 될 수있는 위험을 감소 요새 호스트.

에서 authorized_keys클라이언트의 권한이 옵션을 사용하여 제한 할 수 있습니다 command, no-agent-forwarding, no-pty, no-user-rc, no-X11-forwarding,뿐만 아니라 사용하는 등 permitopen으로 제한 포트 포워딩 만이 사용자에 대한 액세스를 허용하는 호스트의 포트 22에 액세스 할 수 있습니다.

원칙적으로이 방법은 여러 사용자가 요새에서 단일 사용자 이름을 공유하더라도 안전합니다. 그러나 요새에서 별도의 사용자 이름을 사용하면 약간 더 분리됩니다.

쉘이 시작될 때 ForceCommand가 시작되기 때문에 ForceCommand를 쉽게 우회 할 수 있습니다. 이것은 본질적으로 쉘 rc 파일이 먼저 처리 된 다음 ForceCommand가 도달하도록 허용하면 강제 실행됨을 의미합니다. exec sh쉘에서 rc 파일을 단순 하게하면 다른 쉘이 생성되고이 쉘을 종료 할 때까지 ForceCommand를 대기 상태로 유지합니다.

결론은 다음과 같습니다. 사용자가 ftp, sftp, scp 또는 다른 방법으로 쉘 rc (예 : .bashrc)를 편집 할 수 있다면 ForceCommand는 실제로 의존하지 않습니다.

나는 그것이 대부분의 경우는 좋다고 생각하지만, 보안의 문제는 아직 아무도 생각하지 못한 것들입니다. 보장은 없습니다.

예를 들어 오랫동안 bash의 환경 변수에서 함수를 생성하는 방법에 대해 너무 열심히 생각한 사람은 없었지만 최근 사람들은이를 파괴 할 수 있다는 사실을 깨달았으며 그 영향 중 하나는 ForceCommand가 사용자의 셸이 bash 인 경우 최소한 Authorized_keys 파일에 구현 된대로) 배쉬가 고쳐졌고 버전이 최신 버전이지만, 이런 일이 발생하기를 바랍니다.

ForceCommand를 정의하는 것이 authorized_keys 파일에서 해당 명령을 정의하는 것과 실제로 동일한 지 확실하지 않습니다. 나는 그것을 자세히 보지 않았습니다.

사용자 로그인으로 실행중인 sshd 가 .bashrc소유 root:usergrp하지만 여전히 읽을 수 있도록합니다. 사용자가 새 파일을 만들 수 없도록 $ HOME에서 perms / owner를 설정하십시오. 이 방법으로 root는의 내용을 제어 .bashrc하여 필요한 것을 수행 할 수 있지만 사용자 자신은 해당 설정이나 파일 / 디렉토리에 대한 권한을 변경하여 내용을 변경할 수 없습니다 .bashrc.

다른 생각이 있습니다. 요새 서버의 각 사용자에 대해 / etc / passwd에서 쉘을 ssh user1 @ machine1, user2 @ machine2 등을 실행하는 bash 스크립트로 정의 할 수 있습니다. 이렇게하면 유효한 서버가 없는지 확인할 수 있습니다. 서버 자체의 쉘에 연결되어 있어야합니다.