VSCode + WSL2 + Remote Development 사용시 permissions for keyfile are too open 문제 해결

문제 발생

원래 WSL1(Ubuntu)을 셋팅하여 사용 중이었다. VScode에 Remote Development 확장을 설치하고 ssh 접속시 public key를 가지고 패스워드 입력없이 접속하는 기능을 잘 사용하고 있었다. 그런데, 어느날 WSL2로 업데이트를 한 이후 이 기능이 갑자기 안되는 것이다!

아래 두 가지의 문제가 곧바로 발생했는데,
1. VScode에서 원래 사용하던 SSH Configuration file을 인식 못함
2. public key를 읽어오면서 permissions for KEYFILE are too open 이라고 나옴
(여기에서 KEYFILE부분은 환경마다 다름)

TL;DR

결론만 빠르게 알고 싶은 분을 위해,
우선 나와 완전히 똑같은 상황인지를 꼭 확인하길 바라며,

중요한 것은 이것이었다.

1. VScode는 Windows에 설치된 프로그램이고, 내가 사용하려던 SSH Configuration 파일과 public key는 WSL에 있는 파일이다. 그리고 Windows용 프로그램에서 WSL2에 있는 파일을 접근할 때는 UNC path를 사용한다.
2. VScode의 Remote SSH 확장이 사용하는 것은 Windows에 설치된 OpenSSH다. WSL에 설치된 것이 아니다!

이 두 가지가 핵심이다.

첫번째 문제 해결

자, 이제 길게 설명해보려고 한다. 참으로 불필요했던 삽질 기록이다.

위에 적었듯이, VScode는 Windows에 설치되어 있다.
그리고 나는 SSH용 public key를 WSL에서 만들었다.
심지어 Remote Development 확장에서 사용할 Configuration 파일도 WSL에서 작성해버렸다.
어째서인지 WSL1에서는 이렇게 사용할 때 문제가 없었던 것 같다. (어쩌면 내가 뭔가를 조치해놓고 적어두지 않았을 수도 있다.)
그러나 WSL2에 위치한 이 파일들을 Windows용 프로그램에서 읽어올 때 경로는 아래처럼 UNC(Universal Naming Convention) Path가 적용된다.
Ubuntu-18.04와 같이 배포명이 포함된 부분은 어디까지나 예시로, 이하에서는 부연하지 않겠음

\\wsl.localhost\Ubuntu-18.04\home\username\

그런데, VSCode는 특정 버전이상부터 UNC Path에서 파일을 읽어오는 부분을 block했다고 한다. 그래서 설정에서 UNC path를 읽어올 수 있게 변경해줘야 한다.

 "security.allowedUNCHosts": [
    "wsl.localhost"
  ]

그리고 Remote SSH가 참조하는 Configuration의 경로에도 아래처럼 수정해준다.

"remote.SSH.configFile": "\\\\wsl.localhost\\Ubuntu-18.04\\home\\username\\.ssh\\your_config_filename",

이렇게해서 1번 문제가 해결되었다.

두번째 문제 해결

이것도, VSCode의 Remote SSH 확장이 Windows에 설치된 OpenSSH를 사용하는 것임을 알고나면, 금새 해결될 문제였다. 나는 이 부분을 전혀 생각도 못하다가 관련된 이슈를 검색하던 중, "Powershell에서는 접속이 잘 되니?"라고 물어보는 글을 보고나서 알게 되었다.

그래서 Windows의 OpenSSH가 참조하는 public key가 들어있는 디렉토리는 결국 아래 경로였다는 것을 알게 되었고, 이 디렉토리로 WSL에 있던 public key를 옮겨왔다.

C:\Users\username\.ssh

그리고 1번에서 작성한 Configuration 파일 안에 IdentityFile 부분에도 이 경로로 수정해주면 된다.

IdentityFile C:\Users\username\.ssh\id_rsa

2번 문제도 이렇게 간단히 해결되었다!

결론

WSL과 Windows 간의 경로에 대해서 잘 이해하고 있으면 발생하지 않을 문제였음을, 그리고 여기에서도 다른 모든 문제들과 마찬가지로, output 로그를 처음부터 잘 살펴봤다면 더 빨리 해결할 문제였다는 것을 다시 한번 되새기며 글을 마친다.