여러 Github 프로젝트에 동일한 배포 키 사용

여러 Github 프로젝트에 동일한 배포 키 사용

Github은 둘 이상의 프로젝트에 동일한 ssh 배포 키를 사용하도록 허용하지 않습니다. 이는 경우에 따라 매우 유용합니다(예: 개인 하위 모듈을 사용하는 프로젝트를 처리하는 CI 서버).저는 이러한 제한이 '보안상의 이유' 때문이라고 말하는 것처럼 보이는 다양한 스레드를 보았지만, 정확히 어떤 위험이 발생하는지에 대한 설득력 있는 설명은 아직 보지 못했습니다.

Github이 계정 수준 키의 재사용을 허용하지 않는다는 사실은 타당합니다(두 사용자가 키를 공유하면 안 됩니다).제가 의문을 제기하는 것은 배포 키에 대한 제한입니다.

그리고 분명히 말씀드리면, 저는 해결 방법(더미 사용자 만들기, 여러 키 사용 등)을 찾고 있는 것이 아니라, 키 배포에 대한 이러한 제한에 대한 타당한 설명을 찾고 있는 것입니다.

관련 스레드:

• 해결 방법을 보여주는 하나
• 하나는 문제를 논의하지만 실제로는 아무 데도 가지 않습니다.

불행하게도, 이것은 github이 단지 키 쌍과 계정 또는 프로젝트 사이의 구별을 잘못 해석하는 시나리오입니다.

키 쌍은 인증 및 권한 부여에 사용되므로 사실상 ID입니다.Github 계정은 또 다른 정체성입니다.github 계정을 키 쌍에 연결하면 github 계정 기반 ID와 키 쌍 ID 간의 1:N 매핑이 효과적으로 설정됩니다.

반대로 github은 프로젝트를 키 쌍 기반 ID에 1:N 매핑을 적용합니다.현실 세계의 유사점은 많은 다른 사람들에 의해 잠금 해제될 수 있는 프로젝트에 대한 접근을 허용하는 문이 있다는 것입니다.하지만 그들 중 누구라도 문 열쇠를 얻으면, 다시는 다른 문 열쇠를 얻을 수 없습니다.

키가 손상된 경우 위반을 방지하는 관점에서 키를 자주 재사용하지 않는 것이 좋습니다.하지만 그것은 좋은 행정 정책일 뿐입니다.원칙적으로 키가 두 번 이상 사용되지 않도록 하는 것은 의미가 없습니다.다시는 사용하지 않는 몇몇 문들의 열쇠들이 있다는 것은 정책에 달려 있습니다.

---

좀 더 복잡한 보기는 키 쌍을 역할로 설명하는 것입니다.여러 키 쌍을 소유할 수 있으므로 여러 역할에 사용할 수 있습니다.개인 키는 역할에 대해 사용자를 인증합니다.

Github의 프로젝트에 대한 배포 키 매핑은 역할이 두 개 이상의 작업을 포함할 수 없음을 나타냅니다.그것은 현실적이지 않습니다.

물론 그 중 어느 것도 깃허브가 허용하는 것을 바꾸지 않습니다.

한 사용자를 하는 경우)에서이유는 다음과 .id_rsa.REPONAME.pub다음과 같습니다.

다른 사용자에 대한 공용/개인 키 공유 방지

사용자의 상황(여러 프로젝트 빌드)에서는 그렇지 않지만, 동일한 ssh 키를 재사용할 수 있도록 허용하면 서로 다른 두 사용자가 동일한 ssh 키를 공유할 가능성이 열려 인증 목적이 실패할 수 있습니다.

인증은 다음을 의미합니다.
"특정 SSH 키를 사용하는 것은 누가 그것을 사용하는지 알아야 한다는 것을 의미합니다."

그러나 jtlindsey의 답변에서 언급한 바와 같이, 이는 인증/아이덴티티/정상 정책과는 관련이 없으며 이러한 키에 연결하는 "역할"과 더 관련이 있습니다.(특정 리포지토리를 배포하는 역할).

tkeeler의 "두 개 이상의 github repo에서 하나의 ssh 키를 사용할 수 없는 이유는 무엇입니까?"에서 언급한 대로:

이 워크플로우는 자동화된 시스템 및 Git 하위 모듈을 사용할 때 문제가 됩니다.
둘 이상의 repo에서 동일한 배포 키를 사용할 수 없으므로 해결 방법은 해당 키를 사용자 계정(또는 전용 시스템 계정)에 추가하는 것입니다.

최소한의 저항 경로를 사용하면 대부분의 사용자가 자신의 계정에 이를 추가하여 보안 위험이 커집니다.

