인기포스트 MORE POST

    -

ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • SSH로 원격 서버 안전하게 접속 관리하기
    Programming/TIL 2024. 9. 4. 17:22

    기본적인 ssh 연결 방법부터 보안을 강화하는 방법까지 실제 홈서버를 만들면서 알아본 내용을 초보자 관점에서 설명합니다.
    비밀번호 인증 대신 ssh 키 인증을 사용해야 하는 이유와 설정 방법, sshd_config 파일을 통한 보안 설정 등 인터넷상으로 ssh 연결이 가능하게끔 설정할 때 필요한 내용을 포함합니다.
    그리고 Tailscale VPN을 이용한 ssh 연결 방법을 소개합니다.

    Intro

    요즘 짬짬이 노노그램 퍼즐 서버를 개발 중입니다. 간단한 REST api 서버입니다.

    서버는 예전에 쓰던 노트북을 서버 PC로 운용할 예정입니다. 힌지가 박살 나서 제대로 여닫는 데 10분 이상 걸리는 노트북입니다. 작동은 되니까 전원 물려놓고 서버용으로 방구석에 모셔놓기에는 안성맞춤이지요.

    한편, 고장 난 노트북 앞에서 작업하는 건 꽤 불편합니다. 그래서 평소 사용하는 노트북에서 ssh 연결을 해 서버 관리를 원격으로 하기로 했습니다. 번거롭게 노트북을 바꿔가며 작업할 일도 없어지고, 작업 공간 자유도도 높아지겠죠.

    특히 제가 카공족이다 보니, 카페와 같은 외부 환경에서 서버에 연결 가능하다는 점도 큰 장점이고요.

    이 글은 그렇게 ssh 연결을 처음 해보며 공부한 내용과 진행 사항들을 정리한 글입니다.

    ssh 연결 방법, 주요 설정과 보안 유의점, 그리고 Tailscale VPN을 이용한 ssh 연결 방법을 다룹니다.

    배경 및 주의 사항

    ssh 연결 시 보안의 중요성을 강조하는 글이 정말 많습니다. 그런데 초보자가 참고할 만한 쉬운 가이드는 좀처럼 찾기 힘들었습니다.

    쉬운 건 너무 간단하고, 어려운 건 너무 어려웠습니다. 당연한 삶의 이치에 대고 투덜대는 기분도 들지만, 보안이 달려 있으니 확실하게 하고 싶었습니다. 외부에서도 연결이 가능한 서버를 운영하는 게 목표였으니까요.

    해킹당하지 않으려면 어떤 조처를 해야 하는지 확실하게 알아보면서도, 간단한 개인 프로젝트니까 효과에 비해 너무 복잡한 조치는 생략하고 싶었습니다.

    "이 정도면 하면, 일단 나쁘지 않다"라는 식의 초보자 가이드가 필요했습니다.

    그런 글이 많지 않기 때문에, 제가 찾아보고 설정한 내용이 누군가에게 도움이 될 거로 생각해 따로 글로 남깁니다.

    아래 조치만으로 보안을 보장할 수 없으며, 잘못된 내용을 포함하고 있을 수 있음에 주의해 주세요. 특히 네모퍼즐보다 더 중요한 프로그램이나 개인정보를 다루는 분이라면요.

    저는 아래 내용과 관련해 전문가가 아닙니다. 잘못되거나 우려되는 점, 추가했으면 좋은 내용이 있다면 댓글로 남겨주세요. 수정/추가하겠습니다.

    글 전반에 걸쳐 Digital Ocean의 SSH Essentials Guide가 많은 도움이 되었습니다. 영어가 편하시다면 이 글을 주로 참고하셔도 좋겠습니다.

    환경

    • 클라이언트 PC: Ubuntu 22.04.3 LTS on WSL2 Windows 11
    • 서버 PC: Ubuntu 22.04.1 LTS

    SSH 연결 방법 기초

    서버 PC에서 openssh-server를 받고 실행해 줍니다.

    sudo apt install openssh-server
sudo systemctl start ssh
sudo systemctl enable ssh

    systemctl 는 systemd를 통해 실행되는 백그라운드 서비스를 관리하는 명령어입니다.
    start ssh는 ssh 서비스를 시작하는 명령, enable ssh는 서버 PC 부팅 시 자동으로 ssh 서비스를 실행하도록 하는 명령입니다.

    ssh 연결은 22번 포트를 기본 포트로 사용합니다.
    22번 포트를 방화벽에서 열어 주겠습니다. Ubuntu의 ufw를 사용했습니다.

    sudo ufw enable
