같은 네트워크에서 project-dev-server 사용 준비

핵심 요약

이전 글에서는 사용하지 않던 컴퓨터에 Ubuntu Server를 설치하고, 서버 이름을 project-dev-server, 사용자 이름을 apple2ne1로 설정했습니다. 이번 글에서는 집이나 사무실의 같은 네트워크에 연결된 Windows 11 PC에서 이 서버에 SSH로 접속하는 방법을 알아봅니다.

처음에는 사용자 이름과 비밀번호로 접속하고, 연결을 확인한 뒤 SSH 공개 키를 서버에 등록합니다. 마지막에는 긴 IP 주소 대신 ssh project-dev-server라는 짧은 명령으로 접속할 수 있게 만들고, 서버 IP 고정과 UFW 방화벽 설정까지 진행합니다.

앞으로의 작업 위치 이 글을 마친 뒤에는 서버 앞에 앉아서 직접 작업하기보다, 같은 네트워크에 있는 Windows 11 PC에서 SSH로 접속한 후 대부분의 서버 작업을 진행합니다.

이 글이 필요한 경우

• Ubuntu Server 설치를 끝냈지만 다른 PC에서 접속하는 방법을 모르는 경우
• 서버의 IP 주소와 SSH 포트가 무엇인지 알고 싶은 경우
• 매번 비밀번호를 입력하지 않고 SSH 키로 접속하고 싶은 경우
• IP 주소 대신 기억하기 쉬운 별칭으로 접속하고 싶은 경우
• 서버 IP를 고정하고 UFW 방화벽을 설정하려는 경우
• 명령을 서버에서 실행해야 하는지 Windows PC에서 실행해야 하는지 헷갈리는 경우

시작하기 전에

이번 글에서는 다음 용어를 사용합니다.

이 글에서 사용하는 설정값은 다음과 같습니다.

다음 호스트 이름, 사용자 이름과 IP 주소는 예시가 아니라 이 글을 작성하고 검증할 때 사용한 실제 환경값입니다. 실제 암호와 인증정보는 기록하지 않습니다.

비밀번호 보안 주의 블로그에는 실제 비밀번호를 적지 않습니다. xxxxxxxx 같은 표시는 예시일 뿐이며, 명령에도 비밀번호를 직접 넣지 않습니다. 비밀번호 입력 요청이 나타날 때만 키보드로 입력합니다. Linux 터미널에서는 비밀번호를 입력해도 화면에 글자나 별표가 표시되지 않지만 실제로는 입력되고 있습니다.

검증 환경

• 서버 운영체제: Ubuntu Server 26.04 LTS
• 호스트 이름: project-dev-server
• 사용자 이름: apple2ne1
• 서버 IP 주소: 192.168.1.231
• Windows 관리 PC: Windows 11, IP 주소 192.168.1.240
• SSH: OpenSSH, 기본 포트 22
• 네트워크 예시: 192.168.1.0/24
• 작성 및 확인 기준일: 2026년 7월 17일

1. 같은 네트워크에 있다는 것은 무엇일까?

같은 네트워크에 있다는 것은 두 컴퓨터가 같은 공유기나 같은 내부망에 연결되어 서로 직접 통신할 수 있는 상태를 말합니다.

예를 들어 다음 두 IP 주소를 살펴보겠습니다.

• project-dev-server: 192.168.1.231
• Windows PC: 192.168.1.240

두 주소는 앞부분인 192.168.1이 같습니다. 일반적인 가정용 공유기에서 서브넷 마스크가 /24, 즉 255.255.255.0이라면 두 장치는 같은 내부 네트워크에 있다고 볼 수 있습니다.

이 글에서는 설명을 쉽게 하기 위해 같은 네트워크에 있는 PC를 Windows 관리 PC라고 부르겠습니다. 반대로 외부 장소처럼 다른 네트워크에 있는 PC는 외부 PC라고 부르겠습니다.

같은 네트워크에서는 내부 IP 주소로 바로 접속할 수 있습니다. 그러나 외부 PC에서 192.168.1.231로 접속할 수는 없습니다. 192.168.x.x 주소는 집이나 사무실 내부에서만 사용하는 사설 IP이기 때문입니다. 외부 PC 연결은 포트 포워딩, VPN 또는 Tailscale 같은 별도의 구성이 필요하며 후속 글에서 다루겠습니다.

같은 네트워크인지 간단히 확인하기

Windows PowerShell에서 다음 명령을 실행합니다.

ipconfig

서버에서는 다음 명령으로 IP 주소를 확인합니다.

hostname -I

출력에 192.168.1.231이 보이고 Windows 관리 PC도 192.168.1.240 형태라면 같은 네트워크일 가능성이 큽니다.

Windows 관리 PC에서 서버에 신호가 도착하는지 확인하려면 다음 명령을 실행합니다.

ping 192.168.1.231

응답이 오면 기본적인 네트워크 연결은 정상입니다. 다만 방화벽이 ping 응답을 막을 수도 있으므로, ping이 실패했다고 해서 반드시 SSH 접속도 실패하는 것은 아닙니다.

위 화면의 192.168.1.117은 연결 실패를 보여 주기 위한 별도 예시 주소입니다. 대상 장치가 꺼져 있거나, IP 주소가 변경되었거나, 같은 네트워크에 연결되어 있지 않을 때 이와 비슷한 결과가 나타날 수 있습니다.

2. 서버 IP 주소와 sudo 명령 이해하기

Ubuntu Server를 설치할 때 네트워크 화면에서 확인한 서버 IP 주소는 192.168.1.231입니다. 설치할 때 이 주소를 기록하지 않았다면 서버에 직접 로그인한 후 다음 명령으로 다시 확인할 수 있습니다.

서버 콘솔에서 실행

hostname -I

조금 더 자세히 확인하려면 다음 명령을 사용합니다.

ip -br address

기본 Gateway와 네트워크 장치 이름도 함께 확인하려면 다음 명령을 실행합니다.

ip route

나타나는 정보는 다음과 같습니다.

• 사용자 이름: apple2ne1
• 서버 이름: project-dev-server
• IP 주소: 192.168.1.231
• 기본 Gateway : 192.168.1.1
• 유선 장치 이름 : eno1 (장치 이름은 enp3s0, 또는 eth0 로 나타날 수 있습니다.)