GitHub은 사용자가 저장소별로 위험을 선택하고 부담하도록 허용해야 합니다.

---

GitHub 페이지 "배포 키 관리"에서는 ssh를 사용하는 다양한 계정에 대해 자세히 설명합니다.

• SSH 에이전트 전달:에이전트 전달은 서버에 SSH를 입력하고 git 명령을 실행할 때 로컬 개발 시스템에 이미 설정된 SSH 키를 사용합니다.
  선택적으로 원격 서버가 로컬 ssh-에이전트가 서버에서 실행되는 것처럼 액세스하도록 할 수 있습니다.
  따라서 서버에서 개인 키를 복제할 필요가 없습니다.

• 컴퓨터 사용자: (이것이 "더미 계정" 전략입니다.)키를 사용자 계정에 연결합니다.이 계정은 사람이 사용하지 않기 때문에 기계 사용자라고 합니다.
  그러나 이 사용자를 인간과 동일한 방식으로 취급하면 키를 일반 계정인 것처럼 기계 사용자 계정에 첨부할 수 있습니다.
  계정 공동작업자 또는 팀에게 액세스해야 하는 리포지토리에 대한 액세스 권한을 부여합니다.
  따라서 서버당 하나의 "머신 사용자"와 연결된 개인 키가 하나씩 있습니다.

(DHA는 배포 키 제한 번호에 대한 설명과 하나의 컴퓨터 사용자 계정만 가질 수 있다는 사실을 지적합니다.)

• 서버에 저장되고 단일 저장소 GitHub에 대한 액세스 권한을 부여하는 배포 키(GitHub repo당 하나) SSH 키.
  이 키는 사용자 계정이 아닌 repo에 직접 연결됩니다.
  계정 설정으로 이동하는 대신 대상 repo의 관리 페이지로 이동합니다.
  "동이로 이동Deploy Keys를 클릭합니다.Add deploy key공용 키를 붙여넣고 제출합니다.

이번에는 SSH 키가 (여러 리포에 대한 액세스 권한을 부여할 수 있는) 사용자에게 연결되지 않고 하나의 리포에 연결됩니다.
여러 repo에 대해 ssh 액세스 권한을 부여하는 것은 "머신 사용자"와 같습니다.

인증 측면:

• 사용자가 동일한 키를 여러 리포지토리에 사용하는 경우(해당 키가 자신의 계정에 연결된 경우) 괜찮습니다.
• 키가 레포에 의해 연결된 경우 여러 레포에 대해 동일한 키를 사용하는 것은 좋지 않습니다. 누가 무엇에 액세스했는지 전혀 모르기 때문입니다.
  이는 "사용자"가 많은 repo의 공동 작업자로 선언되는 "머신 사용자"와는 다릅니다.
  여기(Deploy 키)에는 "공동작업자"가 없으며, repo에 직접 SSH 액세스 권한만 부여됩니다.

---

Yusuf Bhabhrawala는 코멘트에서 이 모델의 한계를 자세히 설명합니다.

개인 pip 모듈을 사용하는 파이썬 프로젝트 또는 개인 npm 패키지를 사용하는 노드 프로젝트와 같은 매우 그럴듯한 사용 사례를 고려해 보십시오.

현재로서는 배포 키 또는 계정 키를 사용하여 이 매우 단순한 사용 사례를 배포할 방법이 없습니다(다른 저장소가 너무 많이 노출됨).

그리고 Chris Stenkamp는 "'가 ssh 키를 검색하는 pip install git+ssh://...위치를 찾는 방법?"을 지적합니다. 여기에는 다음과 같은 설정이 포함됩니다.GIT_SSH_COMMAND환경 변수입니다.

해결책을 찾고 있지 않다는 것은 알지만 많은 사용자가 이 페이지에 접속할 것으로 예상되며 간단한 해결책도 원합니다.링크를 게시한 주변 작업은 githubdocs에 있는 것과 유사합니다.프로세스를 수동으로 수행하면 오류가 발생하기 쉽습니다.

참고로, Bitbucket.org 에는 이러한 제한이 없습니다.여러 리포지토리에서 동일한 읽기 전용 액세스 키를 사용할 수 있습니다.따라서 여러 저장소가 있는 단일 프로덕션 서버를 매우 쉽게 사용할 수 있습니다.

만약 당신이 Github을 고수한다면, 여기 당신이 단순히 당신의 저장소 소유자 이름과 저장소 이름을 전달할 수 있도록 하는 스크립트가 있습니다../generateDeployKey.sh repo_owner_name repo_name그리고 그것은 당신을 위해 모든 것을 해주고 당신이 복사해야 할 것들을 출력합니다.

을 파일 이름이 "" " " 인 새 합니다.generateDeployKey.sh

