들어가며

  안전한 보안을 위한 좋은 방법 중 하나는 Two Factor Authentication (2FA)를 계정에 설정해두는 것이다. 사이드마다 다른 비빌먼호 생성, 주기적인 비밀번호 변경보다 훨씬 쉽게 보안 수준을 높게 유지할 수 있다. 그런데 github에 2FA 인증을 설정해두면 서드파티 앱이나 shell에 있는 git 에서 remote repository (remote)에 접근을 하기 어려워진다. 또한 지난 2021년 8월 13일부로 github 계정을 사용한 remote 접근이 완전히 차단되어서 더이상 단순히 비밀번호를 입력해서 접근하기가 어려워졌다. 때문에 아래와 같은 방법을 통해 remote에 접근 할 수 있다.

1. Token 발급 : sub-password의 역할을 하는 token을 발급받아 비밀번호 대용으로 쓰는 방식으로, 각 token 마다 유효기간, 권한등을 설정할 수 있다. 기존의 github 계정 비빌번호를 사용하는 방법을 완전히 대체 가능하다.

2. OAuth : Open Authentication. 로컬 git, 서트파티앱에 github 로그인 정보를 제공하지 않고 github에 연결하게 해주는 인증방식이다.

3. SSH : 이 글에서 다룰 내용으로 한번 설정만 제대로 한다면 편리하고 보안성도 좋다.

설정 난이도만 생각하면 Token을 발급받는 방법이 가장 쉽다. Token을 발급받아서 필요한 권한을 준 뒤, 어딘가에 적어두고 remote를 연결할 때 사용하면 된다. 그러나 더 높은 보안과 편리성을 위해서는 SSH를 사용하는 것을 추천한다.

SSH 연결 특징

  SSH는 Secure SHell의 약자이며 구체적인 SSH 통신 방법은 여기에서 다루지 않겠다. 대신, SSH 를 사용하면 어떤 것들이 필요하고, HTTPS를 사용하는 방식과는 어떻게 다른지 비교를 하겠다.

사용자 이름을 knowblesse, repository 이름을 myrepo라고 했을 때 HTTPS와 SSH에서 필요한 것은 아래와 같다.

차이점 1 : remote 주소

SSH는 인증방식이 아니라 (보안 인증 프로토콜을 포함하고 있는) 통신 방식이다. 때문에 일반적으로 알고 있는 https로 시작하는 주소가 아닌 git@github.com 으로 시작하는 주소를 입력해야한다.

차이점 2 : 인증

SSH에서는 public key와 private key, 두 가지 파일을 사용하는 공개키 암호화 방식을 기본으로 택하고 있다. 처음에 key 생성기를 사용해서 서로 매치가 되는 public key와 private key를 생성하고, 인증을 원하는 곳에 public key를 제공하면 이후 접속시 private key를 이용해서 인증받을 수 있다.

차이점 3 : Credential 저장

token을 사용하는 HTTPS 방식에서는 credential.helper를 사용해서 token을 저장해둘 수 있다. SSH에서는 ssh-agent를 사용해 credential을 저장한다.

SSH 연결 설정

SSH 연결 설정 순서는 다음과 같다.

1. SSH 키가 없는 경우 : SSH 키 생성

2. Github에 SSH 등록

3. local repository에 SSH 기반 remote 주소 등록

4. ssh-agent 셋업 및 연결 방법

1. SSH 키 생성

    SSH 키 생성은 다양한 프로그램이 지원하고 있는데, Window와 Linux 모두 기본으로 설치되어있는 ssh-keygen을 사용하는 방법이 가장 보편적이다.

먼저 기존에 생성해둔 ssh키가 없는지 간단히 확인한다.

Window ("C:\Users\Knowblesse") 와 Linux ("\home\Knowblesse") 의 유저폴더 안에 ".ssh" 라는 명칭의 폴더 안에 .pub로 끝나는 파일이 있는지 확인해보면 된다. 키 생성을 한번도 안한경우 폴더 자체가 없을 것이다.

Window cmd나 Linux shell에서 다음과 같이 ssh-keygen을 실행하자.

> ssh-agent -t ed25519