장치 이름과 Gateway 주소는 컴퓨터와 공유기에 따라 달라지므로 실제 출력값을 기록해 둡니다.

sudo 그룹이란?

Linux에는 일반 사용자와 시스템 전체를 관리할 수 있는 관리자 권한이 구분되어 있습니다. Ubuntu에서는 root 계정으로 직접 로그인하여 모든 작업을 하는 대신, 허가된 일반 사용자가 필요한 순간에만 sudo 명령으로 관리자 권한을 사용하도록 합니다.

설치할 때 만든 apple2ne1 사용자는 일반적으로 sudo 그룹에 포함됩니다. 현재 사용자가 어떤 그룹에 속해 있는지 확인하려면 다음 명령을 실행합니다.

groups

출력에 sudo가 포함되어 있다면 apple2ne1 사용자는 필요한 명령에 sudo를 붙여 관리자 권한으로 실행할 수 있습니다.

apple2ne1 sudo

여기서 관리자 작업은 일반 사용자가 임의로 변경할 수 없는 시스템 전체의 설정과 자원을 다루는 작업을 뜻합니다. 대표적인 예는 다음과 같습니다.

• apt를 이용한 프로그램 설치, 업데이트와 삭제
• /etc 아래의 SSH, 네트워크와 서비스 설정 파일 수정
• systemctl을 이용한 시스템 서비스 시작, 중지와 재시작
• UFW 방화벽 규칙 추가와 활성화
• 사용자 계정과 그룹 생성, 수정과 삭제
• 시스템 파일의 소유자와 권한 변경
• Disk와 Partition Mount 또는 Storage 설정
• 서버 종료와 재부팅
• 다른 사용자의 파일이나 root 전용 파일 확인 및 변경

이러한 작업은 시스템 전체에 영향을 줄 수 있으므로 Ubuntu는 일반 명령과 관리자 명령을 구분합니다. apple2ne1 사용자가 sudo 그룹에 포함되어 있더라도 모든 명령이 항상 관리자 권한으로 실행되는 것은 아닙니다. 관리자 권한이 필요한 명령 앞에 sudo를 붙였을 때만 해당 명령을 높은 권한으로 실행합니다.

sudo에서 어떤 비밀번호를 입력해야 할까?

Ubuntu Server를 설치할 때 만든 apple2ne1 계정에는 로그인할 때 사용하는 비밀번호가 있습니다. 다음처럼 sudo가 붙은 명령을 실행하면 Ubuntu는 현재 명령을 실행하는 사용자가 정말 apple2ne1인지 확인하기 위해 apple2ne1 계정의 비밀번호를 요구합니다.

sudo apt update

이때 root 계정의 비밀번호를 입력하라는 의미가 아닙니다. 로그인할 때 사용하는 apple2ne1의 비밀번호를 입력하면 됩니다. 터미널에서 비밀번호를 입력해도 문자나 *가 화면에 나타나지 않지만 입력은 정상적으로 처리됩니다.

Ubuntu는 기본 설치에서 root 계정으로 직접 로그인하는 방식보다 sudo 사용을 권장합니다. 일반적으로 root 계정은 암호 로그인이 잠긴 상태이므로 root 비밀번호를 따로 만들 필요가 없습니다. apple2ne1이 sudo 그룹에 포함되어 있으면 필요한 관리자 작업을 수행할 수 있습니다.

root 비밀번호를 별도로 만들고 root 계정으로 직접 로그인하면 모든 명령이 제한 없이 관리자 권한으로 실행됩니다. 이 상태에서는 명령이나 경로를 잘못 입력했을 때 시스템 파일을 변경하거나 삭제할 위험이 커지고, 누가 어떤 관리자 명령을 실행했는지 구분하기도 어려워집니다. 따라서 이 연재에서는 root 비밀번호를 만들거나 root로 직접 로그인하지 않고, 필요한 명령에만 sudo를 사용합니다.

sudo를 사용해 서버 끄기

sudo shutdown -h now

또는 다음 명령을 사용할 수 있습니다.

sudo poweroff

sudo를 사용해 서버 다시 시작하기

sudo reboot

이 명령들은 시스템 전체에 영향을 주기 때문에 관리자 권한이 필요합니다. 그래서 명령 앞에 sudo가 붙습니다.

주의 SSH로 접속한 상태에서 sudo reboot를 실행하면 SSH 연결은 즉시 끊어집니다. 고장이 아니라 서버가 재부팅되면서 발생하는 정상적인 동작입니다. 서버 부팅이 완료될 때까지 기다린 뒤 다시 SSH로 접속합니다.

3. Ubuntu Server에 설치한 SSH란?

SSH는 Secure Shell의 약자입니다. 네트워크를 통해 다른 컴퓨터의 터미널에 안전하게 접속하는 통신 방식입니다.

이전 설치 과정에서 Install OpenSSH server를 선택했기 때문에 project-dev-server에는 SSH 연결을 받아 주는 OpenSSH Server가 설치되어 있습니다. Ubuntu의 sshd 서비스는 백그라운드에서 실행되며 접속 요청을 기다립니다. 따라서 서버가 부팅되면 콘솔에 로그인하지 않아도 SSH 접속을 받을 수 있습니다.

SSH를 사용하면 다음 작업을 할 수 있습니다.

• Windows 관리 PC에서 Ubuntu 서버 명령 실행
• 서버의 파일과 폴더 확인
• 서버의 프로그램 설치와 설정 변경
• scp 또는 sftp를 이용하여 파일 전송 또는 받기
• VS Code Remote SSH를 이용한 서버 프로젝트 편집
• 서버의 로그 확인과 서비스 재시작

SSH는 접속 내용과 인증 정보를 암호화합니다. 과거에 원격 터미널 접속에 사용하던 Telnet은 사용자가 입력한 명령 및 서버 응답을 암호화하지 않고 평문으로 전송해서 안전하지 않았습니다.

SSH의 두 구성 요소

대표적인 SSH 프로그램

• Windows 터미널과 PowerShell: Windows 10/11에서 OpenSSH Client를 사용할 수 있음
• PuTTY: Windows에서 오래 사용된 무료 SSH 프로그램
• WinSCP: Windows에서 서버 파일을 그래픽 화면으로 전송하고 관리하는 프로그램
• VS Code Remote – SSH: VS Code에서 서버 폴더를 열고 편집할 수 있는 확장 기능

