☰

사용자가 자신의 .ssh 폴더를 함부로 사용하는 것을 방지하려면 어떻게 해야 합니까?

tag-icon • tag-icon permissions ssh-keys
사용자가 자신의 .ssh 폴더를 함부로 사용하는 것을 방지하려면 어떻게 해야 합니까?

저는 사용자가 개인/공개 키 기반 인증을 사용하여 SSH를 통해 로그인하는 RedHat 서버를 관리하고 있습니다.

실수로 콘텐츠를 변경/삭제/변경하는 것을 방지하고 싶습니다.~/.ssh폴더. 그들 중 일부는 "이 방법으로 동료와 파일을 공유하는 것이 더 쉬웠기 때문에" 이미 자신의 홈 폴더 전체를 재귀적으로 777-chmoded하고 발에 총을 맞았습니다.

어떻게 이것을 달성할 수 있는지 아시나요? 표준 Linux 권한 시스템을 사용하는 것이 좋습니다.

답변1

짧은 대답은 할 수 없다는 것입니다.

SSH는 권한에 대해 매우 까다로우며 모양이 마음에 들지 않는 파일을 재생하지 않습니다. 또한 사용자가 ssh_config구문 분석됩니다.~ 전에시스템 전체 구성.

그러고보니,5월파일을 다른 곳에 두고 디렉토리를 $HOME/.ssh각 사용자에 대한 읽기 전용 파일 시스템으로 마운트할 수 있습니다. (가능합니다. 하지만 ssh 및 관련 도구가 이를 어떻게 처리할지 모르겠습니다.)

그들 중 일부는 이미 자신의 홈 폴더 전체를 재귀적으로 777-chmoded했습니다.

그러면 훨씬 더 큰 보안 및 교육 문제가 발생합니다.

답변2

사용자 자신의 무지와 무능력으로부터 사용자를 보호하기는 어렵습니다.

그러나 사용자가 스스로 관리하도록 허용해야 하는 정도와 사용자를 위해 관리하는 정도에 따라 홈 디렉터리 외부 및 ~/.ssh/authorized_keys.

AuthorizedKeys명령

상대적으로 복잡한 솔루션은 다음과 같습니다./etc/ssh/sshd_config AuthorizedKeysCommand Authorized_keys 파일에 의존하기보다는 지시어는 사용자의 공개 키를 조회하는 데 사용할 프로그램을 지정합니다. 예를 들면 다음과 같습니다.

  • ㅏLDAP 디렉토리

  • ㅏ데이터 베이스

  • (사소한) 웹 서비스

  • 또는 사용자 이름이 Github 사용자 이름과 동일한 경우 사용자가 거기에 업로드한 키 쌍으로 인증하도록 허용할 수 있습니다.

    AuthorizedKeysCommand /usr/bin/curl https://github.com/%u.keys

에서 언급했듯이이 답변; 기본 정책에 의해 차단되므로 AuthorizedKeysCommand에 적합한 SELinux 정책을 생성해야 합니다.

저는 인증된 키 관리와 관련된 많은 문제를 해결할 수 있기 때문에 이 접근 방식을 좋아합니다. 중앙 집중식 관리를 추가하고 SSH에서 비밀번호 인증을 비활성화하려는 경우 서버에 인증된 키를 가져오는 닭과 달걀 문제를 제거하는 등의 문제가 있습니다.
이는 공개 키가 관련 개인 키와 달리 특별히 민감하지 않다는 사실을 활용하므로 관리를 중앙 집중화해도 IMHO 위험이 추가되지 않으며 제어 및 보고 기능도 향상될 수 있습니다.

승인된 키파일

약간 덜 복잡한 것은 홈 디렉터리 외부의 디렉터리에 키를 저장하는 것입니다. 예를 들어 실제 사용자 이름으로 /etc/ssh/<username>바꿉니다 . <username>이 디렉터리에는 755 권한이 있어야 하며 사용자가 소유해야 합니다. authorized_keys파일을 그 안으로 옮깁니다 . Authorized_keys 파일에는 여전히 644 권한이 있어야 하며 사용자가 소유해야 합니다.

~ 안에/etc/ssh/sshd_config조정하다AuthorizedKeysFile환경

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

그리고 SSH 데몬을 다시 시작하세요.

답변3

내가 생각할 수 있는 가장 좋은 해결책은 루트를 소유 .ssh하고 만드는 것입니다.authorized_keys

루트 소유 .ssh/authorized_keys

