GitHub이 이전에 SSH를 통해 HTTPS를 권장한 이유는 무엇입니까?
GitHub 사이트에 링크가 있습니다...
https://web.archive.org/web/20130114042103/https ://help.github.com/articles/generating-ssh-keys
그리고 그것은...
권장되는 HTTPS 방법을 사용하지 않기로 결정한 경우 SSH 키를 사용하여 컴퓨터와 GitHub 간에 보안 연결을 설정할 수 있습니다.아래 단계에서는 SSH 키를 생성한 다음 GitHub 계정에 공용 키를 추가하는 과정을 안내합니다.
HTTPS가 권장되는 방법은 무엇입니까?SSH 방식에 보안 결함이 있습니까, 아니면 더 느립니까?SSH 키를 생성했는데, 보안 문제가 완화됩니까?
GitHub은 권장 사항을 여러 번 변경했습니다(예).
HTTPS가 가장 광범위한 네트워크와 플랫폼에서 가장 쉽게 설정할 수 있고 이 모든 것을 처음 접하는 사용자가 설정할 수 있기 때문에 현재 HTTPS를 권장하는 것으로 보입니다.
SSH에는 본질적인 결함이 없습니다. 아래 링크에서 SSH 연결에 대한 세부 정보도 제공합니다.
HTTPS는 방화벽에 의해 차단될 가능성이 적습니다.
그
https://복제 URL은 표시 여부에 관계없이 모든 리포지토리에서 사용할 수 있습니다.https://복제 URL은 사용자가 방화벽 또는 프록시 뒤에 있더라도 작동합니다.HTTPS 은 HTTPS를 합니다.
credential.helper암호를 캐시합니다.https://docs.github.com/en/get-started/quickstart/set-up-git#connecting-over-https-recommended
HTTPS로 복제하는 경우 자격 증명 도우미를 사용하여 Git에서 GitHub 자격 증명을 캐시할 수 있습니다.자세한 내용은 "HTTPS URL을 사용한 복제" 및 "Git에서 GitHub 자격 증명 캐싱"을 참조하십시오.
HTTPS는 몇 가지 이유로 GitHub에서 권장하는 것 같습니다.
리포지토리에 쓰는 데 SSH 키가 필요하지 않은 계정 세부 정보만 있으면 되므로 어디서나 리포지토리에 액세스하는 것이 더 간단합니다.
HTTPS는 모든 방화벽에서 열려 있는 포트입니다.SSH가 항상 외부 네트워크와의 통신을 위한 포트로 열려 있는 것은 아님
따라서 GitHub 저장소는 SSH보다 HTTPS를 사용하여 보다 보편적으로 액세스할 수 있습니다.
SSH 키는 SSH 키를 생성하는 데 약간의 추가 작업을 수행할 가치가 있습니다.
SSH 키는 GitHub 계정에 대한 액세스를 제공하지 않으므로 키를 도난당한 경우 계정을 도용할 수 없습니다.
SSH 키와 함께 강력한 키 구문을 사용하면 키를 도난당한 경우(컴퓨터 계정에 대한 액세스 보호를 처음 해제한 후)에도 오용이 제한됩니다.
GitHub 계정 자격 증명(사용자 이름/암호)을 도난당한 경우 GitHub 암호를 변경하여 액세스를 차단하고 모든 공유 리포지토리를 신속하게 삭제할 수 있습니다.
개인 키를 도난당한 경우 누군가가 빈 리포지토리를 강제로 밀어넣어 소유한 각 리포지토리에 대한 모든 변경 기록을 삭제할 수 있지만 GitHub 계정에서는 아무것도 변경할 수 없습니다.GitHub 계정에 액세스할 수 있는 이러한 위반을 복구하는 것이 훨씬 쉬워질 것입니다.
암호 보호 키와 함께 SSH를 사용하는 것을 선호합니다.저는 컴퓨터마다 다른 SSH 키를 가지고 있기 때문에 컴퓨터가 도난당하거나 키가 손상되면 GitHub에 빠르게 로그인하여 해당 키를 삭제하여 원치 않는 액세스를 방지할 수 있습니다.
현재 네트워크가 SSH 포트를 차단하는 경우 HTTPS를 통해 SSH를 터널링할 수 있습니다.
https://help.github.com/articles/using-ssh-over-the-https-port/
HTTPS를 사용하는 경우 계정과 리포지토리를 보호하기 위해 이중 인증을 추가하는 것이 좋습니다.
HTTPS를 도구(예: 편집기)와 함께 사용하는 경우 해당 도구 구성에서 사용자 이름과 암호를 캐시하는 대신 GitHub 계정의 개발자 토큰을 사용해야 합니다.토큰은 매우 특정한 액세스 권한에 대해 토큰을 구성할 수 있고 토큰이 손상된 경우 쉽게 해지될 수 있으므로 HTTPS 사용의 잠재적 위험을 일부 완화할 수 있습니다.
잘못된 인용을 하고 있거나 github이 다른 페이지에서 다른 권장 사항을 가지고 있거나 시간이 지남에 따라 학습하여 기록을 업데이트할 수 있습니다.
GitHub와 상호 작용할 때는 SSH 연결을 사용하는 것이 좋습니다.SSH 키는 암호를 사용하지 않고 신뢰할 수 있는 컴퓨터를 식별하는 방법입니다.아래 단계에서는 SSH 키를 생성한 다음 GitHub 계정에 공용 키를 추가하는 과정을 안내합니다.
https://help.github.com/articles/generating-ssh-keys
방화벽에 의해 차단된 경우 HTTPS를 통한 SSH 연결 사용
HTTPS 포트를 통해 SSH가 가능한지 테스트하고 다음 SSH 명령을 실행합니다.
$ ssh -T -p 443 git@ssh.github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.
그게 효과가 있었다면, 훌륭해요!그렇지 않은 경우 문제 해결 가이드를 따라야 할 수도 있습니다.
SSH를 사용할 수 있는 경우git@ssh.github.com포트 443을 통해 SSH 설정을 재정의하여 해당 서버와 포트를 통해 GitHub에 대한 모든 연결을 실행할 수 있습니다.
SSH 구성에서 이를 설정하려면 다음 위치에서 파일을 편집합니다.~/.ssh/config다음 섹션을 추가합니다.
Host github.com
Hostname ssh.github.com
Port 443
GitHub에 다시 연결하여 이 기능이 작동하는지 테스트할 수 있습니다.
$ ssh -T git@github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.
인증에서 GitHub로 / HTTPS 포트를 통해 SSH 사용
또한 help.github.com 의 공식 원격 URL을 참조하십시오.
편집:
SSH URL을 사용하기 위해 더 이상 공용 레포에 대한 쓰기 액세스 권한이 필요하지 않아 제 원래 설명이 유효하지 않습니다.
원본:
HTTPS URL을 선호하는 주요 이유는 SSH URL이 해당 repo에 대한 쓰기 액세스 권한이 없으면 공용 repo에서 작동하지 않기 때문입니다.
그러나 운영 서버에 배포할 때는 SSH URL을 사용하는 것이 좋습니다. 여기서 맥락은 Heroku와 같은 서비스일 것입니다.
SSH 키를 사용하여 인증하는 것이 새 SSH 키를 생성하는 것보다 주기적으로 암호를 변경하는 경향이 있기 때문에 보안이 떨어진다는 주장이 있을 수 있습니다.
지정된 SSH 키의 수명을 제한하는 서버는 사용자가 주기적으로 SSH 키를 새로 고치도록 할 수 있습니다.
HTTPS를 선호하는 또 다른 이유는 여러 사용자가 중앙 서버(예: 개발 시스템)에서 코드를 관리하는 경우 각 사용자가 SSH 기반 연결을 사용하기 위해 자체 ssh 키를 만들어야 한다는 것입니다.연결이 HTTPS이면 이 문제가 없습니다.
프로젝트가 저장된 서버를 사용하는 온보드의 일부로 자신의 키를 설정하는 것이 그렇게 어렵지는 않지만, 작업을 완료하는 데는 더 큰 장애물이 될 수 있습니다.
권장 사항: Git Credential Manager 또는 git-credential-oauth와 같은 자격 증명 생성 도우미와 함께 HTTPS를 사용합니다.
암호 또는 개인 액세스 토큰이 더 이상 없습니다!처음 누르면 도우미가 브라우저 창을 열어 인증합니다.스토리지 수명 내의 후속 푸시는 상호 작용이 필요하지 않습니다.
SSH의 단점:
- 공용 레포를 복제하거나 가져올 때도 인증합니다.
- SSH 클라이언트를 설치해야 합니다.
- SSH 키를 만드는 초기 단계는 많은 사람들에게 생소합니다.
- 중간 사용자 공격으로부터 보호하려면 호스트 지문을 수동으로 확인해야 합니다.모두가 귀찮게 하는 것은 아닙니다!
- 호스트에서 키를 구성하려면 로컬 파일과 웹 사이트 간에 복사하여 붙여넣어야 합니다.호스트가 5개인 시스템 3대를 사용하려면 15개의 로트 구성이 필요합니다.
- 암호가 없는 SSH 키는 만료되지 않고 일반 텍스트로 저장됩니다.
- 암호 구문(사용되는 경우)을 정기적으로 입력해야 합니다.ssh-agent를 구성한 후에도 시스템을 다시 시작할 때마다 암호를 입력해야 합니다.
- SSH는 때때로 방화벽에 의해 차단됩니다.
HTTPS의 장점:
- 필요한 경우에만 인증합니다.공용 레포를 복제하거나 가져올 때 인증이 없습니다.
- 서버 인증은 HTTPS 인증서를 사용하여 자동으로 확인됩니다.
- Git Credential Manager 또는 git-credential-oauth와 같은 자격 증명 생성 도우미를 사용한다고 가정하면 암호를 입력하거나 개인 액세스 토큰을 구성할 필요가 없습니다.
- OAuth 프로토콜은 짧은 기간의 토큰을 사용하고 재생 공격을 탐지하는 토큰 순환을 새로 고침하여 토큰 도난으로부터 보호합니다.
- wincred, osxkeychain 및 libsecret를 비롯한 플랫폼별 스토리지 선택 또는 단순 캐시 선택
언급URL : https://stackoverflow.com/questions/11041729/why-did-github-previously-recommend-https-over-ssh
'programing' 카테고리의 다른 글
| Postgres에서 테이블에 여러 열을 추가하는 방법은 무엇입니까? (0) | 2023.05.16 |
|---|---|
| 생성 간의 차이인덱스() 및 확인mongodb를 사용한 Java의 인덱스() (0) | 2023.05.16 |
| 특정 파일의 오류를 무시하도록 Eclipse 설정 변경 (0) | 2023.05.16 |
| Postgre 구성 방법들어오는 모든 연결을 수락하는 SQL (0) | 2023.05.16 |
| 쿼리를 사용하여 SQL Server에서 null이 아닌 제약 조건을 제거하는 방법 (0) | 2023.05.16 |