A-9: 네트워크와 원격 접속

안녕하세요, 여러분의 리눅스 길잡이 홍순구 튜터입니다.

지난 시간 우리는 리눅스 한 대 안에서 소프트웨어를 설치하고(apt), 서비스로 띄우고(systemctl), 로그를 보고(journalctl), 작업을 예약하는(cron) 시스템 관리의 전 과정을 거쳤어요. 그러면서 제가 슬쩍 흘린 질문이 하나 있었죠. "현업에서 이 모든 일은 내 노트북이 아니라 저 멀리 데이터센터나 클라우드에 있는 원격 서버에서 벌어진다. 그 서버엔 화면도 키보드도 없는데, 대체 어떻게 들어가서 명령을 칠까?"

오늘 그 문을 엽니다. 솔직히 말하면, 신입 때 서버 접속 앞에서 한 번도 안 헤맨 사람은 거의 없어요. "비밀번호가 자꾸 틀려요", "키를 어디다 두는 거예요?", "접속이 거부됐는데 뭘 봐야 하죠?" 다들 겪는 통과의례입니다. 그러니 겁먹지 마세요. 오늘 우리는 네트워크가 어떻게 동작하는지 기초부터 차근차근 짚고, 마지막엔 여러분 손으로 만든 열쇠 하나로 원격 서버에 비밀번호 없이 쏙 들어가 볼 거예요.

오늘은 이런 길을 따라갑니다.

  오늘의 여정 — "원격 서버의 문을 열기까지"

  ① TCP/IP·포트     컴퓨터끼리 어떻게 말을 주고받나 (IP·포트·계층)
  ② 이름과 DNS      google.com 이 어떻게 숫자 주소로 바뀌나 (ping·dig)
  ③ 연결 보기       내 서버가 지금 어떤 포트를 열어두고 있나 (ss·lsof)
  ④ SSH 인증        비밀번호 vs 키 — 왜 키가 더 안전한가
  ⑤ 키 만들고 접속   ssh-keygen 으로 열쇠를 만들어 원격 서버에 입장

💡 오늘 수업의 핵심 — "이름과 포트로 길을 찾고, 열쇠 한 쌍으로 화면 없는 원격 서버의 문을 안전하게 연다"

원격 접속은 어려운 게 아니라 낯선 것일 뿐이에요. 네트워크의 기본 규칙(IP·포트·DNS)을 한 번 이해하고, SSH 키가 왜 비밀번호보다 안전한지 그 원리를 잡고 나면, 그다음부터는 ssh 서버이름 한 줄로 끝납니다. 오늘 그 원리를 차근차근 함께 풀어볼게요.

🎯 학습 목표

• TCP/IP·포트·DNS로 컴퓨터끼리 어떻게 서로를 찾고 말을 주고받는지 이해한다.
• ss/lsof로 서버가 열어둔 포트를 확인하고, 지난 시간의 "포트 잡은 프로세스 찾기"와 잇는다.
• SSH 키 한 쌍을 직접 만들어, 비밀번호 없이 원격 서버에 안전하게 접속한다.

Step 1: "내 컴퓨터는 어떻게 남의 컴퓨터와 말을 섞을까"

새 기술을 배우기 전엔 그 밑바닥부터 짚는 게 우리 방식이죠. 원격 접속도 결국 "내 컴퓨터가 멀리 있는 다른 컴퓨터와 대화하는 일"입니다. 그 대화가 어떻게 이뤄지는지부터 봅시다.

네트워크는 우편 시스템과 닮았다

컴퓨터끼리 데이터를 주고받는 걸 네트워크(network)라고 해요. 이걸 우편에 비유하면 이해가 쉬워요. 편지를 보내려면 (1) 내용을 쓰고, (2) 봉투에 받는 사람 주소를 적고, (3) 우체국이 그 주소를 보고 분류하고, (4) 트럭이 실제로 실어 나르죠.

인터넷도 똑같이 일을 층(layer)으로 나눠서 처리해요. 이걸 TCP/IP 4계층이라고 부릅니다.

  층(layer)        하는 일                       우편 비유
  ───────────      ─────────────────────────     ──────────────
  응용 계층         "무슨 내용을 보낼까" (HTTP·SSH)   편지 내용 쓰기
  전송 계층(TCP)    "빠짐없이·순서대로 전달"          등기우편 (도착 확인)
  인터넷 계층(IP)   "어느 컴퓨터로 보낼까" (IP 주소)   봉투에 주소 적기
  링크 계층         "실제 선·전파로 나르기"           트럭·비행기로 운송