ssh-agent는 기본 옵션으로 rsa key pair를 만드는데 최신 방식은 ed25519라고 한다. 기본 옵션으로 키를 생성하려면 "ssh-agent"만 실행하면 된다.

이후 파일을 저장할 위치를 묻는데 default 위치를 그대로 사용해야지, 다른 곳에 저장을 했다가는 추가로 key 위치를 입력해주는 작업을 해야한다. 가능하면 ~/.ssh 폴더 안에 생성하도록 그대로 두자.

> ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\Knowblesse/.ssh/id_ed25519):

다음으로는 password를 묻는다.

> ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\Knowblesse/.ssh/id_ed25519):
Enter passphrase (empty for nopassphrase):

이 passphrase는 private key를 한번 더 암호화 하는데에 사용된다. private key에도 암호를 걸어두는 것을 적극 권장한다.

Q. 왜 passphrase를 설정하나요?
A. 행여나 private key가 노출되었을때를 방지하기 위함입니다. 실질적인 보안은 사실 public/private key 쌍이 담당하고 있기에 passphrase를 복잡하게 설정할 필요는 없습니다. 때문에 명칭도 password가 아니라 phrase 입니다.

private key에 암호설정 과정을 마치면, 아래와 같은 출력 메시지 후에 public key와 private key가 생성된다.

.pub 확장자를 가진 파일이 public key, 아무런 확장자가 없는 파일이 private key 이다.

생성된 두 파일은 텍스트 편집기로 열 수 있는 plain text 파일이며 private key는 절대 인터넷 상에 노출이 되면 안된다.

Q. 어차피 private key는 public key와 인증을 거치는 과정 중에서 인터넷 상에 노출되지 않나요?
A. SSH 인증에 사용하는 비대칭 공개키 암호화 방식은 1) 서버가 랜덤한 메시지를 호스트로 보내고, 2) 이를 받은 호스트는 private key로 암호화를 해서 다시 서버에게 보내고, 3) 암호화된 메시지를 받은 서버가 자신이 가지고 있는 public key를 사용해 복호화 한 뒤, 원래 보냈던 메시지와 비교하는 방식입니다. 때문에 private key는 인터넷 상에 절대 노출되지 않습니다.

2. Github에 SSH 등록

    생성한 public키는 Github에 등록할 수 있다.

새로운 SSH 키 등록 버튼을 누른 뒤, 텍스트 편집기로 .pub 파일을 열어서 내용을 붙여넣으면 된다.

3. local repository에 SSH 기반 remote 주소 등록

    여기서부터 살짝 까다로워 진다.

3-1. 처음 repository를 생성하는 경우 (clone 하는 경우)

https 기반 주소가 아니라 아래처럼 SSH 기반 주소를 입력하면 끝난다.

> git clone git@github.com/knowblesse/myrepo

3-2. 기존에 생성된 repository를 변경하는 경우

remote에 연결된 url 을 SSH 형식으로 수정하는 작업이 필요하다.

> git remote
origin

먼저 git remote 커맨드로 어떤 remote 와 연결되어있는지 확인한다. 위의 예시에서는 origin만 연결되어 있다.

추가로 아래 커맨드를 사용하면 origin의 url을 볼 수 있다.

> git remote get-url origin
https://github.com/knowblesse/myrepo.git

url의 변경은 set-url을 사용하면 된다.

> git remote set-url origin git@github.com:knowblesse/myrepo.git

형식에 주의하자

git@github.com:knowblesse/myrepo.git

Q. 여러 개의 SSH key를 사용할 경우에는 어떻게 하죠? 어떤 key를 쓰라고 지정할 수는 없나요?
A. ~/.ssh 폴더 안에 config 파일을 만들어서 어느 사이트에 연결할 때 어떤 key 파일을 사용할지 정해줄 수 있습니다. 이 방법 외의 다른 방법도 있지만, git command 안에서 "어떤 key 파일을 써라" 라고 명시적으로 알려주는 방식은 없는 것으로 알고 있습니다. config 파일을 생성하는 방법은 아래 접은 글을 참고해 주세요.

Host myhub
	HostName github.com

#keyfile 1
Host account1
         HostName github.com
         IdentityFile ~/.ssh/account1_private