SSH는 권한이 까다롭지만, 그렇다고 해서 너무 까다롭지는 않습니다. 첫째, 사용자 자신에게 읽기 액세스 권한이 있어야 합니다 authorized_keys(모든 상위 디렉터리에 대한 읽기 액세스 필요). 둘째, 사용자 자신이나 루트 이외의 사용자가 /home, .ssh또는 에 대한 쓰기 액세스 권한을 갖고 있는 경우 액세스를 거부합니다 authorized_keys. 이는 o+w및 g+w다른 사용자가 포함된 그룹을 허용하지 않습니다.

이 설정은 나에게 적합하며 사용자는 로그인할 수 있습니다.

drwxr-xr-x 19 root root 4096 Sep 22 11:24 /
drwxr-xr-x  3 root root 4096 Sep 22 11:19 /home/
drwx------ 14 test test 4096 Sep 22 11:44 /home/test/
drwxr-x---  2 root test 4096 Sep 22 11:42 /home/test/.ssh/
-rw-r--r--  1 root test   98 Sep 22 11:36 /home/test/.ssh/authorized_keys

.ssh및 은 루트 소유 이므로 authorized_keys사용자는 해당 권한을 변경하거나 제거할 수 없습니다. 또한 자신의 authorized_keys파일을 편집할 수도 없습니다.

사용자가 자신의 을(를) 편집할 수 있도록 허용하려면 authorized_keys그룹 쓰기 권한을 추가하면 됩니다. 이를 위해서는 test그룹에 자신 외에 다른 구성원이 없어야 합니다 test.

-rw-rw-r--  1 root test   99 Sep 22 12:04 /home/test/.ssh/authorized_keys

어느 접근 방식을 사용하든 사용자는 더 이상 아래에 자신의 파일을 만들 수 없으므로 .ssh추가 파일도 제공해야 할 수 있습니다. 마음에 떠오르는 일부 키 유형은 known_hosts, config및 id_rsa{.pub,}또는 기타 키 유형입니다.

대안: chattr

일부 Linux 파일 시스템은 다음을 지원합니다.파일 속성, 특히불변 플래그. 불변 플래그가 설정된 파일/디렉토리는 삭제, 수정 또는 권한 변경이 불가능합니다. 루트만이 이 플래그를 설정/삭제할 수 있습니다.

이 명령은 기본 소유권/권한을 사용하더라도 트릭을 수행합니다.

# chattr +i ~test/.ssh/{authorized_keys,}

이제는 어떤 식 .ssh으로든 authorized_keys, 심지어 루트로도 수정할 수 없습니다. 루트가 이러한 파일을 업데이트해야 하는 경우 chattr -i먼저 해당 파일을 업데이트해야 합니다 . 속성을 확인하는 데 사용합니다 lsattr.

이 접근 방식은 더 간단하지만 유연성이 떨어집니다. 또한 파일 시스템 지원이 필요합니다. 적어도 ext2/3/4, XFS 및 btrfs에서 지원된다고 생각합니다.

Posix ACL?

또한 있습니다Posix ACL(액세스 제어 목록)을 사용하면 좀 더 세부적인 제어가 가능합니다. 나는 그것들에 대해 별로 익숙하지 않으며, 이것이 여기서 어떤 도움이 될지 확신할 수 없습니다.

엄격한 모드

메모:매우 권장되지 않지만 완전성을 위해 제공됩니다.

OpenSSH 서버구성 지시어가 있습니다라고 하며 StrictModesSSH의 권한이 얼마나 까다로운지를 결정합니다.

sshd가 로그인을 수락하기 전에 파일 모드와 사용자 파일 및 홈 디렉터리의 소유권을 확인해야 하는지 여부를 지정합니다. 초보자가 실수로 자신의 디렉터리나 파일을 누구나 쓸 수 있도록 남겨두는 경우가 있기 때문에 이는 일반적으로 바람직합니다. 기본값은 입니다 yes.

해당 옵션을 비활성화하면 소유권과 권한을 설정하는 방법이 더 자유로워집니다. 그러나 SSH는 좋은 이유로 기본적으로 엄격합니다. SSH 파일을 777-chmodding하는 사용자는 보안 위험이 있습니다.

답변4

매일 밤 크론 작업을 실행하여 권한을 수정하세요.

파일을 삭제하는 것은 조금 더 어렵습니다. cron의 백업에서 누락된 파일을 복원할 수도 있습니다. 하지만 그렇게 하면 이상한 극단적인 경우에 빠질 수 있는 것 같습니다... 스크립트가 제공할 수 있는 것보다 더 많은 지능이 필요할 수 있습니다. 나는 작게 시작하여 복원 기능에 조심스럽게 기능을 추가했습니다.

관련 정보