왜 굳이 층으로 나눌까

한 덩어리로 다 처리하지 않고 층을 나눈 이유는, 각 층이 자기 일만 잘하면 되기 때문이에요. 편지 내용을 쓰는 사람은 트럭이 어떻게 굴러가는지 몰라도 됩니다. 마찬가지로 웹 브라우저는 "데이터를 어떻게 전선으로 흘려보내는지" 신경 쓸 필요 없이, 그냥 "이 주소로 이 내용을 보내줘"라고 아래 층에 맡기면 돼요. 이 덕분에 와이파이든 유선이든 5G든, 윗 층 코드는 그대로 통합니다.

IP 주소와 포트 — 건물 주소와 호실 번호

여기서 두 가지 핵심 개념이 나와요.

IP 주소(IP address)는 네트워크에 연결된 컴퓨터 하나하나의 주소예요. 203.0.113.10처럼 점으로 나뉜 숫자 네 덩어리로 생겼죠(IPv4). 건물 주소라고 생각하면 됩니다.

그런데 컴퓨터 한 대는 여러 프로그램을 동시에 돌려요. 웹 서버도 돌고, SSH 접속도 받고요. 그래서 "건물 주소(IP)"만으로는 부족하고, 그 건물 안의 어느 호실로 갈지를 정하는 번호가 필요해요. 그게 포트(port)입니다. 0번부터 65535번까지 있어요.

  IP 주소 = 건물 주소,   포트 = 그 건물 안의 호실 번호

  203.0.113.10 : 22     →  SSH   (원격 접속용 문)
  203.0.113.10 : 80     →  HTTP  (웹 서버 — 지난 시간 nginx 가 살던 곳)
  203.0.113.10 : 443    →  HTTPS (보안이 적용된 웹)
            └ IP ┘ └port┘

특히 자주 쓰는 포트는 번호가 약속돼 있어요. 22번은 SSH, 80번은 HTTP, 443번은 HTTPS. 지난 시간 nginx를 설치하고 sudo ss -ltnp | grep :80으로 80번 포트를 잡고 있는지 확인했던 것 기억나시죠? 그 80번이 바로 "웹 서버용 호실"이었던 거예요. 오늘 우리가 열려는 SSH 문은 22번이고요.

현업에선 "그 서비스 몇 번 포트 쓰죠?"라는 질문을 정말 자주 들어요. 포트는 외울 게 아니라 "건물 안 호실 번호"라는 그림만 잡아두면, 22(SSH)·80(웹)·443(보안 웹)·3306(MySQL)·6379(Redis) 같은 단골 번호는 자연스럽게 익숙해집니다.

💡 한 줄 정리

네트워크는 일을 층(TCP/IP 4계층)으로 나눠 처리하고, 컴퓨터는 IP 주소(건물)로 찾고 포트(호실)로 어느 프로그램과 말할지 정한다. SSH는 22번, 웹은 80·443번 포트를 쓴다.

Step 2: "google.com 을 어떻게 찾아갈까"

Step 1에서 컴퓨터는 IP 주소(숫자)로 서로를 찾는다고 했어요. 그런데 우리가 브라우저에 칠 때는 142.251.x.x가 아니라 google.com이라고 치잖아요? 사람은 이름이 편하고, 컴퓨터는 숫자가 편해요. 이 둘을 이어주는 게 바로 DNS입니다.

DNS는 인터넷의 연락처 앱

DNS(Domain Name System)는 "이름 → IP 주소"를 찾아주는 거대한 전화번호부예요. 우리가 연락처 앱에서 "엄마"를 누르면 실제 전화번호로 거는 것과 똑같아요. google.com을 입력하면, 컴퓨터는 DNS에게 "이 이름의 진짜 주소(IP)가 뭐야?"라고 물어보고 답을 받아 그리로 연결합니다.

  나: "google.com 으로 가고 싶어"
       │
       ▼
  ① 내 컴퓨터의 작은 수첩(/etc/hosts) 먼저 확인
       │  없으면
       ▼
  ② DNS 서버에 질의 "google.com 의 IP 가 뭐야?"
       │
       ▼
  ③ DNS: "142.251.x.x 야"
       │
       ▼
  나: 그 IP 로 접속!

/etc/hosts — 내 컴퓨터만의 작은 수첩