sudo ufw allow 22

    일단 지금 단계에서는 모든 ssh연결을 내부망으로 진행하겠습니다. 서버 PC와 클라이언트 PC가 같은 네트워크(같은 와이파이)에 연결되어 있어야 합니다.

    서버 PC의 내부 IP(=사설 IP) 주소를 확인해 줍니다.

    ip addr

    서버 PC의 네트워크 인터페이스를 확인합니다. 적혀있는 사설 IP와 MAC 주소를 기억해 주세요.

    3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> 
    link/ether <YOUR MAC ADDR> 
    inet <YOUR PRIVATE IP ADDR>

    이제 클라이언트 PC에서 ssh 원격 연결이 가능합니다. ssh <username>@<address> 형식입니다.

    ssh brokenhinge@172.30.1.100

    집 안에서 서버 PC에 ssh 연결이 가능해 졌습니다만, 아직 집 밖에서 인터넷을 통한 서버 접속은 불가능합니다.

    포트포워딩 설정을 해주지 않았기 때문입니다.

    포트포워딩이란

    포트포워딩이란, 공인 IP(공유기의 IP)/포트번호와 사설 IP(서버 PC의 내부 IP)/포트번호를 연결하는 설정입니다.

    제 공유기 공인 IP, 인터넷상 IP가 216.58.217.14라고 가정하겠습니다.

    공유기에는 스마트폰, 서버 PC, 스마트 냉장고 등이 연결되어 있습니다.
    각 기기는 공유기로부터 사설 IP를 할당받아 사용하고 있습니다. 서버 PC의 사설 IP는 172.30.1.100이라고 합시다.

    이때 지구 반대편에 사는 A 씨가 서버에 ssh 연결을 하는 상황을 가정해 봅시다.

    A 씨는 먼저 216.58.217.14 IP 22번 포트로 접속을 시도합니다.

    공유기는 당황합니다.

    현재 3개 기기가 연결 되어있는데, 어떤 기기 22번 포트에 연결해야 할지 모르기 때문입니다.
    고민하느니 그냥 연결을 거부하기로 합니다.

    이후 A 씨는 172.30.1.100 IP 22번 포트로 접속을 시도합니다.

    공유기는 당황합니다. 이번에는 서버 PC가 연결된 공유기가 아닌 A 씨의 공유기가 당황합니다.

    172.30.1.100은 사설 IP입니다. A 씨의 공유기는 자신과 연결된 기기의 사설 IP 중에서 172.30.1.100를 찾습니다. 인터넷을 통해 요청이 전송되지도 않습니다.

    A 씨가 접속하려면 포트포워딩이 필요합니다.

    216.58.217.14 IP의 22번 포트와 서버 사설 IP 172.30.1.100의 22번 포트를 연결합니다.

    A 씨가 요청을 보내도 이제 공유기는 당황하지 않습니다.

    22번 포트로 들어온 요청은 내부 네트워크에 연결된 172.30.1.100의 22번 포트로 전달되어 서버 PC에 도착합니다.

    DHCP와 내부 IP 고정

    여러 공유기는 DHCP를 통해 네트워크 기기에 내부 IP를 동적으로 할당해 줍니다.

    즉 제 노트북에 할당된 사설 IP 172.30.1.100가 어느 날 172.30.1.99로 바뀔 수 있다는 말입니다.

    저희 집 공유기는 연결된 기기 수가 적고 변동도 거의 없어서 바뀔 일이 많지는 않겠지만, 혹시 모르니 공유기 설정 페이지에서 수동 IP 할당 설정을 해주었습니다.

    설정 방법은 공유기 제조사 별로 다릅니다.
    KT 및 Iptime 공유기는 KT/Iptime 공유기 사설 IP 고정 설정 이 글을 참고하시면 좋겠습니다.

    SSH 보안 강화하기

    포트포워딩 설정하기 전 SSH 연결 보안을 꼭 염두에 두어야 합니다.

    포트포워딩을 통해 제가 집 밖 카페에서 원격으로 서버를 관리하는 만큼, 사악한 해커도 똑같이 인터넷을 통해 서버에 접근할 수 있습니다.

    해커가 ssh 접속에 성공하면 컴퓨터를 도둑맞은 것과 진배없습니다. 터미널에서 뭐든 열람 할 수 있고, 어떤 명령어든 실행할 수 있습니다.

    서버 PC는 오늘 막 OS를 설치한지라 가져갈 만한 파일이 있지는 않습니다. 해커가 네모퍼즐 DB를 좋아할지도 모르겠고요. 하지만 그렇다고 해서 무시할 수는 없습니다.

    ssh를 통해 비트코인 채굴기나 디도스 봇, 백도어 등이 설치 될 수도 있으니까요.

    따라서 추가 보안 조치를 취해 줍시다.

    SSH Key를 사용한 로그인

    제일 정말 가장 중요한 조치입니다.

    다른 건 몰라도 이것만은 꼭 해주셔야 합니다.

    SSH Key vs 패스워드 로그인

    ssh 연결을 다시 해보겠습니다. 원격 연결 유저의 패스워드를 묻고 있습니다.

    ssh brokenhinge@172.30.1.100
