여러 github 프로젝트에 동일한 배포 키 사용
Github는 하나 이상의 프로젝트에 동일한 ssh 배포 키를 사용하는 것을 허용하지 않습니다. 이는 경우에 따라 매우 유용합니다 (예 : 비공개 하위 모듈이있는 프로젝트를 처리하는 CI 서버). 이 제한이 '보안상의 이유로'있다고 말하는 여러 스레드를 보았지만 정확히 어떤 위험이 발생할 지에 대한 설득력있는 설명은 아직 보지 못했습니다.
Github에서 계정 수준 키의 재사용을 허용하지 않는다는 사실 은 의미가 있습니다 (두 명의 사용자가 키를 공유해서는 안 됨). 내가 질문하는 것은 키 배포에 대한 제한 일뿐 입니다.
그리고 분명히, 나는이있어 하지 해결 방법을 찾고 (더미 사용자를 생성, 여러 개의 키를 사용하여 ...) 만 배포 키에 이러한 제한에 대한 그럴듯한 설명합니다.
관련 스레드 :
참조하는 해결 방법 (단일 "빌드"사용자 생성 또는 id_rsa.REPONAME.pub저장소 당 동일한 공유)에 설명 된 유일한 이유 는 다음과 같습니다.
다른 사용자에 대해 공개 / 개인 키 공유 방지
귀하의 상황 (여러 프로젝트 빌드)에서는 그렇지 않더라도 동일한 ssh 키를 재사용하면 두 명의 다른 사용자가 동일한 ssh 키를 공유 할 수 있는 가능성이 열리고 인증 목적 이 무효화 됩니다.
인증은
"특정 ssh 키를 사용하는 것은 누가 사용하고 있는지 알고 있어야 함을 의미합니다"를 의미합니다 .
GitHub 페이지 " 배포 키 관리 "는 ssh를 사용하는 다양한 계정에 대해 자세히 설명합니다.
SSH 에이전트 전달 : 에이전트 전달은 서버에 SSH로 로그인하고 git 명령어를 실행할 때 로컬 개발 머신에 이미 설정된 SSH 키를 사용합니다.
원격 서버가 서버에서 실행중인 것처럼 선택적으로 로컬 ssh-agent에 액세스하도록 할 수 있습니다.
따라서 서버에서 개인 키를 복제 할 필요가 없습니다.컴퓨터 사용자 : (이는 "더미 계정"전략입니다.) 사용자 계정에 키를 연결합니다. 이 계정은 사람이 사용하지 않으므로 컴퓨터 사용자라고합니다.
이 사용자를 사람과 같은 방식으로 취급하고 키를 일반 계정 인 것처럼 컴퓨터 사용자 계정에 연결합니다.
계정 공동 작업자 또는 팀이 액세스해야하는 저장소에 대한 액세스 권한을 부여합니다.
따라서 하나의 "머신 사용자"와 관련된 하나의 개인 키, 서버 당 하나씩.서버에 저장되고 GitHub의 단일 저장소에 대한 액세스 권한을 부여하는 SSH 키 (GitHub 리포지토리 당 하나)를 배포합니다 .
이 키는 사용자 계정 대신 저장소에 직접 연결됩니다 .
계정 설정으로 이동하는 대신 대상 저장소의 관리 페이지로 이동하십시오.
"Deploy Keys"로 이동하여 " "을 (를) 클릭하십시오Add deploy key. 공개 키를 붙여넣고 제출하십시오.
이번에는 ssh 키가 사용자 (여러 저장소에 대한 액세스 권한을 부여 할 수있는 사용자)에게 연결되지 않고 하나의 저장소에 연결됩니다. 여러 저장소에
ssh 액세스 권한을 부여하는 것은 "머신 사용자"와 동일합니다.
의 용어에서 인증 :
- 여러 저장소에 동일한 키를 사용하는 것은 사용자가 수행 한 경우 (자신의 계정에 연결된 키가 있음) 괜찮습니다.
- 여러 리포지토리에 동일한 키를 사용하는 것은 키가 리포지토리에 연결되어있을 때 누가 무엇에 액세스했는지 전혀 모르기 때문에 괜찮지 않습니다 .
이는 "사용자"가 많은 저장소의 공동 작업자로 선언되는 "머신 사용자"와 다릅니다.
여기 (Deploy key) 에는 "collaborator"가 없으며 저장소에 직접 SSH 액세스 권한 만 부여됩니다.
불행히도 이것은 github가 키 쌍과 계정 또는 프로젝트 간의 차이를 잘못 해석하는 시나리오입니다.
키 쌍은 인증 및 권한 부여에 사용되기 때문에 사실상 ID입니다. Github 계정은 또 다른 ID입니다. github 계정을 키 쌍에 연결하면 github 계정 기반 ID와 키 쌍 ID간에 1 : N 매핑이 효과적으로 설정됩니다.
반대로 github는 키 쌍 기반 ID에 대한 프로젝트의 1 : N 매핑을 적용합니다. 현실 세계의 유사점은 많은 다른 사람들이 잠금을 해제 할 수있는 프로젝트에 대한 액세스 권한을 부여하는 문이 있다는 것입니다. 그러나 그들 중 누구라도 문에 대한 열쇠를 얻으면, 그들은 다시는 다른 문에 대한 다른 열쇠를 얻을 수 없습니다.
키가 손상 될 경우 위반을 포함하는 관점에서 키를 자주 재사용하지 않는 것이 좋습니다. 그러나 그것은 단지 좋은 행정 정책 일뿐 입니다. 원칙적 으로 키가 두 번 이상 사용되는 것을 방지하는 것은 의미가 없습니다 . 재사용되지 않는 일부 문에 대한 몇 가지 열쇠가 있다는 것은 다시 한 번 정책에 달려 있습니다.
약간 더 복잡한보기는 키 쌍을 역할로 설명하는 것 입니다. 많은 키 쌍을 소유 할 수 있으므로 많은 역할을 수행합니다. 개인 키는 역할에 대해 사용자를 인증합니다.
프로젝트에 대한 Github의 배포 키 매핑에 따르면 역할은 하나 이상의 작업을 포함 할 수 없습니다. 그것은 거의 현실적이지 않습니다.
물론 github가 허용하는 것을 변경하는 것은 없습니다.
그 의미를 합리화하기 위해 많은 생각이 필요했고이 시나리오를 생각해 냈습니다.
여러 저장소에 할당 한 사용자에 대해 단일 배포 키를 생성한다고 가정 해보십시오. 이제 해당 키를 취소하고 싶지만 여러 곳에서 사용됩니다. 따라서 모든 액세스를 취소하는 대신 실수로 부분 액세스 만 취소 할 수 있습니다.
이것은 이익처럼 들릴 수 있지만이 다 대일 관계는 인적 요소를 고려하면 실제로 본질적으로 안전하지 않습니다. 이는 모든 리포지토리를 검사하지 않고 모든 액세스 권한을 실제로 취소했는지 확실하지 않고 실제로 할당 한 위치를 잊은 경우 각 공개 키를 개별적으로 비교할 수 없기 때문입니다.
너무 많은 고유 키를 할당하고 관리하는 것은 확실히 실망 스럽지만 GitHub가 정책을 수립 한 방법에 따라 보안에 미치는 영향이 분명 합니다. 키를 취소하면 해당 키가 부여한 모든 액세스 권한이 한 곳에서만 사용되기 때문에 취소됩니다. .
참고 URL : https://stackoverflow.com/questions/13225826/using-the-same-deploy-key-for-multiple-github-projects
'development' 카테고리의 다른 글
| Android에서 알림에 버튼을 추가하는 방법은 무엇입니까? (0) | 2020.10.22 |
|---|---|
| Android SoundPool은 얼마나 나쁜가요? (0) | 2020.10.22 |
| Microsoft.Bcl.Build NuGet 패키지의 기능은 무엇입니까? (0) | 2020.10.22 |
| C #의 인터페이스에서 XML 주석 상속 (0) | 2020.10.22 |
| YAML 배열을 병합하는 방법은 무엇입니까? (0) | 2020.10.22 |