컴퓨터는 DNS 서버에 묻기 전에, 자기 안의 작은 수첩 파일 /etc/hosts를 먼저 봐요. 여기에 직접 "이 이름은 이 IP"라고 적어두면, DNS를 거치지 않고 바로 그리로 갑니다.

cat /etc/hosts

127.0.0.1   localhost
203.0.113.10   myserver

이렇게 적어두면 myserver라는 이름이 곧 203.0.113.10을 가리켜요. 실무에서 아직 도메인이 없는 테스트 서버에 별명을 붙일 때 종종 씁니다. 참고로 localhost는 "내 컴퓨터 자신"을 가리키는 약속된 이름이고, 그 IP가 127.0.0.1이에요.

ping — 살아있니? 두드려보기

상대 컴퓨터가 응답하는지 가장 간단히 확인하는 명령이 ping이에요. 문을 똑똑 두드려보고 "야 살아있어?" 하는 거죠.

ping -c 3 google.com

PING google.com (142.251.207.46) 56(84) bytes of data.
64 bytes from 142.251.207.46: icmp_seq=1 ttl=115 time=33.2 ms
64 bytes from 142.251.207.46: icmp_seq=2 ttl=115 time=33.9 ms
64 bytes from 142.251.207.46: icmp_seq=3 ttl=115 time=34.0 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 33.234/33.711/34.012/0.331 ms

-c 3은 "세 번만 두드리고 멈춰"라는 뜻이에요(안 주면 멈출 때까지 계속 두드립니다 — Ctrl+C로 멈춰요). 응답이 돌아오는 데 33밀리초쯤 걸렸고, 빠진 패킷 없이(0% packet loss) 잘 도착했네요. 또 하나 주목할 건, ping이 자동으로 google.com을 IP 142.251.207.46으로 바꿔서 보여준다는 거예요. 이게 바로 방금 말한 DNS가 동작한 결과입니다.

dig — 이름의 진짜 주소를 캐묻기

DNS 조회를 좀 더 자세히 보고 싶으면 dig를 써요. 가장 간단하게 IP만 보려면 +short를 붙입니다.

dig +short google.com

142.251.207.46
142.251.207.78
142.251.207.110

한 이름에 IP가 여러 개 묶여 있죠? 큰 서비스는 트래픽을 나눠 받으려고 여러 서버를 둬요. 자세히 보고 싶으면 +short 없이 dig google.com을 치면 질의·응답 과정이 한눈에 나옵니다.

예전엔 nslookup을 많이 썼고 지금도 동작해요. 다만 더 자세하고 현업에서 선호되는 건 dig라, 우리는 dig를 기본으로 잡고 nslookup은 "예전부터 있던 도구" 정도로만 기억해두면 됩니다.

지난 시간 끝에 제가 "원격 서버를 어떻게 찾아 들어가지?"라고 물었죠. 그 답의 절반이 여기 있어요. 서버는 이름(DNS)이나 IP 주소로 찾습니다. 이제 어디로 갈지는 알았으니, 다음은 "그 서버가 어떤 문을 열어두고 있나"를 들여다볼 차례예요.

💡 한 줄 정리

DNS는 "이름 → IP"를 찾아주는 인터넷의 연락처 앱이다. 컴퓨터는 /etc/hosts(내 수첩)를 먼저 보고 없으면 DNS 서버에 묻는다. ping으로 살아있는지 두드리고, dig로 이름의 진짜 IP를 캐묻는다.

Step 3: "내 서버는 지금 어떤 문을 열어두고 있나"

Step 1에서 포트를 "건물 안 호실"에 비유했죠. 그럼 내 컴퓨터(또는 서버)는 지금 어떤 호실 문을 열어두고 손님을 기다리고 있을까요? 이걸 보는 게 오늘 Step의 주제예요. 그리고 이건 지난 시간 우리를 괴롭혔던 그 문제와 바로 이어집니다.

ss — 열려 있는 포트와 그 주인 보기

리눅스에서 "지금 열려 있는 연결과 포트"를 보는 현행 표준 명령은 ss예요(socket statistics의 줄임말). 자주 쓰는 형태는 이거예요.

sudo ss -ltnp

State   Recv-Q  Send-Q   Local Address:Port   Peer Address:Port  Process
LISTEN  0       4096           0.0.0.0:22          0.0.0.0:*      users:(("sshd",pid=812,fd=3))
LISTEN  0       511            0.0.0.0:80          0.0.0.0:*      users:(("nginx",pid=1234,fd=6))