Windows에서 Command Prompt 열기

가장 쉬운 방법은 Windows 작업 표시줄의 시작 버튼을 누르고 cmd 또는 Command Prompt를 검색한 뒤 Command Prompt를 선택하는 것입니다.

키보드에서 Windows + R을 눌러 실행 창을 열고 다음 명령을 입력한 뒤 Enter를 눌러도 됩니다.

cmd

Command Prompt가 열리면 일반적으로 다음과 같이 현재 Windows 사용자 폴더가 프롬프트에 표시됩니다.

현재_사용자_폴더>

Windows에서 PowerShell 열기

Windows 작업 표시줄의 시작 버튼을 누르고 PowerShell을 검색한 뒤 Windows PowerShell을 선택합니다.

Windows + R로 실행 창을 열고 다음 명령을 입력해도 됩니다.

powershell

Windows 터미널이 설치되어 있다면 시작 메뉴에서 터미널을 검색해 실행한 뒤, Tab 메뉴에서 Windows PowerShell 또는 PowerShell Profile을 선택할 수도 있습니다.

이 문서에서 SSH 버전을 확인하거나 서버에 접속하는 명령은 관리자 권한이 필요하지 않습니다. 따라서 관리자 권한으로 실행을 선택하지 않고 일반 사용자 권한으로 Command Prompt 또는 PowerShell을 열어도 됩니다.

Windows에서 SSH Client가 준비되어 있는지 확인하려면 PowerShell에서 다음 명령을 실행합니다.

ssh -V

버전 정보가 표시되면 OpenSSH Client를 바로 사용할 수 있습니다. Windows 10과 Windows 11에서는 OpenSSH Client가 선택적 Windows 기능이므로 설치 상태가 환경마다 다를 수 있습니다.

ssh 명령을 찾을 수 없다면 설정 → 시스템 → 선택적 기능에서 OpenSSH Client의 설치 여부를 확인하고, 설치 후 새 PowerShell 창에서 ssh -V를 다시 실행합니다.

서버의 SSH 서비스 확인

Ubuntu Server를 설치할 때 OpenSSH Server를 선택했더라도 현재 서비스가 실행 중인지 다음 명령으로 확인합니다.

sudo systemctl status ssh

active (running)이 표시되면 OpenSSH Server가 실행 중입니다.

4. SSH 포트 확인

SSH 접속에는 서버 IP 주소, 포트 번호와 사용자 이름이 필요합니다. OpenSSH Server의 기본 포트는 22이므로 이 글에서는 다음 명령으로 접속합니다.

ssh apple2ne1@192.168.1.231

서버에서 SSH가 22번 포트의 연결을 기다리는지 확인합니다.

sudo ss -tlnp | grep ':22'

IP 주소와 포트의 차이, 포트 번호 범위와 변경 시 주의 사항은 SSH 포트의 개념과 확인 방법에서 자세히 설명합니다.

5. Windows 관리 PC에서 project-dev-server에 처음 연결하기

Windows 관리 PC의 Windows PowerShell에서 실행

ssh apple2ne1@192.168.1.231

별도로 SSH 설정을 바꾸지 않았다면 기본 포트가 22이므로 포트 번호를 생략할 수 있습니다.

포트를 명시하려면 다음과 같이 입력합니다.

ssh -p 22 apple2ne1@192.168.1.231

처음 접속하면 다음과 비슷한 메시지가 나타날 수 있습니다.

The authenticity of host '192.168.1.231' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

서버의 Host Key 지문을 확인한 뒤 일치하면 다음을 입력합니다.

yes

그다음 apple2ne1 사용자의 비밀번호를 입력합니다. 입력 중에는 화면에 아무것도 표시되지 않습니다. 입력을 마친 뒤 Enter를 누릅니다.

로그인 후 다음처럼 프롬프트가 나타나면 접속에 성공한 것입니다.

apple2ne1@project-dev-server:~$

로그인 화면이 떠 있어도 SSH 연결이 가능한 이유

서버가 다시 시작되면 서버 모니터에는 사용자 이름을 입력하라는 로그인 화면이 나타납니다. 그렇더라도 SSH 서비스인 sshd는 운영체제의 백그라운드에서 실행되고 있습니다.

여기서 백그라운드 실행이란 프로그램 화면을 직접 열어 놓지 않아도 운영체제 뒤에서 계속 동작하는 것을 말합니다. 따라서 서버 모니터의 로그인 화면에 아무것도 입력하지 않은 상태에서도 Windows 관리 PC에서 SSH로 접속할 수 있습니다.

재부팅 후 백그라운드 연결 시험

먼저 SSH로 연결된 서버 터미널에서 다음 명령을 실행합니다.

sudo reboot

SSH 연결이 끊어지면 약간 기다린 뒤 Windows 관리 PC에서 다음 명령으로 서버의 응답을 확인합니다.

ping 192.168.1.231

Windows에서는 ping을 중지할 때 Ctrl + C를 누릅니다.

서버가 응답하기 시작하면 다시 SSH로 접속합니다.

ssh apple2ne1@192.168.1.231

로그인 화면을 직접 조작하지 않았는데도 접속된다면 SSH 서비스가 백그라운드에서 정상적으로 시작된 것입니다.

## 앞으로 명령을 실행할 기본 위치

>

특별히 서버 콘솔에서 실행이라고 표시하지 않는 한, 앞으로의 서버 명령은 Windows 관리 PC에서 다음 명령으로 접속한 뒤 실행합니다.

>

“bash ssh apple2ne1@192.168.1.231 “

>

즉, Windows PC의 키보드와 화면을 사용하지만 실제 명령은 project-dev-server에서 실행됩니다.

6. 서버에서 사용할 기본 Linux 명령

SSH 접속 후 다음 프롬프트가 표시되면 project-dev-server에서 명령을 실행하는 상태입니다.

apple2ne1@project-dev-server:~$

이 문서에서는 현재 위치 확인과 폴더 이동에 다음 명령을 사용합니다.

pwd
ls -la
cd ~

pwd, ls, cd, 홈 폴더, 루트 폴더와 주요 Linux 폴더 구조를 더 자세히 학습하려면 추가학습 Category의 Linux 기본 명령어를 참조하세요. 파일 소유권과 접근 권한은 Linux Directory 권한을 함께 참고합니다.