#!/bin/sh
# This script generates a ssh key for a single repository
# and adds a custom configuration to the users (not global) ssh config file,
# and outputs the public key for you to copy and paste as the repo deploy key
# and outputs the url for you to clone the repo on the machine.
# Github docs ref:
# https://docs.github.com/en/developers/overview/managing-deploy-keys#using-multiple-repositories-on-one-server
#
# 1. Add the script to the user account of the machine. The home directory is fine.
# 2. Make the script executable by running the following command as the user:
# chmod u+x generateDeployKey.sh
# 3. Run script like `./generateDeployKey.sh REPO_OWNER_NAME REPO_NAME` Note the space between owner and repo name. Example:
# ./generateDeployKey.sh yourname hello_world
# If you make a mistake with what you pass in, you can remove change from your ~/.ssh/config file
# by deleting the most recent "New Key Generated on...." and deleting the related .pub and private keys


# Check if user passed in both parameters
if [ -z "$1" ] || [ -z "$2" ]
then
  echo "Make sure to pass in both parameters REPO_OWNER_NAME and REPO_NAME. Example:"
  echo "./generateDeployKey.sh yourname hello_world"
else
  REPO_OWNER_NAME=$1
  REPO_NAME=$2
  KEY_PATH=~/.ssh/id_rsa.$REPO_NAME
  echo "Generating ssh key At ${KEY_PATH}"
  ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa.${REPO_NAME}
  echo "Your ssh deploy key is:"
  PUB_KEY_PATH=$KEY_PATH".pub"
  cat $PUB_KEY_PATH
  echo ""
  # Will create config if it does not exist
  echo "Updating ~/.ssh/config"
  DATE_TIME=$(date +"%Y-%m-%d at %r")
  echo "
  # New Key Generated on $DATE_TIME
  Host github.com-$REPO_NAME
    HostName github.com
    User git
    IdentityFile $KEY_PATH" >> ~/.ssh/config
  echo ""
  echo "Here is your hostname's alias to interact with the repository using SSH:"
  echo "git clone git@github.com-$REPO_NAME:$REPO_OWNER_NAME/$REPO_NAME.git"
fi

시사점을 합리화하는 데는 많은 생각이 필요했고 이 시나리오를 생각해냈습니다.

여러 리포지토리에 할당한 사용자에 대한 단일 배포 키를 생성한다고 가정합니다.이제 해당 키를 취소하려고 하지만 여러 위치에서 사용되고 있습니다.따라서 모든 액세스를 취소할 수 있는 대신 실수로 부분 액세스만 취소할 수 있습니다.

이것은 이점처럼 들릴 수도 있지만 인간적인 요소를 고려하면 이 다대일 관계는 실제로 본질적으로 불안정합니다.이는 모든 리포지토리를 검사하고 각 공용 키를 실제로 할당한 위치에 잊어버린 경우 각 공용 키를 개별적으로 비교하지 않고 모든 액세스를 취소했는지 여부를 확실히 알 수 없기 때문입니다.

이렇게 많은 고유한 키를 할당하고 관리하는 것은 분명 실망스럽지만 GitHub이 정책을 어떻게 도입했는지에 대한 보안 영향은 분명합니다. 키를 취소할 때 해당 키가 한 곳에서만 사용되기 때문에 해당 키가 부여한 모든 액세스를 취소할 수 있습니다.

"공식" 솔루션은 https://docs.github.com/en/developers/overview/managing-deploy-keys#using-multiple-repositories-on-one-server 입니다.
으로 각 이 문제의 입니다.

배포를 위해 읽기 전용 액세스 권한을 가진 사용자 한 명을 추가로 지불해야 합니까?

(GitHub) 저장소 배포mnet 키가 잘못된 방법임은 분명합니다.

이 작업을 수행하기 위해

• (웹) 서버당 Git(Github 또는 기타) 사용자가 필요합니다.
• 이 사용자의 전자 메일 주소가 필요합니다(재설정 목적).
• 키(를 " " "로 합니다.ssh-keygen
• Git(Github) 사용자를 위한 동반된 개인 키
• 공용 키는 (웹) 서버의 .vmx 폴더에 있습니다.
• 개인 키는 로그온을 위해 Git(Github) 계정에 들어갑니다.

당신의 저장소에서.

• 개인 리포지토리에 대한 읽기 권한이 있는 공동작업자로 사용자 초대

이제 서버에서 저장소에 대한 액세스(읽기) 권한을 가지며 웹 훅으로 자동 복제를 수행할 수 있습니다.

언급URL : https://stackoverflow.com/questions/13225826/using-the-same-deploy-key-for-multiple-github-projects