옵션이 네 글자 붙었는데, 외울 필요 없이 한 글자씩 풀어보면 의미가 보여요.

  ss -l t n p
       │ │ │ └ process : 그 포트를 잡고 있는 프로그램과 PID 까지 보여줘
       │ │ └── numeric : 이름 말고 숫자(포트 번호) 그대로 보여줘
       │ └──── tcp     : TCP 연결만 (우리가 쓰는 건 거의 다 TCP)
       └────── listen  : 손님을 "기다리는 중(LISTEN)"인 포트만

출력을 읽어볼까요? 두 번째 줄을 보면 0.0.0.0:22 포트를 sshd라는 프로그램이 PID 812번으로 잡고 있어요. SSH 접속을 받으려고 22번 문을 열어둔 거죠. 세 번째 줄은 0.0.0.0:80을 nginx가 1234번으로 잡고 있고요. 지난 시간 설치한 그 nginx가 80번 웹 포트를 열고 손님을 기다리는 모습 그대로예요.

지난 시간의 그 문제와 잇기

기억나시나요? 지지난 시간 프로세스를 배우면서 "신입이 서버에서 가장 많이 막히는 상황"으로 "포트를 이미 잡고 있는 프로세스를 못 죽여서 서버를 못 띄우는 일"을 이야기했어요. 새 서버를 띄우려는데 "8080 포트가 이미 사용 중"이라며 안 뜨는 그 상황요.

그때의 해법이 바로 이 ss였어요. 흐름은 이렇게 이어집니다.

sudo ss -ltnp | grep :8080     # ① 8080 을 잡은 프로그램의 PID 알아내기
sudo kill 3120                 # ② 그 PID 를 종료 (지난 시간에 배운 kill)

ss로 "범인의 PID"를 찾고, 지난 시간 배운 kill로 정리하는 거죠. 네트워크를 보는 ss와 프로세스를 다루는 kill이 이렇게 한 흐름으로 맞물려요.

lsof — 특정 포트를 누가 쓰나 콕 집어 보기

비슷하게 "이 포트, 대체 누가 쓰는 거야?"를 콕 집어 보고 싶으면 lsof -i를 써요(list open files).

sudo lsof -i :80

COMMAND   PID  USER     FD   TYPE DEVICE SIZE/OFF NODE NAME
nginx    1234  root     6u   IPv4  29612      0t0  TCP *:http (LISTEN)
nginx    1235  www-data 6u   IPv4  29612      0t0  TCP *:http (LISTEN)

80번 포트를 nginx가 쓰고 있다고 분명히 나오죠. ss가 전체 지도라면 lsof -i :포트는 한 포트를 돋보기로 들여다보는 느낌이에요.

⚠️ 옛날 자료를 보면 netstat -tlnp라는 명령이 자주 나와요. ss의 옛날 버전이라고 보면 됩니다. 요즘 우분투에는 아예 설치가 안 돼 있어서 netstat: command not found가 뜨기도 해요. 그러니 본체는 ss로 익히고, netstat은 "예전엔 이걸 썼구나" 정도로만 알아두세요. 네트워크 설정을 보는 ifconfig도 마찬가지로 요즘은 ip(예: ip a)로 대체됐어요.

💡 한 줄 정리

ss -ltnp로 서버가 열어둔(LISTEN) 포트와 그걸 잡은 프로그램·PID를 본다. ss로 PID를 찾아 지난 시간의 kill로 정리하는 흐름이 핵심이다. 한 포트를 콕 보려면 lsof -i :포트. netstat·ifconfig는 구 명령이고 현행은 ss·ip다.

Step 4: "비밀번호는 왜 위험하고 키는 왜 안전할까"

자, 이제 드디어 원격 서버에 들어갑니다. 지난 시간 끝에 던진 질문 "화면도 키보드도 없는 원격 서버에 어떻게 들어가서 명령을 칠까?"의 답이 바로 SSH예요.

SSH — 멀리 있는 셸을 내 앞으로 끌어오는 통로

SSH(Secure Shell)는 멀리 있는 컴퓨터의 셸(터미널)을 내 앞에서 그대로 쓰게 해주는 도구예요. 내 노트북에서 명령을 치면 그게 원격 서버에서 실행되고, 결과가 내 화면으로 돌아옵니다. 마치 그 서버 앞에 앉아 있는 것처럼요. 기본 사용법은 이렇게 단순해요.

ssh alice@203.0.113.10