#keyfile 2
Host account2
         HostName github.com
         IdentityFile ~/.ssh/account2_private

> git remote set-url origin git@account1:knowblesse/repo1.git

4. ssh-agent 셋업 및 연결 방법

    여기까지 설정을 완료했고, key 파일이 기본 위치인 ~/.ssh 안에 들어있다면 정상적으로 remote와 연결이 될 것이다. 그러나 매번 passphrase를 물어본다는 단점이 있다. 이를 해결하는 방법은 ssh-agent를 사용해서 잠시동안 passphrase를 저장해두는 것이다. 이 경우 한동안 passphrase 없이 SSH 통신을 할 수 있다. 마치 credential.helper 를 사용해서 token을 저장해두는 것과 동일하다.

순서는 두 과정을 거치는데, 1)ssh-agent를 실행하고, 2) ssh-add를 통한 key 등록이다.

Linux

> eval `ssh-agent -s`
Agent pid 12345
> ssh-add

Windows (PowerShell)

> Set-Service ssh-agent -StartupType Manual
> Start-Service ssh-agent
> ssh-add

Q. 왜 그냥 ssh-gent를 실행하면 안되고 꼭 eval 함수 사용해서 실행해야하죠?
A. eval을 쓰지 않고 ssh-agent 명령을 실행해도 ssh-agent 프로세스는 정상적으로 시작된다. 그런데 그 이후에 ssh-add가 정상작동하지 않는다. 그 이유는 ssh-add가 SSH 소켓에 대한 정보를 필요로 하기 때문이다.

ssh-agent 명령을 실행하면 다음과 같은 출력이 나온다.

> ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXmj93qJ/agent.36991;
export SSH_AUTH_SOCK;
SSH_AGENT_PID=36992;
export SSH_AGENT_PID;
pid 36992;

눈치 챘겠지만, ssh-agent 명령은 ssh-add 에게 매번 긴 SSH_AUTH_SOCK에 해당하는 값을 전달해주지 않도록 SSH 소켓과 ssh-agent 관련 정보를 bash 코드로 출력한다. 때문에 출력 텍스트를 그대로 코드처럼 실행시키는 eval 함수를 사용하여 ssh-agent를 실행하면, ssh-agent의 출력결과인 소켓과 pid 설정을 자동으로 할 수 있다!

때문에 굳이 eval을 쓰고 싶지 않다면, ssh-agent를 돌려서 나온 소켓과 pid 정보를 아래와 같이 변수로 입력해주면 된다.

> SSH_AUTH_SOCK=/tmp/ssh-XXXXXXmj93qJ/agent.36991
> SSH_AGENT_PID=36992
> ssh-add

Q. 왜 윈도우에서는 서비스 시작 방법을 바꾸나요?
A. Startup Type 이 Manual이 아니면 수동 시작이 안되는 것 같다. 윈도우는 UI가 잘 되어 있으니 수동시작을 하지말고 시작시 자동 시작을 하게 하면 더 편할 것 같다.

마치며

SSH 설정이 단순하지는 않지만, 한번 설정만 해두면 높은 보안수준을 유지하며 쉽게 데이터 공유가 가능하다.

이 시리즈를 포스팅하게 된 계기는 한달전부터 Ubuntu 를 사용을 시작한 것이다.

vim과 터미널 명령어들을 배우면서 슬슬 GUI보다 CUI에 익숙해지고 있어서 git도 이제 GUI 프로그램을 사용하지 않고 명령어를 외어서 사용하려는 중이다. 하지만 git에 입문하는 처음이라면 꼭 GUI 프로그램을 사용해라.하는 것을 추천한다.

대체 누가 git 입문 책에서 CUI로 알려주는지. git은 꼭 GUI로 시작해라.

처음에는 branch라는 개념이 직관적으로 다가오지 않으며, 여러 branch가 꼬이기 시작하면 머리도 같이 꼬일 수 있다. 

또한 아무리 CUI가 입력하기엔 편해도 visualize 하는 면에 있어서는 GUI를 이길 수 없다. 나는 CUI에 익숙해져도 GUI git을 지우지는 않을거라고 확신한다.

GUI로 git을 사용할 수 있게 해주는 프로그램은 그렇게 많지 않다. 