> brokenhinge@172.30.1.100's password:

    제 패스워드는 1q2w3e4r 입니다. OWASP SecList Top 10000 Passwords 최고의 패스워드 랭킹 235위에 랭크한 패스워드입니다. 누군가 리스트에 있는 패스워드를 하나씩 시도해 본다면, 235번째에 제 서버에 접속할 수 있겠죠.

    물론 그러기 위해선 제 공인 IP 주소와 포트 번호, 유저네임을 알아야 합니다.

    한편 IP 주소 형식은 뻔하고, ssh 기본 포트 번호는 22번입니다. 여기에 해커들은 365일 24시간 자동으로 모든 IP ssh 포트에 비밀번호 무차별 대입 공격을 시도합니다. 상대는 전 세계 모든 해커입니다. 인터넷 접속이 가능하면 어디서나 접속 시도를 할 수 있으니까요.

    사실 1q2w3e4r은 제 패스워드가 아닙니다. 설명을 위해 가상의 패스워드를 한번 상상해 만들어보았습니다. 원래는 더 길고 복잡한 패스워드를 사용하고 있죠.

    카스퍼스키 패스워드 체커 에서 제 진짜 패스워드를 넣어 확인해 보았습니다.

    Oops! Your password could be cracked faster than you can say "Oops!"

    타이머를 키고 "웁스"라고 말해봤습니다. 0.87초가 걸리는군요.

    Wjdayghfks1627&Qudwkghfks1636 이라는 비밀번호를 만들었습니다. 무차별 대입으로 뚫으려면 10000 세기가 걸린다고 합니다. 하지만 길고 안전한 비밀번호를 사용한다고 끝이 아닙니다.

    키보드 입력을 가로채는 키로깅이나 가짜 ssh 서버를 이용한 피싱 공격도 있습니다. 긴 비밀번호도 이런 경우 쉽게 노출될 수 있습니다.

    따라서 비밀번호 대신 ssh key를 사용하는 게 좋습니다.

    ssh key를 이용한 인증 방식에서 사용자는 공개 키와 개인 키로 이루어진 키 쌍을 생성합니다.

    이때 공개 키는 원격 서버에, 개인 키는 사용자 로컬시스템에 저장합니다.

    ssh 연결을 수립할 때 서버는 공개 키를 사용해서 오직 개인 키로만 해결할 수 있는 인증을 요구합니다.

    클라이언트는 개인 키를 이용해 인증을 수행합니다. 인증을 완료했음을 증명하는 서명을 생성해 서버에 전달합니다.

    여기서 개인 키를 서버에 전달하는 게 아닌, 인증 서명을 전달한다는 점이 중요합니다.

    패스워드와 달리 개인 키는 네트워크상으로 전달되지 않습니다. 중간에 탈취될 가능성이 없습니다.

    인증 서명을 받은 서버는 공개 키를 이용해 서명을 검증합니다. 검증이 성공하면 인증이 완료되고 ssh 연결이 수립됩니다.

    해커가 개인 키 대신 인증 서명을 탈취해도 문제가 없습니다. 서명은 일회성이기 때문에 재사용이 불가능하기 때문이죠.

    서버에 공개 키를 저장한 사용자만 인증 가능하기에 접근 권한 관리도 용이합니다. 일반적인 비밀번호보다 길이가 길고 복잡해서 무차별 대입 공격 저항성도 매우 높습니다.

    그 외 자세한 내용은 is ssh key more secure than password 이 글을 참고하셔도 좋겠습니다.

    저희는 ssh 접근 시 키를 통한 접속만 허용하고 패스워드를 통한 접근은 아예 막아두도록 하겠습니다.

    SSH KEY 생성

    클라이언트 PC에서 ssh 키를 생성해 봅시다. 

    ssh-keygen -t <keygen-algorithm> -C <comment>

    <keygen-algorithm>으로는 Ed25519를 쓰겠습니다.
    많이 쓰는 RSA 알고리즘보다 짧으면서도 더 안전한 알고리즘이라고 합니다.

    생성 시 순서대로 아래 값들을 물어봅니다.

    • 키를 저장할 장소: 기본값은 홈의 .ssh 디렉터리가 됩니다.
    • 암호(Passphrase): 기본값은 암호 없음 입니다.

    엔터키를 누르면 기본값이 적용됩니다.
    다만 ssh key passphrase는 꼭 설정하기를 추천합니다.

    생성이 완료되면 지정한 위치에 개인 키 id_ed25519 파일과 공개 키 id_ed25519.pub 파일이 생성된 걸 볼 수 있습니다.
    개인 키 파일은 절대 공유해서는 안 되며 잘 관리해야 합니다.
    공개 키 파일은 인증 서버에 공유하는 파일입니다.

    이제 공개 키를 원격 서버에 복사 해줍시다.
    클라이언트 PC에서 다음을 실행해 주면 ssh 연결을 통해 서버 PC에 공개 키 전달이 가능합니다.

    ssh-copy-id brokenhinge@127.30.1.100

    ssh 연결을 통해 서버 PC에 공개 키를 전달할 수 없다면 ~/.ssh/authorized_keys 에 공개 키 내용을 그대로 복붙/따라 치기를 해 주셔도 됩니다.

    .ssh/id_ed25519 already exists. Overwrite ?

    이미 생성된 키가 있다면 새로 키를 덮어쓸지 물어보는 메시지가 나옵니다.
    당연할 수 있지만 덮어쓰게 되면 기존에 만든 키로는 인증이 불가능합니다.

    저는 Github account와 연결 인증을 ssh키를 통해서 하고 있었습니다. 발급한 지도 얼마 되지 않았죠.
    그래서 그냥 덮어쓰지 않고 기존에 발급받은 키를 사용하기로 했습니다.

    처음엔 Github과 서버 PC에 같은 키를 사용하는 게 과연 맞는지, 서버마다 다른 키를 써야 하는 건 아닌지 궁금했습니다.

    관련 Reddit 포스트를 읽고 나서 일반적인 경우 한 기기당 키 하나를 유지하는 게 맞겠다고 생각했습니다.
    비밀번호랑 다르게 개인 키에 문제가 생겼다 == 내 기기가 털렸다라는 의미에서 모든 ssh 키는 운명 공동체일 테니까요.

    물론 하나의 키를 사용하더라도 ssh 키를 새로 발급하고 서버 공개 키를 업데이트하는 Key Rotation을 주기적으로 해주면 좋다고 합니다.

    SSH 서버 설정 바꾸기

    서버 PC에서 ssh 설정 파일을 수정해 주겠습니다.
    nano, emacs, gedit 등 선호하는 텍스트 에디터를 사용해 주세요. 저는 vim을 쓰겠습니다.

    sudo vim /etc/ssh/sshd_config

    비밀번호 인증을 막아두겠습니다.
    PasswordAuthentification의 주석을 해제하고, 값을 no로 바꿔줍니다.

    Vim을 사용 중이시라면 /Password로 검색, n/N 으로 탐색이 가능합니다.
    i 를 통해 insert 모드로 들어가 수정 후 ESC를 눌러 normal 모드로 전환해 주세요.
    :wq를 통해 저장 후 편집기를 나가 주시면 끝입니다.

    설정 반영을 위해 ssh 서비스를 다시 시작해 줍니다.

    sudo service ssh restart

    이제 클라이언트 PC에서 ssh 접속을 하면 ssh key와 설정한 passphrase를 사용하여 로그인이 가능합니다.

    보안을 위한 추가 설정

    다시 서버 PC에서 ssh 설정 파일을 건드려 주겠습니다.

    sudo vim /etc/ssh/sshd_config

    Root 로그인 비활성화

    PermitRootLogin 설정을 no 로 바꿔주세요.
    기본 값은 아마 패스워드 로그인만 불가능 하도록 설정 되어 있을 텐데요.
    어짜피 sudo 명령어를 이용해서 필요한 작업을 할 예정이니 아예 root 로그인 자체를 막아두겠습니다.

    ssh 포트 번호 변경

    ssh 연결 기본 포트 22번을 다른 번호로 바꿔주겠습니다.
    포트 스캔을 하면 금방 들키겠지만, 22번 포트만 대충 찔러보는 식의 공격에서는 벗어날 수 있습니다.

    설정에서 Port 를 원하는 포트 숫자로 바꿔주세요. 저는 22224를 써 보겠습니다.

    앞으로는 클라이언트 PC에서 접속 할 때마다 -p 옵션을 통해 포트 번호를 명시해주면 됩니다.

    ssh brokenhinge@172.30.1.100 -p 22224

    물론 방화벽도 수정 해 줘야겠죠.

    서버 PC에서 22번 방화벽을 다시 닫겠습니다.
    ufw status 에서 규칙 번호를 확인하고 삭제해주세요.

    sudo ufw status