alice라는 사용자로 203.0.113.10 서버에 들어가겠다는 뜻이에요. "이름@주소" 형태죠. 그런데 여기서 중요한 갈림길이 나와요. 서버가 "너 진짜 alice 맞아?"라고 확인하는 방법이 두 가지거든요.

두 가지 인증 방식

① 비밀번호 인증은 우리에게 가장 익숙해요. 접속할 때마다 비밀번호를 입력하는 방식이죠. 그런데 서버 운영에선 약점이 큽니다.

• 접속할 때마다 매번 직접 입력해야 해서 번거롭다(자동화도 어렵다).
• 사람이 외우는 비밀번호는 대개 약하다.
• 공격자가 흔한 비밀번호를 1초에 수천 번씩 자동으로 찔러보는 무차별 대입 공격에 노출된다.

② 키 인증은 비밀번호 대신 열쇠 한 쌍을 쓰는 방식이에요. 현업 서버 접속은 거의 다 이 방식입니다. 왜 더 안전한지 비유로 보죠.

자물쇠(공개키)와 열쇠(개인키)

키 인증은 한 쌍으로 움직여요. 공개키(public key)는 자물쇠, 개인키(private key)는 그 자물쇠를 여는 유일한 열쇠라고 생각하면 딱 맞아요.

• 공개키(자물쇠): 남이 봐도 괜찮아요. 원격 서버에 미리 걸어둡니다("이 자물쇠를 열 수 있는 사람만 들여보내라").
• 개인키(열쇠): 오직 나만 가집니다. 절대 남에게 주거나 네트워크로 보내지 않아요.

  내 노트북                                  원격 서버
  ─────────                                 ─────────
  개인키  id_ed25519      (열쇠 · 나만 가진다 · 밖으로 절대 안 나감)
  공개키  id_ed25519.pub  ──미리 등록──▶  서버의 ~/.ssh/authorized_keys (자물쇠)

  ssh alice@server 접속 순간 벌어지는 일:
    1) 나                  ──"접속할게"──▶          서버
    2) 나   ◀──"이 자물쇠로 낸 수수께끼 풀어봐"──     서버
    3) 나(개인키로 풀어서)  ──"정답!"──▶             서버
    4) 나                  ◀──"통과! 입장하세요"──    서버

핵심은 3번이에요. 서버는 자물쇠(공개키)로 수수께끼를 내고, 나는 그걸 내 열쇠(개인키)로 풀어 답을 보내요. 이 과정에서 개인키 자체는 절대 네트워크로 나가지 않습니다. 그러니 중간에 누가 통신을 엿들어도 열쇠를 훔칠 수가 없어요. 비밀번호는 "정답 그 자체"를 매번 보내야 하지만, 키 인증은 "정답을 안다는 증거"만 보내는 거죠. 이게 키가 훨씬 안전한 이유예요.

현업에선 새 서버를 받으면 가장 먼저 하는 일이 "내 공개키를 등록하고 비밀번호 로그인은 아예 꺼버리는 것"이에요. 무차별 대입 공격을 원천 차단하는 가장 기본적인 방어죠. 오늘 그 첫걸음인 키 만들기와 등록을 직접 해봅니다.

참고로 SSH의 표준 구현인 OpenSSH는 오늘날 사실상 모든 리눅스·맥에 기본 탑재돼 있어요. 우리가 칠 ssh·ssh-keygen이 전부 여기 들어 있습니다.

💡 한 줄 정리

SSH는 멀리 있는 서버의 셸을 내 앞에서 쓰게 해주는 안전한 통로다. 인증은 비밀번호 방식과 키 방식이 있는데, 키 방식은 공개키(자물쇠)를 서버에 걸어두고 개인키(열쇠)는 나만 가진다. 개인키가 네트워크로 나가지 않아 비밀번호보다 안전하다.

Step 5: "내 열쇠를 만들어 원격 서버에 입장하기"

원리를 잡았으니 이제 직접 손으로 해봅시다. 열쇠 한 쌍을 만들고, 자물쇠를 서버에 걸고, 비밀번호 없이 입장하는 전 과정을 거쳐볼게요.

① 열쇠 한 쌍 만들기 — ssh-keygen

키를 만드는 명령은 ssh-keygen이에요. 요즘 권장되는 키 종류는 ed25519입니다(짧고 빠르고 안전해요).

ssh-keygen -t ed25519 -C "alice@laptop"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alice/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alice/.ssh/id_ed25519
Your public key has been saved in /home/alice/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:cBfDZwa/ROCGfh5INfN4AiaoTmKnxPwc/wWuqmUEEi0 alice@laptop

