문제 상황
현재 프로젝트를 윈도우와 리눅스 컨테이너 양쪽에서 작업을 진행하던 중, github 토큰을 등록을 하게 되었다. 깃허브 홈페이지에서 성공적으로 토큰을 발급받고, 이를 활용하여 비밀번호를 입력한 후 성공적으로 push를 할 수 있게 되었다. 문제는 이후의 push 에서도 계속해서 비밀번호를 요구한다는 점이였다. 환경이 조금 특이해서 (도커 컨테이너 ubuntu, wsl) 다양한 방법을 시도해봤는데, 시간을 예상보다 많이 쏟게 되어 기록을 위해 글을 작성한다.
Linux 환경
방법 0
git config --global credential.helper store
보안적으로 추천하지 않는 방법이다. git이 설치된 위치에서 git-core를 들어가면, git-credential-store라는 파일이 있는데, 거기에 토큰을 기록하는 방식이다. 사실 가장 편하긴 한데, 역시 보안적으로 취약하다는 점에서 권장되는 방식은 아니다.
방법 1
sudo apt-get install libsecret-1-0 libsecret-1-dev
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret
원리는 libsecret이라는 패키지를 설치하여, 해당 패키지에 token을 저장하고 token이 필요한 경우 github는 명시한 credential.helper인 libsecret을 참고하여 인증을 수행한다.
여기까지해서 문제가 없으면 다행인데, 현재 docker 컨테이너 환경에서 작업을 진행하던 중 다음의 에러를 만날 수 있었다.
** (process:23898): CRITICAL **: 12:21:26.791: store failed: Cannot autolaunch D-Bus without X11 $DISPLAY
그래서 위의 방법이 안된다면 다른 방법을 시도해봐야 한다.
방법 2
그래서 어떻게 해결할 것이냐. git-credential-manger를 통해 토큰을 관리할 것이다.
가장 먼저 다음의 명령어로 수행이 가능하다면, 쉽게 갈 수 있다. git-credential-manager가 이미 설치된 경우이다.
git config --global credential.helper manager-core
근데, 내 컨테이너 환경에는 무슨 일이 일어났던 건지, 정상적인 git 경로에 credential-manager가 존재하지 않았다.
/usr/lib/git-core# ls git-credential*
git-credential git-credential-cache git-credential-cache--daemon git-credential-store
그래서 직접 설치해주었다.
먼저 방법 1을 수행하지 않았다면 필요한 패키지를 설치해준다.
sudo apt-get install libsecret-1-dev
다음으로 credential-manager의 패키지 파일을 다운로드하고
(여기가 조금 오래 걸린다. 서버가 빠르지 않다... 최신 버전의 릴리즈는 더 느리다...)
wget https://github.com/microsoft/Git-Credential-Manager-Core/releases/download/v2.0.498/gcmcore-linux_amd64.2.0.498.54650.deb
패키지를 설치해준다.
sudo dpkg -i gcmcore-linux_amd64.2.0.498.54650.deb
여기까지 왔다면 설치는 완료되었고, 잘 설치되었나 확인 한번 해주자.
git credential-manager version
마지막으로 git에 설치한 credential-manager를 사용한다고 등록해주면 끝난다.
git config --global credential.helper manager-core
이후 push 수행 시 문제 없이 업로드가 가능해진다.
wsl, debian
방법 0
git config --global credential.helper store
보안적으로 취약하기에 권장되는 방식은 아니다. (위의 linux 부분을 참고)
방법 1
앞의 방법으로 credential.helper를 활용하면, 다음과 같은 에러 메세지를 만날 수 있다.
could not connect to Secret Service: Cannot autolaunch D-Bus without X11 $DISPLAY
위의 credential-manager를 설치해서 해결을 할 수도 있지만, 좀 더 쉬운 방법이 있다.
바로 윈도우 쪽에 설치된 git에서 자체적으로 제공하는 credential-manager의 경로를 직접 먹여주는 것이다.
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe"
문제가 없다면 해당 명령 수행 이후 정상적으로 push가 추가적인 비밀번호 없이도 가능해진다.
만약 잘 안된다면 해당 경로에 git-credential-wincred.exe가 실제로 있는지 확인하고, 만약 없다면 직접 설치 이후, 설치된 위치의 credential-manager를 활용하는 방식으로 해결이 가능할 것 같다.
'etc > errors' 카테고리의 다른 글
| 스크립트를 통한 ssh 접속 (0) | 2023.04.07 |
|---|---|
| SSH를 통한 Root 로그인 불가 시 해결 방법 (0) | 2023.04.07 |
| Git 충돌날 때 사용가능한 간단한 대처방법 (0) | 2023.03.26 |
| [VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)." (0) | 2022.11.22 |
ssh를 접속하는 가장 기본적인 방법은 bash의 ssh 명령어를 사용하는 것이다.
기본적인 사용방법은 다음과 같이 직관적이다.
ssh <ip-address>다만, 앞선 명령어는 현재 로컬 머신의 ip 주소를 그대로 가지고 서버에 접속을 시도하기 때문에, 해당 의도가 아닌 경우라면 비밀번호와 유저가 일치하지 않아 로그인이 안되는 문제가 있다.
ssh <username>@<ip-address>때문에 주로 위의 명령어처럼 유저를 명시하고 사용을 권장하곤 한다.
이는 argument로도 전달이 가능한데, 바로 -l 옵션을 통해서이다.
ssh -l <username> <ip-address>
여기까지가 기본적인 명령어 사용방법이였다.
ssh 명령어가 있으니 이를 활용하여 ssh 접속을 스크립트 실행을 통해 간소화해보고 싶었다.
문제는 비밀번호를 넣는 부분인데, ssh 명령어를 통해서는 비밀번호를 스크립트로 넣을 수가 없었다.
-p 옵션이 있기 때문에, 될 것 같은 느낌도 들지만 해당 옵션은 포트를 명시하는 옵션이다.
때문에, 비밀번호를 가지고 ssh 접속을 하기 위해서는 sshpass 라는 패키지를 설치해줘야 한다.
# Ubuntu or Debian
sudo apt-get install sshpass
# macOS
brew install http://git.io/sshpass.rb이후 다음 명령어를 통해 비밀번호를 스크립트 안에 밀어넣을 수 있다.
sshpass -p <password> ssh -l <username> <ip-address>
ssh가 보안 상의 이유로 비밀번호를 노출시키지 못하도록 한 것을 sshpass가 끄집어냈다는 느낌이 든다. 사실 근데 대부분의 상황에서 편리하자고 sshpass를 쓰는게 맞을까 하는 의문은 든다. 혹여나 스크립트가 노출이 되어버리면 곧바로 컴퓨터에 대한 모든 권한을 넘겨주는 것이기에, sshpass는 최대한 지양하는 것이 맞을 것 같다.
그럼에도 ssh를 자동으로 접속해야만 하는 불가피한 상황이 있을 수 있으니 해당 상황에서는 꼭 방화벽을 철처하게 설정해줘야 하지 싶다.
'etc > errors' 카테고리의 다른 글
| git push시 계속해서 인증을 요구하는 경우 (0) | 2023.04.09 |
|---|---|
| SSH를 통한 Root 로그인 불가 시 해결 방법 (0) | 2023.04.07 |
| Git 충돌날 때 사용가능한 간단한 대처방법 (0) | 2023.03.26 |
| [VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)." (0) | 2022.11.22 |
접속하고자 하는 Server 터미널에서
sshd_config 파일을 열고
sudo nano /etc/ssh/sshd_config
해당 부분을 Yes로 바꿔준다.
PermitRootLogin Yes
이후 sshd 재시작 해주며 변경 사항 적용해주면 끝.
sudo systemctl restart sshd
(써놨으니 안까먹겠지...)
'etc > errors' 카테고리의 다른 글
| git push시 계속해서 인증을 요구하는 경우 (0) | 2023.04.09 |
|---|---|
| 스크립트를 통한 ssh 접속 (0) | 2023.04.07 |
| Git 충돌날 때 사용가능한 간단한 대처방법 (0) | 2023.03.26 |
| [VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)." (0) | 2022.11.22 |
문제 상황
Local Repository (master)
- A.cpp
- B.cpp
- AA.H
Remote Repository (main)
- README.md
Remote Repository (master)
- A.cpp
- B.cpp
- AA.H상당히 이상한 예시지만, 실제로 위와 같은 상황에 대처해보는 방법을 전부터 작성해보고 싶어 이번 기회에 작성하고자 한다.
기존에는 그냥 간단하게 새로 clone 받아서 복구하는 형태로 충돌을 대처했다면, 만약 clone 외에 어떠한 방식으로 충돌을 해결할 수 있을 지를 남기고자 한다.
먼저, 문제 상황을 살펴보면 로컬/리모트 두 저장소가 서로 합쳐질 수 있는 듯 보이지만, master라는 어디선가 생겨버린 브랜치와 main 브랜치는 현재 아무런 접점이 없어, 히스토리를 서로 추적할 수 없는 상황이다.
그래서 우선적으로 local에 main 브랜치를 생성해주고 이동해주었다.
git branch main
git checkout main이후 동일하게 add, commit, push 를 진행해주었다.
git add .
git commit -m "my commit message"그럼에도 여전히 push 명령어는 오류를 발생시켰다.
git push origin main
To https://github.com/mukmookk/repo.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/mukmookk/repo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.여전히 현재 로컬의 main 브랜치와 리모트 main 브랜치 간의 충돌이 발생함을 확인할 수 있다.
이는 로컬의 파일들과 리모트에 위치한 README.md 간의 히스토리가 일치하지 않기 때문일 것이다.
때문에 명령어의 힌트에 나온 것처럼 pull 명령어를 시도해보았다.
git pull origin main
From https://github.com/mukmookk/repo
* branch main -> FETCH_HEAD
fatal: refusing to merge unrelated histories그러나 별도의 옵션이 존재하지 않는 pull 명령어는 여전히 오류를 발생시켰고, 이는 push가 실패한 이유와 크게 다르지 않은 것으로 추정된다.
해결
다만, 히스토리가 다르더라도 병합될 브랜치 파일들 간에 간섭이 없는 위의 상황이라면 pull의 --allow-unrelated-histories 옵션이 해결책일 수 있다.
git pull origin main --allow-unrelated-histories
From https://github.com/mukmookk/repo
* branch main -> FETCH_HEAD
Merge made by the 'ort' strategy.
README.md | 1 +
1 file changed, 1 insertion(+)
create mode 100644 README.md위의 명령어는 서로 관련없는 히스토리를 가졌다고 해도, 두 브랜치 간의 머지를 허용해주는 옵션이다. 때문에 앞서 제시된 문제상황과 같은 경우에 해당 명령어를 작성해주면 다음과 같이 로컬 저장소에 머지가 된다.
Local Repository (master)
- A.cpp
- B.cpp
- AA.H
- README.md이를 다시 push 해주면 당초 목표했던 push가 가능해진다.
git push origin main
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 366 bytes | 366.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/mukmookk/repovvvvvvvv.git
7923c39..545efbd main -> main'etc > errors' 카테고리의 다른 글
| git push시 계속해서 인증을 요구하는 경우 (0) | 2023.04.09 |
|---|---|
| 스크립트를 통한 ssh 접속 (0) | 2023.04.07 |
| SSH를 통한 Root 로그인 불가 시 해결 방법 (0) | 2023.04.07 |
| [VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)." (0) | 2022.11.22 |
[VirtualBox, Window] 호스트 전용 네트워크 설정 오류 "Querying NetCfgInstanceId failed (0x00000002)."
문제 상황
Virtual Box를 통해 호스트 전용 네트워크를 설정하고자 함. 만들기 버튼을 눌렀더니, creating host only network interface not working 라는 메세지가 꽤나 오랜시간 뜨더니 생성이 실패함.
버전을 변경해가며 재설치를 진행했고, 혹시나 제거가 완벽하게 되지 않아서 생긴 문제인가 싶어서 로그 파일까지 다 지웠음에도 문제가 해결되지 않았음.
로그: creating host only network interface not working
문제 해결
Summary: 이더넷 네트워크 설정에서 VirtualBox NDIS6 Bridged Networking Driver를 제거.
Step 1: 현재 실행 중인 Virtual Box를 종료
...
Step 2: 기존에 사용하던 Virtual Box를 제거
Step 3: 설정 > 네트워크 및 인터넷 > 어뎁터 옵션 변경 으로 이동
Step 4: 마우스 우클릭 후 속성으로 진입, VirtualBox NDIS6 Bridged Networking Driver를 제거
(Virtual Box가 제거되지 않은 경우 해당 항목의 삭제가 정상적으로 되지 않음)
Step 5: Virtual Box 재설치
원하는 버전으로 재설치
Step 6: 별도의 작업 없이도 VirtualBox Host-Only Ethernet Adaptor가 정상적으로 추가되었다면 성공
Virtual Box 내부에서도 확인 가능
'etc > errors' 카테고리의 다른 글
| git push시 계속해서 인증을 요구하는 경우 (0) | 2023.04.09 |
|---|---|
| 스크립트를 통한 ssh 접속 (0) | 2023.04.07 |
| SSH를 통한 Root 로그인 불가 시 해결 방법 (0) | 2023.04.07 |
| Git 충돌날 때 사용가능한 간단한 대처방법 (0) | 2023.03.26 |