sudo ufw delete 2

    새로운 포트를 열어줍니다. 

    sudo ufw allow 22224
sudo ufw reload

    VERBOSE Logging

    LogLevel 값을 VERBOSE로 바꿔줍니다.
    로그인한 유저의 퍼블릭 키를 포함해 더 디테일한 로그를 볼 수 있어 관리가 용이합니다.

    그 외 고려할만한 ssh 설정 값

    • MaxAuthTries: 한 번에 가능한 인증 시도 횟수 입니다. 기본 값은 6번입니다. 4회 이하로 바꾸셔도 좋습니다.
    • LoginGraceTime: 이 시간 내 로그인을 하지 못하면 연결을 끊습니다. 기본 값은 120초입니다.
    • ClientAliveInterval: 연결한 클라이언트가 명시한 시간동안 아무것도 안 한다면 연결을 끊어줍니다. 기본 값은 없습니다.
    • X11Forwarding: 원격으로 GUI 사용이 가능해집니다. 보안을 위해 끄는 게 권장됩니다. 저는 편의성을 위해 켜줬습니다.

    아래 설정을 통해 포트 포워딩을 막아두면 백도어 공격을 예방할 수 있습니다.

    AllowTcpForwarding no AllowStreamLocalForwarding no GatewayPorts no PermitTunnel no

    그 외 추가 내용은 아래 링크를 참고해 주세요.

    SSH 편의성 설정

    클라이언트 PC에서~/.ssh/config 파일을 다음과 같이 수정해줍니다.

    HOST dev-server
    HostName 172.30.1.100
    Port 22224
    User brokenhinge

    이제 타이핑 할 게 줄어들었습니다.

    ssh dev-server

    매 연결마다 passphrase 입력 하는 게 귀찮다면, 아래 설정을 추가해 주면 됩니다.
    ~/.ssh/config 에서 ControlMaster 세팅을 하면 ssh 연결 소켓을 캐싱할 수 있습니다. 

    HOST *
    ControlMaster auto
    ControlPath ~/.ssh/tmp/%r@%h-%p
    ControlPersist 1