-t ed25519는 키 종류, -C "alice@laptop"은 "이 키가 누구 건지" 알아보기 쉽게 다는 메모예요. 중간에 세 번 묻는데, 저장 위치와 암호문구(passphrase)예요. 일단 다 엔터로 넘어가도 괜찮아요(암호문구는 비워두면 나중에 접속할 때 안 물어봐서 편하지만, 보안을 더 챙기려면 걸어두세요).

아주 오래된 일부 장비와 호환이 꼭 필요하면 ssh-keygen -t rsa -b 4096처럼 RSA 키를 쓰기도 해요. 하지만 특별한 이유가 없다면 오늘날 표준은 ed25519입니다.

② 만들어진 열쇠 두 개와 그 권한 확인

~/.ssh 디렉토리를 보면 파일이 두 개 생겼어요. 첫 모듈에서 배운 ~가 내 홈 디렉토리였던 것 기억나시죠.

ls -l ~/.ssh

-rw-------  1 alice alice  399  6월 17 12:56 id_ed25519
-rw-r--r--  1 alice alice   94  6월 17 12:56 id_ed25519.pub

여기서 권한을 꼭 보세요. 지난 모듈에서 배운 권한 10글자가 다시 나옵니다.

• id_ed25519(개인키, 열쇠): 권한이 -rw-------예요. 8진수로는 600, 즉 "주인만 읽고 쓰기, 남은 아무것도 못 함". 열쇠니까 당연히 나만 봐야죠.
• id_ed25519.pub(공개키, 자물쇠): -rw-r--r--(644)라 남도 읽을 수 있어요. 자물쇠는 공개돼도 괜찮으니까요.

이 권한은 SSH가 직접 챙겨요. 만약 개인키 권한이 너무 헐렁하면(남도 읽을 수 있으면) SSH가 "이 열쇠는 위험하다"며 아예 접속을 거부해요. 그럴 땐 지난 시간에 배운 chmod 600 ~/.ssh/id_ed25519로 조여주면 됩니다.

③ 공개키(자물쇠)를 서버에 걸기 — ssh-copy-id

이제 자물쇠를 원격 서버에 걸어야 해요. ssh-copy-id가 이걸 한 방에 해줍니다.

ssh-copy-id alice@203.0.113.10

이 명령을 처음 한 번은 비밀번호를 물어봐요(아직 자물쇠가 안 걸렸으니까요). 입력하면 내 공개키가 서버의 ~/.ssh/authorized_keys 파일에 등록됩니다. 이 파일이 바로 "이 자물쇠들을 열 수 있는 사람은 들여보내라"는 명단이에요.

④ 비밀번호 없이 입장!

이제 다시 접속해보면, 비밀번호를 묻지 않고 바로 들어가져요.

ssh alice@203.0.113.10

Welcome to Ubuntu 26.04 LTS (GNU/Linux ...)
alice@myserver:~$

프롬프트가 alice@myserver로 바뀌었죠? 지금 여러분은 남의 컴퓨터 셸 안에 들어와 있는 거예요. 그리고 바로 여기서, 지난 시간 로컬에서 했던 일들을 그대로 할 수 있어요.

alice@myserver:~$ sudo apt update && sudo apt install nginx   # 설치 (지난 시간 그대로)
alice@myserver:~$ sudo systemctl enable --now nginx           # 서비스 띄우기
alice@myserver:~$ journalctl -u nginx -f                       # 로그 보기

지난 시간 우리가 로컬에서 익힌 apt·systemctl·journalctl이, 이제 저 멀리 있는 원격 서버 위에서 똑같이 돌아가는 거예요. "남의 컴퓨터를 내 컴퓨터처럼" 다루는 그 첫 관문을 방금 넘은 겁니다.

⑤ 매번 길게 치기 귀찮다면 — ~/.ssh/config

서버가 여러 개거나 주소가 길면 매번 ssh alice@203.0.113.10을 치기 번거로워요. ~/.ssh/config 파일에 별명을 적어두면 한 단어로 접속할 수 있어요.

cat ~/.ssh/config

Host myserver
    HostName 203.0.113.10
    User alice
    IdentityFile ~/.ssh/id_ed25519

이렇게 적어두면 이제 이거면 끝이에요.

ssh myserver