처음에는 GitHub에서 자체제작한 GitHub Desktop을 사용했는데 깔끔한 그래픽의 군더더기 없는 디자인이라 마음에 들었지만 git의 모든 기능을 구현하지 않은 것 같고, 전반적으로 UI가 휑한 느낌을 주었다.

단순한 기능들만 사용한다면 추천하기는 한다. 

이후로 본격적으로 git을 사용하게 만든 장본인은 Sourcetree이다. GitHub Desktop과는 다르게 다양한 기능들을 구현을 해두었고, 구현한 기능들에 비해 디자인도 깔끔하게 만들어서 한동안은 정말 잘 썼으나... 2016년즈음 자꾸 내부 프로그램 문제가 발생해서 설치-재설치, GitHub Desktop으로 갈아탔다 다시 오기를 몇 번.. 아주 지쳐버렸다. 

지금은 그래도 그때보다는 더 안정화 되어있을 것이다. 하지만 돌아갈 생각은 없다. 

시커먼 화면을 좋아해서 그런지 한번 적응하고 나서부터는 바꿀 생각을 전혀 안하고 있다. 

UI는 위의 두 프로그램의 딱 중간정도지만 복잡한 기능들도 다 구현이 되어있고 아직까지 한번도 크래시가 난적이 없다.

의외로 이 프로그램에 대한 소개가 별로 없는 것 같기에 프로그램에 대한 애정을 담아 이후 포스팅부터는 이 프로그램을 기준으로 설명하겠다. 

2017년 이후 거의 3년간 문제없이 쓰고 있는 것은 GitKraken이다. 

마무리

아마 직접 git을 설치하는 일은 없을 것이다. 혹시 리눅스 유저라면 이미 git이 기본으로 깔려있을 것이고, 윈도우 유저라면 바로 GUI 프로그램인 GitKraken을 깔자. 이 프로그램 역시 학생에게 무료로 Pro 버전을 제공한다. 

https://www.gitkraken.com/student-resources

이전 포스트에서 GitHub에 가입을 하고, 이번 포스트에서 GitKraken을 설치했다면 이제 준비는 끝이다. 

다음 포스트부터 바로 실제 git에 구조와 사용법에 대해서 작성하도록 하겠다. 

원래 두 번째 글은 왜 git 이 필요한지에 대해서 작성하려고 했으나 계획을 변경했다. 

첫째, 일단 난 왜 git이 필요한지 안다. 굳이 여기서 간증글을 쓸 시간은 없다.

둘째, 지금 이 글을 보는 사람이 git의 필요성을 모르고 들어왔을 거라고 생각하지 않는다. 

셋째, 행여 git의 필요성을 모르는 사람이 들어왔으면 아마 아직 짠 코드 양이 적어서 그럴 것이라고 추측한다. 
코딩을 더 하다가 오면 생각이 바뀌지 않을까.

그럼 바로 git과 GitHub의 관계부터 짚고 넘어가겠다.

git

git 은 버전관리(version-control) 프로그램이다.

버전 관리 프로그램은 말 그대로 파일의 "버전"을 관리해주는 프로그램이다. 

처음에 이 말을 들었을 때는 "뭔 버전? 워드 2013 뭐 이런 버전인가?" 했는데 다음 짤을 보고 한 번에 이해가 되었다. 

한컴오피스나 Word의 검토 기능을 자주 사용해본 사람이라면 다음 그림도 익숙한 화면일 것이다. 

버전 관리 프로그램의 주된 목적은

1. 첫 번째 사진과 같이 같은 파일을 여러 번 다양한 사람에 의해서 수정을 해야 하는 경우 각각의 파일들을 최신순으로 추적해 주며
2. 두 번째 사진과 같이 각 파일이 이전 버전들과 어떻게 달라졌는지를 비교해주는 것이다. 

git은 이러한 버전 관리 프로그램의 한 종류이다. 

뭐 대충 2000년대 전에 개발되었을 거고 2005년에 개발이 되었고, 개발자는 리눅스의 개발자 Linus Torvalds이며 현재는 일본인 개발자 Junio Hamano에 의해 유지되고 있다. 