7. SSH 공개 키 인증 준비

SSH 공개 키 인증의 목적은 서버에 접속할 시 비밀번호 입력없이 접속하기 위해서입니다. SSH 공개 키 인증 준비란 사용자의 PC 에 있는 공개 키를 접속할 서버에 넣는 것입니다.

사용자 Windows PC 에 있는 두쌍의 키 중 확장자가 .pub 으로 되어 있는 키를 서버의 ~/.ssh/authorized_keys file 안에 넣는 것이 등록입니다. 이것은 서버가 사용자 PC 의 신원을 확인하는 절차입니다.

이것과 별도로 사용자 PC 는 Server 에 접속을 하게되면 서버가 가지고 있는 Host Key 와 ip 를 사용자 PC 의 known_hosts 에 저장에 두어, 이후에 그 ip 로 접속할 때 서버의 Host Key 가 다르면, 다른 서버라 판단하고 메세지를 출력하게 됩니다. 이것은 사용자 PC 가 서버의 신원을 확인하는 절차입니다.

두 키 체계의 저장 위치와 인증 순서는 SSH 공개 키 인증과 Host Key의 차이에서 자세히 설명합니다.

8. Windows 관리 PC의 공개 키와 지문 확인

8-1 Windows 관리 PC에 공개 키가 이미 있는지 확인

서버에 넣어줄 공개키가 있는지 확인하고, 없으면 만들어야 합니다. 새 키를 만들거나 등록하기 전에 Windows 관리 PC에 기존 키가 있는지, 그 공개 키가 project-dev-server에 이미 등록되어 있는지 먼저 확인합니다. 기존 키를 확인하지 않고 같은 파일명으로 새로 만들면 다른 서버 접속에 사용하던 키를 덮어쓸 수 있습니다.

Windows PowerShell에서 실행합니다.

cd $HOME\.ssh
ls

사용자 홈 폴더에 있는 .ssh 폴더안에 키가 있는지 확인합니다.

다음 한쌍의 파일이 함께 있다면 Ed25519 키가 이미 생성되어 있습니다.

id_ed25519
id_ed25519.pub

공개 키 내용 간단히 보기

Windows PowerShell .ssh 폴더 에서 실행합니다.

type id_ed25519.pub

공개 키 한 줄은 보통 ssh-ed25519로 시작합니다. .pub가 없는 개인 키 파일은 화면에 출력하거나 서버로 보내거나 블로그에 공개하면 안 됩니다.

공개 키 지문 보기

Windows PowerShell .ssh 폴더 에서 실행합니다.

ssh-keygen -lf id_ed25519.pub

8-2. 키가 없다면 Windows 관리 PC에서 새로 만들기

Windows PowerShell에서 실행합니다.

ssh-keygen -t ed25519 -C "원하는 문구 삽입"

다음 질문이 나타나면 기본 위치를 사용하기 위해 Enter를 누릅니다.

Enter file in which to save the key (.../.ssh/id_ed25519):

이어서 개인 키를 보호할 Passphrase를 설정할 수 있습니다. Passphrase를 사용하면 개인 키 파일이 유출되더라도 바로 악용하기 어렵습니다. 자동화처럼 명확한 이유가 없다면 Passphrase를 설정하는 편이 안전하며, 설정하지 않을 때는 위험을 이해한 뒤 빈 값으로 진행합니다.

같은 이름의 키가 이미 있다는 경고가 나타나면 기존 키를 덮어쓰지 말고 n을 입력합니다. 기존 키를 덮어쓰면 해당 키를 사용하던 다른 서버에 접속하지 못할 수 있습니다. 기존 키가 없다는 것을 확인한 경우에만 기본 파일명에서 Enter를 눌러 새 키를 만듭니다.

키 생성이 끝나면 다음 파일이 만들어집니다.

id_ed25519       ← 개인 키, Windows 관리 PC 에만 보관
id_ed25519.pub   ← 공개 키, 서버에 전송해 값을 등록

8-3 project-dev-server에 공개 키가 등록되어 있는지 확인

ssh apple2ne1@192.168.1.231

서버 계정 비밀번호를 묻는다면 현재 공개 키 인증이 사용되지 않은 상태일 수 있습니다. 키가 등록되지 않았거나, 키 파일을 찾지 못했거나, 서버가 해당 키를 거부한 경우를 함께 확인합니다.

서버 확인을 마치면 다음 명령으로 접속을 종료하고 Windows PowerShell로 돌아옵니다.

exit

9. Windows 관리 PC의 공개 키를 project-dev-server 에 등록하기

9-1. 서버에 .ssh 디렉터리와 authorized_keys 준비하기

먼저 Windows PowerShell에서 서버에 접속합니다.

ssh apple2ne1@192.168.1.231

서버에서 다음 명령을 실행하여 .ssh 디렉터리가 있는지 확인합니다.

ls -la ~

목록에 .ssh가 있으면 새로 만들 필요가 없습니다. .ssh가 없더라도 다음 명령은 안전하게 실행할 수 있습니다.

mkdir -p ~/.ssh

-p 옵션을 사용하면 .ssh 디렉터리가 없을 때는 새로 만들고, 이미 있을 때는 오류 없이 그대로 둡니다.

이어서 SSH Key를 안전하게 보관할 수 있도록 권한을 설정하고 authorized_keys 파일을 준비합니다.

chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

각 명령의 역할은 다음과 같습니다.

• chmod 700 ~/.ssh: 해당 사용자만 .ssh 디렉터리에 접근할 수 있게 합니다.
• touch ~/.ssh/authorized_keys: 파일이 없으면 새로 만들고, 이미 있으면 그대로 둡니다.
• chmod 600 ~/.ssh/authorized_keys: 해당 사용자만 파일을 읽고 수정할 수 있게 합니다.

준비가 끝났으면 서버 접속을 종료합니다.

exit

9-2. Windows 관리 PC의 공개 키를 authorized_keys에 등록하기

Windows PowerShell에서 다음 명령을 실행합니다.

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh apple2ne1@192.168.1.231 "cat >> ~/.ssh/authorized_keys"

이 명령은 다음 순서로 작동합니다.