Host는 내가 부를 별명, HostName은 진짜 주소, User는 접속 사용자, IdentityFile은 쓸 열쇠예요. 현업에선 다루는 서버마다 이렇게 별명을 등록해두고 ssh 별명 한 줄로 드나듭니다.

💡 한 줄 정리

ssh-keygen -t ed25519로 열쇠 한 쌍(개인키 600·공개키 644)을 만들고, ssh-copy-id로 공개키를 서버에 걸면, 그다음부터 ssh 사용자@주소로 비밀번호 없이 입장한다. ~/.ssh/config에 별명을 등록하면 ssh 별명 한 줄로 끝난다.

마무리

오늘은 화면도 키보드도 없는 원격 서버의 문을 여는 전 과정을 거쳤어요. 네트워크가 IP·포트·DNS로 어떻게 동작하는지 기초를 잡고, 서버가 연 포트를 ss로 들여다보고, 마지막엔 직접 만든 열쇠 한 쌍으로 비밀번호 없이 원격 서버에 입장했죠. 지난 시간 "어떻게 들어가지?"라고 궁금해하던 그 문을, 오늘 여러분 손으로 연 거예요. 핵심을 셋으로 정리할게요.

오늘 배운 핵심 세 가지

💡 하나 — 네트워크는 일을 층(TCP/IP 4계층)으로 나눠 처리한다. 컴퓨터는 IP 주소(건물)로 찾고 포트(호실)로 어느 프로그램과 말할지 정한다. SSH는 22번, 웹은 80·443번이다. 이름을 IP로 바꿔주는 게 DNS이고, ping으로 두드려보고 dig로 진짜 주소를 캐묻는다.

💡 둘 — 서버가 열어둔 포트와 그 주인은 ss -ltnp로 본다. ss로 포트를 잡은 PID를 찾아 지난 시간의 kill로 정리하는 흐름이 핵심이다. 한 포트를 콕 보려면 lsof -i :포트. 구 명령 netstat·ifconfig의 현행은 ss·ip다.

💡 셋 — 원격 접속은 SSH로 한다. 키 인증은 공개키(자물쇠)를 서버에 걸고 개인키(열쇠)는 나만 가져, 개인키가 네트워크로 나가지 않아 비밀번호보다 안전하다. ssh-keygen -t ed25519로 열쇠를 만들고(개인키 권한 600), ssh-copy-id로 등록한 뒤 ssh 사용자@주소로 입장한다.

다음 시간 예고

이제 원격 서버 안에 들어왔어요. 그런데 들어가서 끝이 아니죠. 실무에선 내 컴퓨터의 파일을 서버로 올리거나 서버의 로그를 내 노트북으로 내려받아야 하고, 서버가 잘 응답하는지 웹으로 직접 두드려봐야 하고, 아무나 못 들어오게 방화벽으로 문을 여닫아야 합니다.

다음 시간엔 그 "원격 운영"의 도구들을 배워요. 방금 만든 SSH 통로 위로 파일을 주고받는 scp·rsync, 서버에 HTTP 요청을 던져 응답을 확인하는 curl, 그리고 포트를 여닫는 방화벽 ufw까지요. 끝에는 "도커 컨테이너가 결국 리눅스 셸 위에서 도는 무엇인지"도 한 문단으로 짚어, 다음 과목으로 넘어갈 다리를 놓을 거예요. 그리고 이 모든 명령들을 나중엔 bash 스크립트 하나로 엮어 자동화하게 됩니다. 오늘 연 그 문 너머로, 다음 시간에 한 발 더 들어가요.

과제

오늘 과제는 전부 여러분 자신의 리눅스 환경(WSL2·VM·클라우드)에서 직접 쳐보는 실습이에요. 원격 서버가 없어도 괜찮아요 — 키를 만들고 권한을 확인하는 건 내 컴퓨터에서 다 됩니다. 위험한 명령은 없고, 막혀도 다시 만들거나 지우면 되니 편하게 해보세요.

[기초] 내 컴퓨터의 네트워크 들여다보기

내 환경의 네트워크 상태를 눈으로 확인해보세요.

• ip a로 내 컴퓨터의 IP 주소를 찾아본다(inet으로 시작하는 줄을 보세요).
• ping -c 3 google.com을 쳐서, 응답 시간과 함께 google.com이 어떤 IP로 바뀌는지 확인한다.
• dig +short google.com으로 그 이름에 묶인 IP가 몇 개인지 본다.
• sudo ss -ltnp로 내 컴퓨터가 지금 어떤 포트를 열어두고 있는지 확인한다. 22번이나 다른 포트를 잡은 프로그램이 보이는지 살펴본다.