버전 관리 프로그램의 종류는 git 외에도 수 십 종이 있으나 현재 적극적으로 사용되고 있는 것은 많지 않고 굳이 하나를 더 알아야겠다면 CVS랑 Subversion 정도. CVS, Subversion, git 모두 오픈소스에 누구나 쉽게 사용할 수 있지만, git은 모든 사용자가 데이터를 가지고 있지만 CVS와 Subversion은 중앙집중형 시스템이라는 점에서 다르다.

기업에 들어가면 자체 버전관리 시스템을 사용하게 될 것이고, 그 외에는 거의 대부분이 git을 사용하고 있다고 생각해도 무방하다. 

하지만 이러한 버전 관리를 포함하는 모든 데이터 관리의 핵심 기능이 하나 빠졌다. 

바로 백업과 공유이다. 

GitHub

GitHub는 git을 더욱 손쉽게 사용할 수 있도록 해주는 온라인 서비스이다.

GitHub는 git이 나온 지 3년 뒤에 론칭했다. git 프로그램이 이렇게 인기 있는 버전 관리 소프트웨어로 성장하도록 만든 중요 동력원 중 하나가 아닐까 하고 생각할 정도로 다양한 기능들을 제공하며 무엇보다 remote repository를 무료로 제공해준다. 

git은 앞서 설명했듯이 중앙집중형인 CVS와 다르기에 모든 데이터가 로컬 컴퓨터에 저장이 된다.(local repository) 때문에 만일 로컬 컴퓨터에 문제가 생기거나 데이터가 있는 폴더를 실수로 홀라당 날려먹으면 버전 관리고 뭐고 끝이 난다. 

git에서는 이러한 문제를 원격 저장소, remote repository라는 것을 사용해서 해결할 수 있는데, 말 그대로 로컬에 있는 데이터를 local이 아닌 다른 컴퓨터 (주로 클라우드 서버)에 저장하여서 데이터를 백업해둘 수 있다. 

하지만 이를 단순히 "백업"이라고 말하기에는 마음이 편하지 않다. 심지어 GitHub의 Help page에 들어가면 "Git is not adequately designed to serve as a backup tool."이라고 언급을 하고 있다. 물론 원격 저장소를 사용하면 로컬에 있는 데이터를 백업해두고, 로컬에 문제가 있을 때 다시 복구할 수 있지만, 다른 사용자와 코드를 공유하거나 완성된 프로그램을 배포하는 등 훨씬 다양한 기능을 수행할 수 있다.

굳이 백업이라는 단어를 써서 원격 저장소를 설명하자면, "소스코드에 특화된 강화된 기능을 가지는 공개용 백업"?

몇 가지 GitHub의 기능을 나열하면 아래와 같다.

• 원격 저장소 기능
• Issues : 버그 신고 혹은 기능 추가 요청. "이 기능 좀 넣어주세요~", "이거 안 되는데요?"
• Pull requests : 다른 사용자가 직접 코드를 수정해서 원격 저장소 오너에게 이 코드를 사용해달라고 제안하는 기능.
• Wiki : 원격 저장소에 있는 프로그램에 대한 위키 페이지 운영 기능.
• Releases : 배포용 프로그램 생성 기능.

이 모든 것을 무료로 제공 가능한 이유는 단순한 텍스트 파일인 소스코드의 크기가 크지 않기 때문이다. 

때문에 GitHub에 올리는 파일의 크기는 아래와 같은 제약을 받는다.

한마디로 소스코드 외에 다른 것들은 가능하면 올리지 말라는 것이다. 

예전에는 사전에 지정한 사람만 들어올 수 있는 비공개 원격 저장소를 무료 계정에서는 5개로 제한했었는데 이 제한은 없어진 모양이다. 월 USD7을 내면 Pro 계정으로 업그레이드가 가능한데 이마저도 학생들에게는 무료로 제공하고 있다. 

아래 링크를 참고할 것.

https://education.github.com/pack

물론 Github가 git을 위한 유일한 원격 저장소 서비스 제공자는 아니다.

GitLab, Bitbucket 등 다양한 업체가 있으나 둘러본 적은 없다.

따라서 앞으로의 글도 GitHub에 초점을 맞춰서 작성할 예정이다. 

잘못된 정보는 댓글로 지적해주시면 정말 감사하겠습니다!

