id_rsa.pub신뢰할 수 없는 사용자, 낯선 사람이 내 서버와 특정 사용자 authorized_keys( git내 경우에는 사용자) 에 업로드하도록 허용해야 합니다 . 수동으로 아무것도 하지 않고도 이를 달성하는 가장 안전한 방법은 무엇입니까?
저는 구체적으로 웹 인터페이스를 고려하고 있지만 다른 접근 방식에 강력한 장점이 있다면 아이디어에 개방적입니다.
http 데몬은 사용자로 실행되며 http손상 을 방지하기 위해 git사용자 공격에 취약하지 않아야 합니다 .httphttp
답변1
다른 프로세스를 중개인으로 사용하십시오. 웹 서비스(또는 기타 서비스)는 어딘가에 있는 스풀에 새 요청을 씁니다. 중간자(man-in-the-middle)는 스풀을 모니터링하고, 새 항목을 제거하고, 온전성 검사를 수행하고, gitAuthorized_keys 파일에 페이로드를 추가합니다. 동일한 중개인이 웹 서비스가 읽을 수 있는 피드백을 제공할 수 있습니다. 그러나 감염된 http사용자는 중개인이나 git 사용자를 조작할 수 없습니다. 중개인은 데몬일 수도 있고 크론 작업일 수도 있습니다.
git또는 분명히 나쁜 생각이 있기 때문에 :) 1) 사용자는 어쨌든 자신의 파일에 대한 쓰기 액세스 권한을 갖고 authorized_keys2) 사용자가 있는 모든 사람에게 SSH에서 허용되는 액세스 권한을 갖게 된다는 사실을 활용할 수 있습니다. git. 따라서 귀하의 http사용자는 "누구나"에 속하므로 http사용자에게 SSH 키 쌍을 제공하고 공개 키를 git사용자의 인증된 키 파일에 추가하십시오. 이제 웹 서비스는 간단히 ssh -n git@localhost echo $key >> ~/.ssh/authorized_keys.
git오픈 액세스 사용자가 셸을 얻는 것을 원하지 않지만 (보안이 중요하기 때문에) 여전히 git pushSSH를 통한 게시를 허용하는 경우 공개 키 제출만 생성하여 실제 메타데이터를 얻을 수 있습니다. 저장소. 사용자 http는 이 저장소의 복제본을 갖게 되며 웹 서비스는 커밋 및 푸시를 실행합니다. 그런 다음 서버 측 후크는 제출된 키에 대해 온전성 검사를 수행하고 git검증 후 이를 사용자의 Authorized_keys 파일에 추가할 수 있습니다.
하지만 모든 일이 어떻게든 끝났다고 가정해 봅시다. 여러분은 누구나 여러분의 사용자에게 자신의 SSH 액세스 권한을 부여할 수 있는 시스템을 갖게 될 것입니다 git. 그렇다면 SSH 인증의 요점은 정확히 무엇입니까? 낯선 사람이 쉘 액세스 권한을 갖기를 원하십니까? git사용자 비밀번호를 지우고 빈 비밀번호를 허용하면 안 되는 이유는 무엇입니까 ? 또는 이러한 사용자에게 SSH를 통한 복제 기능 이외의 기능을 제공하지 않으려면 http 또는 git 프로토콜을 통해 저장소를 제공하고 전체 혼란을 피하는 것은 어떨까요?
답변2
authorized_keys신뢰할 수 없는 사용자가 자신의 공개 키를 사용자 의 파일 에 추가하도록 허용할 수 있으므로 해당 git사용자에게 비밀번호를 알려주는 것이 좋습니다 git.