1. Windows 관리 PC의 id_ed25519.pub 공개 키 내용을 읽습니다.
2. SSH를 통해 공개 키를 project-dev-server로 보냅니다.
3. 서버의 ~/.ssh/authorized_keys 파일 끝에 공개 키를 추가합니다.

명령을 실행하면 아직 키 등록 전이므로 서버 사용자의 비밀번호를 한 번 입력해야 합니다.

9-3. 공개 키가 등록되었는지 확인하기

다시 서버에 접속합니다.

ssh apple2ne1@192.168.1.231

공개 키 인증이 정상적으로 적용되면 서버 계정 비밀번호를 묻지 않고 접속됩니다. 키에 Passphrase를 설정했다면 개인 키의 Passphrase는 요구할 수 있습니다.

확인하기 위해 서버에서 다음 명령을 실행합니다.

cat ~/.ssh/authorized_keys

ssh-ed25519로 시작하는 Windows 관리 PC의 공개 키가 표시되면 등록된 것입니다.

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... Net-PC

확인을 마쳤으면 접속을 종료합니다.

exit

이제 다시 접속하여 비밀번호 없이 로그인되는지 확인합니다.

ssh apple2ne1@192.168.1.231

서버 계정 비밀번호를 묻지 않고 접속되면 키 인증이 정상적으로 작동하는 것입니다. 키를 만들 때 Passphrase를 지정했다면 서버 비밀번호 대신 그 키의 Passphrase를 물을 수 있습니다.

키 인증의 차이점 비밀번호 접속은 서버 비밀번호를 네트워크 접속 때마다 사용합니다. 키 인증은 Windows 관리 PC의 개인 키와 서버에 등록된 공개 키가 서로 맞는지 확인합니다. 따라서 자동화와 원격 개발에 편리하고, 추측 가능한 비밀번호를 반복 공격하는 위험도 줄일 수 있습니다.

10. Host Key 지문을 확인하고 known_hosts에 등록하기

공개 키를 authorized_keys에 넣는 작업과 서버 지문을 등록하는 작업은 서로 다릅니다.

• authorized_keys: 서버가 어떤 Windows 관리 PC 사용자의 접속을 허용할지 판단
• known_hosts: Windows 관리 PC가 지금 접속한 서버가 이전에 알던 서버와 같은지 판단

Windows 관리 PC의 저장 위치는 다음과 같습니다.

처음 SSH 접속할 때 yes를 입력했다면 Host Key는 이미 known_hosts에 자동 등록되어 있습니다.

등록 여부 확인

Windows PowerShell에서 실행합니다.

ssh-keygen -F 192.168.1.231

결과가 표시되면 해당 서버 정보가 등록되어 있습니다.

여러 값이 나오는 것은 같은 서버 IP에 서로 다른 종류의 SSH 호스트 공개키가 저장되어 있기 때문입니다.

화면에는 다음 세 가지 키가 있습니다.

• ssh-ed25519 — 최신 방식의 SSH 키
• ssh-rsa — RSA 방식의 SSH 키
• ecdsa-sha2-nistp256 — ECDSA 방식의 SSH 키

ssh-keygen -F 192.168.1.231 명령은 Windows PC의 known_hosts 파일에서 해당 IP와 관련된 기록을 모두 찾아서 보여줍니다.

line 33 → ED25519 키
line 34 → RSA 키
line 35 → ECDSA 키

이는 보통 정상입니다. SSH 서버는 여러 키 형식을 가지고 있으며, 클라이언트가 접속할 때 지원되는 방식 중 하나를 선택합니다.

확실하게 비교한 뒤 수동 등록하기

먼저 서버 콘솔에서 실제 Host Key 지문을 확인합니다.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

그 값을 별도로 기록하고, Windows 관리 PC에서 다음 명령으로 서버가 제시하는 공개 키의 지문을 확인합니다.

ssh-keyscan -t ed25519 192.168.1.231 2>$null | ssh-keygen -lf -

두 SHA256 값이 일치하는지 확인한 뒤 Host Key를 known_hosts에 추가합니다.

Windows PowerShell:

ssh-keyscan -H -t ed25519 192.168.1.231 | Out-File -Append -Encoding ascii $HOME\.ssh\known_hosts

중요 ssh-keyscan 결과를 비교하지 않고 바로 등록하면, 그 순간 응답한 장치가 정말 내 서버인지 확인한 것이 아닙니다. 서버 콘솔에서 확인한 지문와 먼저 비교해야 합니다. -Append는 기존 내용을 검사하지 않고 새 줄을 계속 추가합니다. 따라서 반복 실행하면 같은 서버의 같은 키가 중복 저장될 수 있습니다.

서버를 다시 설치했거나 SSH Host Key가 바뀌면 “REMOTE HOST IDENTIFICATION HAS CHANGED” 경고가 나타날 수 있습니다. 실제로 서버를 다시 설치한 것이 맞는지 확인한 후 이전 기록을 지웁니다.

ssh-keygen -R 192.168.1.231

11. 서버 IP 주소 또는 Host Key가 바뀌었을 때

Windows 관리 PC는 접속한 서버의 Host Key를 서버 IP 주소와 함께 $HOME\.ssh\known_hosts에 저장합니다. 이후 같은 IP 주소로 접속했을 때 서버가 다른 Host Key를 제시하면 SSH는 서버 신원이 바뀌었다고 판단하고 연결을 중단합니다.

대표적인 경고는 다음과 같습니다.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Offending ECDSA key in $HOME\.ssh\known_hosts:27

위 예시는 known_hosts의 27번째 줄에 저장된 이전 Host Key와 현재 서버가 제시한 Host Key가 일치하지 않는다는 뜻입니다. 다음과 같은 경우에 발생할 수 있습니다.

• Ubuntu 서버를 다시 설치하여 Host Key가 바뀐 경우
• OpenSSH를 다시 설치했거나 Host Key를 새로 생성한 경우
• 같은 IP 주소를 이전과 다른 서버가 사용하게 된 경우
• 중간자 공격이나 잘못된 네트워크 연결로 다른 장치가 응답한 경우

1단계: 서버 콘솔에서 현재 Host Key 지문 확인

서버에 모니터와 키보드를 직접 연결한 서버 콘솔 또는 이미 신뢰한 별도 연결에서 실행합니다.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

표시된 SHA256:... 지문을 별도로 기록합니다.