어디까지나 프로그래밍은 취미이다.

라고 스스로에게 계속 되뇌고 있지만 이제는 슬슬 인정할 때가 되지 않았나 싶다. 

내게 있어서 프로그래밍은 이미 생활의 일부라고.

각설하고 연구를 위해서도 그렇고, 진정한 취미 프로젝트를 위해서도 그렇고 버전 관리는 필수다. 

심지어 이제 막 프로그래밍을 배우기 시작하는 사람도 git 사용법을 같이 배워야 한다고 생각한다.

과학에서 연구를 할 때 실험을 배우기 전에 연구노트 작성법에 대해서 알려주듯이 프로그래밍을 하는 사람들도 코딩을 제대로 배우기 전에 git 사용법에 대해서 알아야 한다. 원하든 원하지 않든 한번 짠 프로그램은 가능한 기록을 해두는 것이 좋고, 이 기록을 체계적으로 남기기 위해서는 Github 만한 플랫폼이 없다. 객체 지향이나 multi threading 같은걸 알려주기 전에 학습하면서 짜둔 코드를 효율적으로 기록하는 법을 알려주는 게 옳지 않을까. 

또한 프로그래밍 초반이야 말로 다른 사람의 코드를 자주 보게 되는데 "그거 내 깃헙에 올려뒀어요~" 라던가 Github 뭐시기 링크만 달랑 첨부되어 있는 경우 코드를 어떻게 받아야 할지도 모르기 때문이다. 내가 비전공자라 그런지 나름 주변에서 프로그래밍을 배웠거나, 지금도 코딩을 하고 있는 사람들에게 코드 전달 목적으로 깃헙을 알려주면 답답한 일들이 자주 발생한다. 거의 대부분은 내가 업데이트를 할 때마다 전체 파일을 zip으로 다운로드하여서 필요한 코드를 골라가기만 하고 제대로 사용할 줄을 모른다. 최소한 raw 버튼의 사용법만 알아도 바로 필요한 코드만 긁어갈 수 있을 텐데.

나도 한동안 git을 쓰지 않았다. Cloud에 코드를 죄다 올려두고 자체 backup 기능이나 파일 버전 관리 기능을 사용해서 오랫동안 작업을 했었다. 그러다가 조금 내용이 많이 바뀐 것 같으면 프로젝트 파일을 통째로 새로 저장하고, 다른 목적을 위해서 프로그램을 수정하게 되어도 또 새로 저장하고... 그러한 결과 아래와 같은 일이 벌어진다.

전부 같은 "출석 부르기" 프로그램인데 사용목적과 내용에 따라서, 그리고 개발 상태에 따라서 폴더를 새로 만드니 뭐가 뭔지 알 수 없게 되었고, 각각 업데이트한 내용이 달라서 서로 호환도 안된다. 

정말로 코드 짜는 건 20% 밖에 안되고, 의외로 유지보수가 80%나 된다. 주석 잘 달아두자.

CUI가 익숙하지 않아서 이것저것 알아보다가 Sourcetree를 계기로 git에 입문했다. 

대략 다섯 권의 git 혹은 Github 관련 책을 읽었으나 생각보다 내용이 중구난방으로 작성되어 있었고 알파벳순으로 정렬된 매뉴얼처럼 정신없었다. 그래도 꾸역꾸역 읽어서 이제는 별문제 없이 사용하지만, conflict error가 나거나 이전 commit으로 돌릴 때, Github 특화된 기능을 사용할 때는 머리가 터질 뿐이다. 

'아씨 내가 차라리 책 한 권을 쓰면서 배우는 게 빠르겠다!'라는 생각에 이 글을 시작한다. 

우선순위를 고려한 목적은 아래와 같다. 

1. 내가 git의 모든 커멘드에 익숙해질 수 있도록.

2. 이후에 사용법이 궁금할 때 이 글들을 보고 refresh 할 수 있도록. 

3. git 혹은 github 관련 궁금증이 있을 때 제일 먼저 이 블로그로 사람들이 찾아오도록 하기 위해.

시간을 최대한 내서 끝까지 포스팅 할 예정이다. 

PS 출판을 원하시면 언제든 연락주세요