HOST dev-server
    HostName 172.30.1.100
    Port 22224
    User brokenhinge
    ControlPersist 6h

    저는 연결을 6시간 동안 유지하도록 설정했습니다.

    ControlPath에 공유 소켓 파일이 들어가게 됩니다.
    저처럼 tmp 디렉토리를 따로 보관하실 거라면 설정 전에 해당 디렉토리를 꼭 만들어 주세요.

    추가 조치

    방화벽에서 접근 가능한 ip를 제한하거나 (해외 ip 등 제외하기) Fail2Ban 같은 툴을 이용해 로그인을 시도해보는 ip를 자동으로 밴 할 수 있습니다.

    혹은 ssh포트를 여는 대신 VPN을 통해 사설망 접근만 가능하게 할 수도 있습니다.
    이는 tailscale 서비스를 쓰는 내용으로 마지막에 잠깐 다뤄 보겠습니다.

    SSH 포트 열기

    이제 준비가 된 것 같으니 ssh 포트를 열어보겠습니다.

    공유기 설정 사이트에서 22224 포트 포워딩을 해줍니다.
    설정 방법은 공유기 제조사 별로 다릅니다.

    이제 다른 네트워크에서도 ssh 접속이 가능합니다.
    저는 핸드폰 핫스팟으로 ssh 접속을 해보겠습니다.

    ssh brokenhinge@<public_ip_addr> -p 22224

    접속이 잘 되네요.

    해커들도 접속 시도를 하기 시작했을까요?
    로그를 확인해보겠습니다.
    journalctl을 사용 해 보겠습니다.

    journalctl -t sshd -b0 -r

    -b0 는 최근 부팅 이후, -r 은 로그를 역순으로 보여 달라는 플래그입니다.

    아무런 침입 시도가 안보여 서버를 켜놓고 한숨 자고 오기로 합니다.

    자고 와도 별 로그가 안 남아 있더라고요.

    결국 집 앞 카페에 가서 제가 해커가 되어 보기로 했습니다.

    키를 등록한 클라이언트 PC에서 다른 유저네임으로 연결 시도

    Connection closed by invalid user POWERUSER ***.***.***.*** port ***** [preauth]