2단계: Windows 관리 PC에서 서버가 제시하는 지문 비교

Windows PowerShell에서 실행합니다.

ssh-keyscan -t ed25519 192.168.1.231 2>$null | ssh-keygen -lf -

서버 콘솔에서 확인한 지문과 Windows 관리 PC에 표시된 지문이 정확히 일치할 때만 다음 단계로 진행합니다. 일치하지 않으면 기존 기록을 삭제하거나 접속을 승인하지 말고 IP 주소, 네트워크 연결과 접속 대상 서버를 다시 확인합니다.

3단계: 확인된 이전 Host Key 기록 제거

두 지문이 일치하고 서버를 다시 설치하거나 Host Key를 변경한 사실도 확인했다면 Windows PowerShell에서 실행합니다.

ssh-keygen -R 192.168.1.231

ssh-keygen -R은 지정한 호스트와 관련된 기존 키를 known_hosts에서 제거하고 원본 파일의 백업을 만듭니다.

4단계: 다시 접속하고 새 Host Key 등록

ssh -p 22 apple2ne1@192.168.1.231

다시 표시된 지문이 앞에서 확인한 값과 같을 때만 yes를 입력합니다.

이 오류는 비밀번호 오류나 포트 연결 실패와 다릅니다. 서버의 SSH 포트까지는 연결되었지만 이전에 저장한 서버 신원과 현재 신원이 달라서 SSH가 보안상 연결을 중단한 상태입니다. 자세한 원리는 REMOTE HOST IDENTIFICATION HAS CHANGED 경고 이해와 해결을 참조합니다.

12. 별칭으로 간편하게 SSH 접속하기

지금까지는 접속할 때마다 사용자 이름과 IP 주소를 입력했습니다.

ssh apple2ne1@192.168.1.231

SSH Client의 config 파일에 정보를 저장하면 다음처럼 짧게 접속할 수 있습니다.

ssh project-dev-server

SSH config 파일 위치

Windows에서 config 파일 열기

PowerShell에서 실행합니다.

notepad $HOME\.ssh\config

파일이 없다는 안내가 나타나면 새 파일을 만들도록 선택합니다.

다음 내용을 입력합니다.

Host project-dev-server
    HostName 192.168.1.231
    User apple2ne1
    Port 22
    IdentityFile ~/.ssh/id_ed25519

각 항목의 의미는 다음과 같습니다.

별칭 접속 시험

Windows PowerShell에서 실행합니다.

ssh project-dev-server

이제 IP 주소와 사용자 이름을 매번 입력하지 않아도 됩니다.

선택 사항: WinSCP 사용

그래픽 화면에서 Windows와 Linux 서버 사이의 파일을 전송하려면 SFTP를 지원하는 WinSCP를 사용할 수 있습니다. 설치, 공개 키 인증, Host Key 확인과 안전한 파일 전송 방법은 WinSCP 설치와 SFTP 연결 방법에서 설명합니다.

13. project-dev-server IP 주소 고정하기

현재 192.168.1.231 주소를 공유기의 DHCP 기능으로 자동 배정받았다면, 공유기나 서버를 다시 시작한 뒤 다른 주소로 바뀔 수 있습니다. IP가 바뀌면 SSH config, WinSCP, VS Code 설정에 저장한 주소도 모두 맞지 않게 됩니다.

따라서 서버는 항상 192.168.1.231을 사용하도록 고정하는 것이 편리합니다.

가장 먼저 확인할 사항

고정 IP를 설정하기 전에 다음을 확인합니다.

1. 공유기의 LAN 주소와 Gateway가 정말 192.168.1.1인지 확인합니다.
2. 공유기의 DHCP 배정 범위에서 192.168.1.231을 제외하거나 예약합니다.
3. 다른 장치가 192.168.1.231을 사용하지 않는지 확인합니다.
4. 서버의 실제 네트워크 인터페이스 이름을 확인합니다.

IP 충돌이 생기면 서버뿐 아니라 같은 주소를 사용하는 다른 장치도 네트워크 연결이 불안정해질 수 있습니다.

방법 1: 공유기에서 DHCP Reservation 사용

가능하면 공유기 관리자 화면에서 서버의 MAC 주소에 192.168.1.231을 예약하는 방법이 가장 간단합니다. 서버는 DHCP를 그대로 사용하지만 공유기가 항상 같은 IP를 배정합니다.

서버의 MAC 주소는 다음 명령으로 확인합니다.

ip -br link

ip link show | grep link/ether

ip link

공유기마다 메뉴 이름은 DHCP Reservation, Address Reservation, Static Lease 등으로 다릅니다.

방법 2: Ubuntu Server의 Netplan 파일 수정

공유기에서 예약하기 어렵다면 Ubuntu Server의 Netplan 설정을 수정합니다.

연결 끊김 주의 네트워크 설정을 잘못 바꾸면 SSH가 끊어질 수 있습니다. 처음 설정할 때는 가능하면 서버에 모니터와 키보드를 연결해 두고 진행합니다. netplan apply보다 되돌리기 기능이 있는 netplan try를 먼저 사용합니다.

1단계: 현재 값 확인

다음 명령으로 현재 네트워크 인터페이스 이름, IP 주소와 기본 경로를 확인합니다.

ip -br address
ip route

위 화면에서 인터페이스 장치 eno1을 기록해 둡니다. 인터페이스 이름이 enp3s0 으로 나올 수도 있습니다.

2단계: 기존 파일 백업

IP 주소를 고정하기 전에 실제 Netplan 설정 파일 이름을 확인합니다.

ls /etc/netplan/

이 예시에서는 설정 파일 이름이 00-installer-config.yaml이므로 수정 전에 같은 이름을 사용해 백업합니다.

sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.backup

설정 파일 이름이 다르면 위 명령의 파일 이름도 바꿉니다.

3단계: Netplan 파일 열기

서버에 설치된 Nano 편집기로 설정 파일을 엽니다. 편집을 마치면 Ctrl+O, Enter, Ctrl+X 순서로 저장하고 종료합니다.

sudo nano /etc/netplan/00-installer-config.yaml

4단계: 고정 IP 내용 입력

인터페이스가 eno1이고 게이트웨이가 192.168.1.1인 경우의 예시입니다. xx:xx:xx:xx:xx:xx는 ip -br link로 확인한 실제 MAC 주소로 바꿉니다.