[응용] 내 SSH 열쇠 만들고 권한·설정까지

원격 접속의 핵심인 키 한 쌍을 직접 만들고, 권한과 설정 파일까지 다뤄보세요.

• ssh-keygen -t ed25519 -C "내메모"로 키 한 쌍을 만든다(연습이니 암호문구는 비워도 된다).
• ls -l ~/.ssh로 id_ed25519(개인키)와 id_ed25519.pub(공개키)의 권한을 확인한다. 개인키가 -rw-------(600), 공개키가 -rw-r--r--(644)인지 눈으로 짚어본다.
• cat ~/.ssh/id_ed25519.pub으로 공개키(자물쇠)의 내용을 한번 본다. ssh-ed25519로 시작하는 한 줄이다.
• ~/.ssh/config 파일을 만들어 Host·HostName·User·IdentityFile을 적어, 가상의 서버에 별명을 붙여본다.

[심화] 원격 서버에 키 인증으로 접속하기 (서버 상황 상상)

서버 상황을 상상해봅시다. "회사에서 운영 서버 한 대를 받았다. 매번 비밀번호 치기 번거롭고 보안도 약하니, 키 인증으로 바꿔 비밀번호 없이 드나들고 싶다." 클라우드 무료 인스턴스나 로컬 VM이 있다면 실제로 해보고, 없다면 단계를 글로 정리해보세요.

• ssh 사용자@서버주소로 일단 비밀번호로 접속해본다(첫 접속의 yes 확인 절차도 경험해본다).
• ssh-copy-id 사용자@서버주소로 내 공개키를 서버에 등록한다.
• 다시 ssh 사용자@서버주소로 접속해, 이번엔 비밀번호를 묻지 않는지 확인한다.
• 접속한 그 원격 셸에서 지난 시간 배운 apt·systemctl·journalctl을 한 번씩 쳐보고, "남의 컴퓨터를 내 컴퓨터처럼 다룬다"는 게 어떤 느낌인지 적어본다. 그리고 "왜 키 인증이 비밀번호보다 안전한지"를 두세 문장으로 정리해본다.

생각해볼 주제

1. 비밀번호 로그인을 아예 꺼버리는 게 더 안전할까

많은 운영 서버가 키 인증을 설정한 뒤 비밀번호 로그인을 통째로 꺼버립니다(키가 있는 사람만 들어올 수 있게). 무차별 대입 공격을 원천 차단할 수 있어 보안이 크게 올라가죠. 그런데 만약 단 하나뿐인 개인키 파일을 잃어버린다면 어떻게 될까요? 비밀번호 로그인을 끄는 것의 보안 이득과, 그로 인해 생기는 위험(열쇠를 잃으면 영영 못 들어감)을 견주어보고, 현업에서 이 위험을 줄이려면 어떤 대비(예: 관리 콘솔, 백업 접속 경로)가 필요할지 생각해보세요.

2. SSH 포트를 22번이 아닌 다른 번호로 바꾸는 건 의미가 있을까

일부 서버 운영자는 SSH 포트를 기본 22번이 아니라 엉뚱한 번호(예: 2222)로 바꿔둡니다. "공격자가 22번만 노릴 테니 번호를 숨기면 덜 공격받는다"는 논리죠. 이게 실제로 보안에 도움이 될까요, 아니면 그저 "숨겼다는 착각"일 뿐일까요? 포트를 바꾸는 것이 막아주는 공격과 막지 못하는 공격을 구분해보고, 진짜 보안(키 인증·방화벽)과 "숨기기"가 어떻게 다른지 생각해보세요.

3. 이름(DNS)이 IP보다 편한데 왜 설정 파일엔 IP를 직접 적어두기도 할까

우리는 사람이 외우기 쉬운 이름(myserver·api.example.com)을 두고도, 어떤 서버 설정에는 IP 주소를 직접 적어두기도 합니다. 이름이 분명 더 편한데 왜 그럴까요? DNS가 "이름 → IP"를 찾아주는 과정이 한 단계 더 끼는 것이 어떤 상황에서 문제가 될 수 있는지(예: DNS 자체가 응답 안 할 때, 이름이 가리키는 IP가 바뀔 때), 그리고 이름과 IP 중 무엇을 쓸지가 "편함"과 "확실함" 사이의 선택임을 생각해보세요.