Invalid user POWERUSER from ***.***.***.*** port ***** ssh2: ED25519 SHA256:
Connection from ***.***.***.*** port ***** on ***.***.***.*** port 22224 rdomain ""

    키가 등록되지 않은 클라이언트 PC에서 연결 시도

    Connection reset by authenticating user brokenhinge ***.***.***.*** port ***** [preauth]
Connection from ***.***.***.*** port ***** on ***.***.***.*** port 22224 rdomain ""
Connection reset by authenticating user root ***.***.***.*** port ***** [preauth]
Connection from ***.***.***.*** port ***** on ***.***.***.*** port 22224 rdomain ""

    좋네요.

    VPN을 통한 SSH 연결: Tailscale 사용하기

    앞서 VPN을 통한 사설망 접근만 가능하게 하는 방법을 언급했었습니다.
    몇가지 따라 해보려 했는데 VPN 서버를 또 공부하고 구축하고 설정하는게 쉽지 않았습니다.

    그러다 Tailscale을 알게 되었습니다. 엄청 충격적으로 편리하더라고요.
    포트 포워딩 없이 ssh 연결이 가능하니, 그래서 포트 포워딩 해 놓았던 것도 다 닫아버리고 Tailscale로 갈아탔습니다.

    설치 및 ssh 연결

    다음 명령어를 통해 Tailscale을 설치 해 줍니다.

    curl -fsSL https://tailscale.com/install.sh | sh

    아래 명령어로 tailscale 네트워크에 접속해 줍니다.

    sudo tailscale up

    로그인/가입을 하라고 합니다. 여기서 tailscale의 장점이 나옵니다.
    OAUTH를 사용하기 때문에 구글, MS, Github 계정을 통한 가입 및 로그인이 가능합니다.

    클라이언트 PC와 서버 PC 모두 tailscale을 설치, 로그인, 접속 해주세요.
    이제 Tailscale 네트워크를 통해 두 컴퓨터가 연결되었습니다.

    서버 컴퓨터에서 ssh 연결을 켜 줍니다.

    sudo tailscale up --ssh

    그다음 클라이언트 PC에서 접속해 보겠습니다.
    Tailscale 네트워크 안에서는 ip 주소 대신 등록한 기기 명을 주소로 사용 가능합니다.

    ssh brokenhinge@dev-machine

    ssh 포트를 외부에 열어 줄 필요 없이, 어디서든 간단하게 서버 컴퓨터에 ssh 접속이 가능합니다.

    방화벽 설정도 필요 없고요.

    이제 해커가 제 서버에 ssh 연결을 시도하려면 제 구글 혹은 깃헙 계정을 먼저 탈취해 Tailscale 네트워크에 연결해야 합니다.
    가능성이 낮지만 절대 없는 일은 아니죠. 그러니 2차 인증 설정을 해주면 더 안전하겠죠.
    ssh 접속 가능 클라이언트와 호스트 등을 세팅해줘도 좋습니다.

    기기는 100대 연결 까지 무료라고 합니다.
    일반적인 중앙 집중식 VPN 서버 대신 가벼운 coordination 서버와 P2P 연결을 사용해서 가능한 무료 플랜이라고 하네요.

    WSL 환경에서 Tailscale 사용 할 경우 주의점

    저처럼 WSL 내부에서 Tailscale을 사용해 ssh 접속을 할 경우, 처음에는 잘 되다가 ssh: Could not reslove hostname 와 같은 에러가 뜰 수 있습니다.
    WSL 과 Tailscale이 /etc/resolv.conf 파일으로 네임서버를 관리하는 과정에서 생기는 문제인듯 합니다.

    C:\Users\<UserName>\.wslconfig 파일에 다음을 추가 해 주세요.

    [wsl2]
dnsTunneling=true

    해당 방법은 깃헙 gist 댓글창 에서 찾았습니다.
    .wslconfig 에 관해서는 MS 공식문서 를 참고해 보셔도 좋겠습니다.

    Outro

    도움이 되었으면 좋겠네요. 읽어주셔서 감사합니다.

    관련글 관련글 더보기

    댓글

티스토리툴바