network:
  version: 2
  ethernets:
    eno1:
      dhcp4: false
      match:
        macaddress: "xx:xx:xx:xx:xx:xx"
      set-name: eno1
      addresses:
        - 192.168.1.231/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

인터페이스가 enp3s0이고 게이트웨이가 192.168.1.1인 경우의 예시입니다.

network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: false
      addresses:
        - 192.168.1.231/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

YAML 파일은 들여쓰기가 문법의 일부입니다. 탭을 사용하지 말고 공백을 사용합니다.

파일 권한을 정리합니다.

sudo chmod 600 /etc/netplan/00-installer-config.yaml

5단계: 문법 확인

sudo netplan generate

오류가 없다면 다음 단계로 진행합니다.

6단계: 되돌리기 가능한 시험 적용

sudo netplan try

연결이 정상이라면 안내된 시간 안에 Enter를 눌러 설정을 확정합니다. 확인하지 못하면 Netplan이 이전 설정으로 되돌리려고 시도합니다. 시간 초과나 취소 뒤에는 복원이 완료되었다고 가정하지 말고, 서버 콘솔에서 설정 파일과 ip -br address, ip route 결과를 다시 확인합니다.

7단계: 적용 상태 확인

sudo netplan try에서 제한 시간 안에 Enter를 눌러 설정을 확정했다면 이미 영구 적용된 상태이므로 sudo netplan apply를 다시 실행하지 않습니다. netplan try를 사용하지 않고 별도로 적용해야 하는 경우에만 서버 콘솔에서 다음 명령을 실행합니다.

sudo netplan apply

8단계: 결과 확인

ip -br address
ip route
ping -c 4 192.168.1.1

Windows 관리 PC에서도 다시 접속합니다.

ssh project-dev-server

고정 IP 설정 후에도 192.168.1.231로 접속된다면 정상입니다.

14. 방화벽과 UFW 설정하기

방화벽은 네트워크를 통해 들어오고 나가는 통신을 규칙에 따라 허용하거나 차단합니다. 쉽게 말하면 서버의 포트 앞에서 출입 가능 여부를 확인하는 보안 담당자와 같습니다.

방화벽의 종류

Ubuntu에서는 Linux 커널의 Netfilter 기능을 쉽게 설정하기 위한 도구로 UFW를 사용할 수 있습니다. UFW는 Uncomplicated Firewall의 약자입니다.

현재 UFW 상태 확인

서버에서 실행합니다.

sudo ufw status verbose

처음에는 다음처럼 비활성 상태일 수 있습니다.

Status: inactive

SSH를 허용한 뒤 UFW 활성화하기

현재 목표는 같은 192.168.1.0/24 네트워크의 장치만 서버의 SSH 22번 포트로 접속할 수 있게 하는 것입니다.

규칙을 추가합니다.

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

192.168.1.x 네트워크에 있는 장치가 이 Linux 서버의 TCP 22번 포트로 접속하는 것을 허용합니다.

그다음 UFW를 활성화합니다.

sudo ufw enable

상태와 규칙을 확인합니다.

sudo ufw status numbered

핵심 규칙은 다음과 같습니다.

22/tcp  ALLOW IN  192.168.1.0/24

Windows 관리 PC에서 새 터미널 창을 열고 SSH 접속을 다시 시험합니다.

ssh project-dev-server

새 연결이 정상적으로 열린 것을 확인하기 전까지 기존 SSH 창을 닫지 않는 것이 안전합니다.

SSH 포트를 나중에 변경한다면

SSH 포트를 예를 들어 2222로 바꾸려면 먼저 UFW에서 새 포트를 허용하고, SSH 설정을 바꾼 뒤, 새 포트 접속을 확인해야 합니다.

sudo ufw allow from 192.168.1.0/24 to any port 2222 proto tcp

새 포트 접속이 완전히 확인되기 전에는 기존 22번 허용 규칙을 삭제하지 않습니다. 이번 글에서는 기본 포트 22를 그대로 사용합니다.

완료 확인표

지금까지의 설정을 한 번에 확인합니다.

Windows 관리 PC에서 실행

ssh project-dev-server

접속된 서버에서 실행

hostname
whoami
hostname -I
pwd
groups
sudo systemctl is-active ssh
sudo ufw status verbose

다음 조건을 만족하면 준비가 끝난 것입니다.

• hostname 결과가 project-dev-server로 표시됨
• whoami 결과가 apple2ne1로 표시됨
• IP 주소에 192.168.1.231이 표시됨
• 홈 폴더가 /home/apple2ne1로 표시됨
• 그룹 목록에 sudo가 포함됨
• SSH 서비스가 active로 표시됨
• UFW에서 같은 네트워크의 22번 포트가 허용됨
• ssh project-dev-server로 간편하게 접속됨
• 키 인증을 설정했다면 서버 계정 비밀번호 없이 접속됨

자주 발생하는 문제

ssh: connect to host ... port 22: Connection timed out

다음을 확인합니다.

1. 서버 전원이 켜져 있는지 확인합니다.
2. Windows 관리 PC와 서버가 같은 공유기에 연결되어 있는지 확인합니다.
3. 서버 IP가 192.168.1.231인지 hostname -I로 다시 확인합니다.
4. UFW가 22번 포트를 허용하는지 확인합니다.
5. 서버 네트워크 케이블과 공유기 연결을 확인합니다.

Connection refused

네트워크는 도착했지만 SSH 서비스가 실행되지 않거나 해당 포트에서 기다리지 않는 경우가 많습니다. 서버 콘솔에서 확인합니다.

sudo systemctl status ssh.service ssh.socket
sudo ss -tlnp | grep ':22'

Ubuntu 22.10 이후의 기본 소켓 활성화 구성에서 ssh.socket이 비활성 상태라면 서버 콘솔에서 다음 명령으로 시작합니다.

sudo systemctl enable --now ssh.socket

환경에서 ssh.service를 직접 실행하도록 구성했다면 해당 서비스 단위를 사용합니다. 서비스나 소켓을 시작한 뒤 새 PowerShell 창에서 SSH 접속을 다시 시험합니다.

Permission denied

사용자 이름과 비밀번호를 확인합니다.

ssh apple2ne1@192.168.1.231

키 인증 문제라면 서버에서 권한을 다시 확인합니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

SSH 로그를 실시간으로 확인하려면 서버에서 실행합니다.

sudo journalctl -fu ssh.service

REMOTE HOST IDENTIFICATION HAS CHANGED

서버를 다시 설치했거나 같은 IP 주소를 다른 장치가 사용하게 되면 이 경고가 나타날 수 있습니다. 원인을 확인하기 전에 기존 known_hosts 기록을 삭제하지 않습니다. 발생 원리, 서버 지문 확인과 Windows에서 기존 기록을 안전하게 정리하는 절차는 REMOTE HOST IDENTIFICATION HAS CHANGED 경고 이해와 해결에서 설명합니다.

Netplan 수정 후 SSH가 끊겼을 때

서버 콘솔에서 직접 로그인하여 다음 내용을 확인합니다.

ip -br address
ip route
sudo netplan generate

백업 파일로 되돌려야 한다면 실제 파일 이름에 맞춰 복원합니다.

sudo cp /etc/netplan/00-installer-config.yaml.backup /etc/netplan/00-installer-config.yaml
sudo netplan apply

50-cloud-init.yaml을 수정했다면 복원 명령에서도 실제 파일명인 50-cloud-init.yaml과 50-cloud-init.yaml.backup을 사용합니다.

작업 결과 정리

이번 글에서는 같은 네트워크의 Windows 11 PC를 Windows 관리 PC라고 정하고, project-dev-server에 SSH로 접속할 준비를 마쳤습니다.

처음에는 다음과 같이 전체 주소를 사용했습니다.

ssh apple2ne1@192.168.1.231

SSH 키와 config 파일을 설정한 뒤에는 다음처럼 간단하게 접속할 수 있습니다.

ssh project-dev-server

이제 서버에 모니터와 키보드를 항상 연결해 둘 필요가 없습니다. 앞으로 프로그램 설치, Docker 구성, 프로젝트 파일 관리, VS Code 연결과 웹 서비스 배포 같은 대부분의 작업은 Windows 관리 PC에서 SSH로 접속한 뒤 진행합니다.

다음 글에서는 Windows 11의 VS Code Remote – SSH를 사용해 project-dev-server의 폴더를 직접 열고, Codex와 함께 개발 작업을 시작하는 방법을 다룹니다.

주의 사항과 한계

• 이 문서의 Windows 절차는 Windows 11 환경을 기준으로 작성했습니다.
• macOS의 터미널, SSH 키 경로와 ssh-copy-id 사용 방법은 별도 문서에서 다룹니다.
• 192.168.1.231, 192.168.1.240, apple2ne1은 이 문서의 실제 검증 환경값입니다. 다른 환경에서는 실제 IP 주소, 사용자 이름, 게이트웨이와 네트워크 인터페이스 이름을 사용해야 합니다.
• 실제 암호, 개인 키와 인증정보는 문서나 명령에 기록하지 않습니다.
• 공유기 설정과 DHCP Reservation 메뉴 이름은 제조사와 Firmware에 따라 다릅니다.
• Netplan을 잘못 수정하면 SSH 연결이 끊길 수 있으므로 서버 콘솔을 사용할 수 있는 상태에서 작업합니다.

다음 글

VS Code 환경

다음 글에서 다룰 내용:

• Windows 11에 VS Code를 설치하고 Microsoft의 Remote – SSH 확장을 추가합니다.
• VS Code에서 project-dev-server에 연결하고 원격 작업을 지원하는 VS Code Server가 설치되는 과정을 확인합니다.
• SSH config에 등록한 서버 별칭으로 다시 연결하고, 로컬 창과 원격 창을 구분하는 방법을 익힙니다.
• Linux 서버에 프로젝트 폴더를 만들고 VS Code에서 해당 원격 폴더를 엽니다.
• 원격 폴더에 README.md 파일을 생성·저장하여 파일 편집 권한과 작업 환경을 확인합니다.
• 작업을 마친 뒤 실행 중인 개발 서버와 VS Code의 원격 연결을 안전하게 종료합니다.

macOS에서 같은 서버에 SSH로 접속하는 과정은 별도 문서로 정리합니다.

작성 및 검증 정보

• 작성자: apple2ne1
• 검토자: apple2ne1
• 직접 수행 여부: Ubuntu Server 26.04 LTS와 Windows 11 PC에서 단계별로 직접 수행한 환경값을 기준으로 작성
• 마지막 문서 검토일: 2026-08-18
• 검증 방법: Windows PowerShell의 OpenSSH 클라이언트로 접속하고, SSH 키, Host Key 지문, SSH config, 고정 IP와 UFW 설정 결과를 명령 출력으로 확인
• 검증 서버: Ubuntu Server 26.04 LTS, 호스트 이름 project-dev-server, 사용자 이름 apple2ne1, IP 주소 192.168.1.231
• 검증 Windows 관리 PC: Windows 11, IP 주소 192.168.1.240

참고 자료 및 출처

• Ubuntu Server 공식 문서: OpenSSH Server — OpenSSH Server 설치, 서비스와 설정 방법 확인 — 2026-08-18
• Ubuntu Server 공식 문서: User management와 sudo — Ubuntu 사용자와 sudo 권한 관리 확인 — 2026-07-17
• Ubuntu Server 공식 문서: UFW Firewall — UFW 활성화와 SSH 허용 규칙 확인 — 2026-08-18
• Netplan 공식 문서: Static IP address — Netplan 고정 IP 주소 형식과 적용 절차 확인 — 2026-08-18
• Netplan 공식 문서: @@INLINE_0@@ — 제한 시간 후 되돌리기 동작과 실제 설정 복구 상태를 다시 확인해야 하는 한계 확인 — 2026-08-18
• Microsoft Learn: Windows OpenSSH Key-Based Authentication — Windows OpenSSH 키 생성과 인증 방식 확인 — 2026-07-17
• Microsoft Learn: OpenSSH for Windows — Windows OpenSSH Client 사용 환경 확인 — 2026-07-17
• Microsoft Learn: OpenSSH 기능 설치 문제 해결 — Windows 10과 Windows 11에서 OpenSSH Client가 선택적 기능으로 제공되는 점 확인 — 2026-08-02

관련 문서

• Linux MOC
• Ubuntu 26.04 LTS Server 설치하기