[리눅스 기초] 네트워크 관리, OpenSSH

Chapter 11. 네트워크 관리

Linux에서 네트워크를 관리할 때는 네트워크 인터페이스, IP 주소, 라우팅, NetworkManager를 이해하는 것이 핵심이다.

 

1. 네트워크 인터페이스 정보 확인

 

ip 명령어

현대 Linux에서 네트워크 인터페이스의 정보를 확인할 때 사용하는 대표적인 명령어이다.

ip
ip addr
ip address show

ip address show를 사용하면 다음과 같은 정보를 확인할 수 있다.

• 네트워크 인터페이스 이름
• MAC 주소
• IPv4 주소
• IPv6 주소
• 인터페이스 활성화 상태
• 서브넷 정보
• 브로드캐스트 주소

예를 들어 다음과 같이 인터페이스가 구성되어 있을 수 있다.

lo
enp2s0
enp18s0

 

Loopback 인터페이스

lo는 실제 랜카드가 아니라 자기 자신을 가리키는 가상 네트워크 인터페이스이다.

대표적인 주소가 다음과 같다.

127.0.0.1
::1

서버 자신에게 네트워크 서비스를 요청하거나 로컬에서 서비스를 테스트할 때 사용한다.

 

네트워크 인터페이스 상태

인터페이스 정보에는 다음과 같은 상태가 표시된다.

UP
LOWER_UP

특히 LOWER_UP은 물리적인 네트워크 연결이 활성화되어 있음을 나타낸다.

또한 IP 주소 뒤에 다음과 같이 표시될 수 있다.

dynamic

이는 DHCP 등을 통해 동적으로 할당된 IP 주소임을 의미한다.

반대로 직접 설정한 IP는 정적으로 구성된 주소이다.

 

2. ifconfig

ifconfig는 과거 Linux에서 많이 사용했던 네트워크 관리 명령어이다.

ifconfig

네트워크 인터페이스의 IP 주소, MAC 주소, 송수신 패킷 등의 정보를 확인할 수 있다.

하지만 현재 Linux 환경에서는 업데이트와 유지보수 측면에서 ip 명령어 사용이 권장된다.

따라서 네트워크 인터페이스 확인에는 기본적으로 다음 명령어를 기억하는 것이 좋다.

ip address show

 

3. 네트워크 연결 상태 확인

네트워크가 정상적으로 연결되어 있는지 확인할 때 사용하는 대표적인 명령어가 다음과 같다.

• ping
• tracepath
• traceroute

 

ping

특정 호스트와 통신이 가능한지 확인한다.

ping 8.8.8.8

응답이 돌아오면 해당 목적지와 네트워크 통신이 가능하다는 것을 확인할 수 있다.

ping은 ICMP를 이용해 대상에게 요청을 보내고 응답을 확인한다.

 

tracepath

목적지까지 패킷이 어떤 경로를 거쳐 이동하는지 확인할 수 있다.

tracepath 8.8.8.8

여러 라우터를 거치는 과정에서 각 홉(hop)을 확인할 수 있다.

여기서 hop은 목적지까지 이동하면서 거치는 라우터 단위로 이해할 수 있다.

 

traceroute

tracepath와 마찬가지로 목적지까지의 네트워크 경로를 확인하는 명령어이다.

traceroute 8.8.8.8

경로상 특정 라우터가 응답하지 않을 경우 *로 표시될 수 있다.

문서에서는 tracepath와 traceroute의 차이를 설명하면서, 외부 네트워크까지의 경로를 확인할 때 traceroute를 활용하는 흐름을 강조하고 있다.

 

4. TTL과 네트워크 경로

tracepath와 traceroute는 TTL(Time To Live)을 활용하여 패킷이 어느 라우터를 거쳐 가는지 확인한다.

목적지까지 바로 도착하는 것이 아니라 여러 라우터를 거치는 경우, TTL 값을 변화시키면서 각 구간의 응답을 확인하는 방식이다.

다만 모든 라우터가 ICMP 등의 응답을 허용하는 것은 아니기 때문에 특정 구간에서 응답이 나타나지 않을 수도 있다.

따라서 * 또는 no reply가 나타난다고 해서 반드시 해당 라우터에서 네트워크가 끊어진 것은 아니다.

 

5. 라우팅 테이블

네트워크 통신에서 중요한 개념 중 하나가 라우팅 테이블이다.

라우팅 테이블은 패킷이 목적지까지 갈 때 어떤 경로와 게이트웨이를 이용해야 하는지에 대한 규칙을 가지고 있다.

확인 명령어는 다음과 같다.

ip route

예를 들어 다음과 같은 설정이 있을 수 있다.

default via 192.168.154.2 dev enp2s0
192.168.100.0/24 dev enp18s0
192.168.154.0/24 dev enp2s0

 

Default Gateway

가장 중요한 개념이 다음 부분이다.

default via 192.168.154.2

이는 목적지에 대한 별도의 경로를 알지 못할 경우 기본 게이트웨이로 패킷을 전달한다는 의미이다.

즉,

"내가 직접 알고 있는 네트워크가 아니면 기본 게이트웨이로 보낸다."

라고 이해할 수 있다.

과거 방식으로는 다음 명령어를 사용할 수도 있다.

route -n
netstat -rn

하지만 현대 Linux에서는 ip route를 사용하는 것이 기본적인 방법이다.

 

6. NetworkManager

Linux에서는 NetworkManager가 네트워크 설정을 관리한다.

NetworkManager는 네트워크 설정을 동적으로 관리하고 상황에 맞는 네트워크 구성을 적용하는 데몬이다.

상태는 다음과 같이 확인할 수 있다.

systemctl status NetworkManager

NetworkManager는 다음과 같은 네트워크 작업을 관리한다.

• 네트워크 인터페이스 관리
• IP 주소 설정
• DHCP 설정
• 라우팅 설정
• DNS 설정
• 네트워크 연결 프로필 관리

 

7. nmcli와 nmtui

NetworkManager를 관리하는 대표적인 도구가 두 가지 있다.

 

nmcli

nmcli

CLI(Command Line Interface) 기반으로 NetworkManager를 관리한다.

서버 환경에서 네트워크를 관리할 때 특히 유용하다.

 

nmtui

nmtui

TUI(Text User Interface) 기반으로 네트워크 설정을 관리한다.

즉,

• nmcli → 명령어 기반
• nmtui → 화면 기반

이라고 구분하면 된다.

 

8. 네트워크 연결 프로필

NetworkManager는 네트워크 설정을 Connection Profile 형태로 관리한다.

현재 저장된 연결 프로필은 다음 명령어로 확인할 수 있다.

nmcli connection show

각 프로필에는 다음과 같은 정보가 포함될 수 있다.

• 연결 이름
• UUID
• 연결 타입
• 연결된 장치
• 자동 연결 여부
• IP 주소
• 게이트웨이
• DNS
• 인터페이스 이름

특정 연결의 상세 설정은 다음과 같이 확인한다.

nmcli connection show <connection-name>

네트워크 문제를 분석하거나 현재 설정을 확인할 때 유용하다.

 

9. NetworkManager 연결의 핵심 흐름

NetworkManager를 이용한 네트워크 설정은 크게 다음과 같은 흐름으로 이해하면 된다.

연결 생성
   ↓
설정 수정
   ↓
연결 활성화
   ↓
네트워크 인터페이스에 적용

중요한 점은 설정 프로필을 만든 것과 실제로 해당 연결이 활성화된 것은 별개라는 것이다.

따라서 연결을 생성하거나 수정한 후 실제로 적용하려면 연결을 활성화해야 한다.

nmcli connection up <connection-name>

 

10. 정적 IP와 동적 IP

NetworkManager에서는 IP 주소를 동적으로 받을 수도 있고 직접 지정할 수도 있다.

 

동적 IP

DHCP를 통해 IP 주소를 자동으로 할당받는다.

 

정적 IP

관리자가 직접 다음과 같은 정보를 지정한다.

• IP 주소
• 서브넷
• 게이트웨이
• DNS

문서의 설정 예시에서는 ipv4.method를 manual로 지정하여 정적 IP 방식을 구성하고 있다.

ipv4.method manual
ipv4.addresses
ipv4.gateway
ipv4.dns

따라서 정적 네트워크 설정에서 핵심적으로 기억할 항목은 다음과 같다.

IP 주소 + 게이트웨이 + DNS

11. hostname

hostname은 네트워크에서 시스템을 이름으로 식별하기 위한 정보이다.

현재 hostname은 다음 명령어로 확인할 수 있다.

hostname

영구적으로 hostname을 변경할 때는 hostnamectl을 사용한다.

hostnamectl set-hostname "rocky11"

변경된 hostname은 다음 파일을 통해 확인할 수 있다.

/etc/hostname

관련된 주요 설정 파일은 다음과 같다.

/etc/hosts
/etc/resolv.conf
/etc/nsswitch.conf

각 파일은 호스트 이름 확인, DNS 설정, 이름 해석 순서 등의 네트워크 이름 관련 기능과 연결된다.

 

Chapter 12. OpenSSH

1. 원격 서버 관리

서버 환경에서는 직접 서버 앞에서 작업하는 것보다 네트워크를 통해 원격으로 서버에 접속하여 관리하는 경우가 많다.

이러한 원격 서버 관리를 가능하게 하는 대표적인 기술이 SSH(Secure Shell)이다.

과거에는 Telnet을 사용하기도 했지만 Telnet은 통신 내용이 평문으로 전달되는 문제가 있었다.

SSH는 이러한 문제를 해결하기 위해 등장했으며, 통신 내용을 암호화하여 안전하게 원격 접속할 수 있도록 한다.

 

2. OpenSSH

Linux에서 일반적으로 사용하는 SSH 구현이 OpenSSH이다.

SSH를 이해할 때는 단순히 "원격 접속 명령어"로만 생각하기보다,

안전한 통신을 위해 인증과 암호화를 수행하는 프로토콜

이라는 개념으로 이해하는 것이 중요하다.

문서에서는 SSH의 키 교환 과정을 개념적으로 이해하는 것을 강조한다.

 

3. 대칭키 암호화

대칭키 암호화에서는 하나의 키를 이용하여 데이터를 암호화하고 복호화한다.

암호화
데이터 + 키
   ↓
암호문

복호화
암호문 + 같은 키
   ↓
원본 데이터

대칭키 암호화의 장점은 빠른 속도이다.

따라서 실제 데이터를 전송할 때 효율적으로 사용할 수 있다.

하지만 한 가지 문제가 있다.

암호화에 사용할 키를 상대방에게 어떻게 안전하게 전달할 것인가?

이것이 대칭키 방식의 중요한 문제점이다.

 

4. 비대칭키 암호화

비대칭키 암호화에서는 하나가 아닌 공개키와 개인키 한 쌍을 사용한다.

공개키
개인키

공개키는 외부에 공개해도 되지만 개인키는 안전하게 보호해야 한다.

개념적으로는 다음과 같이 이해할 수 있다.

공개키 → 공개 가능
개인키 → 소유자가 비밀스럽게 보관

공개키와 개인키는 서로 연결된 한 쌍으로 사용된다.

비대칭키 암호화는 대칭키의 키 교환 문제를 해결하는 데 활용할 수 있다.

 

5. SSH의 하이브리드 암호화

SSH에서는 대칭키와 비대칭키를 함께 사용하는 하이브리드 암호화 방식을 사용한다.

기본적인 흐름은 다음과 같이 이해할 수 있다.

비대칭키
   ↓
안전한 키 교환
   ↓
세션 키 생성/전달
   ↓
대칭키 암호화
   ↓
실제 데이터 통신

즉,

• 비대칭키 → 인증 및 안전한 키 교환
• 대칭키 → 실제 데이터 통신

이라는 역할 분담으로 이해하면 된다.

대칭키는 빠르기 때문에 실제 데이터 전송에 적합하고, 비대칭키는 안전한 인증 및 키 교환에 활용된다.

 

6. OpenSSH 설정 파일

OpenSSH와 관련된 설정 파일은 /etc/ssh 아래에 위치한다.

대표적으로 다음 파일을 확인할 수 있다.

/etc/ssh/ssh_config
/etc/ssh/sshd_config

 

ssh_config

SSH 클라이언트 설정과 관련된다.

 

sshd_config

SSH 서버 설정과 관련된다.

따라서 이름을 구분해서 기억하면 좋다.

ssh_config   → Client
sshd_config  → Server

 

 

7. SSH 서버의 주요 설정

sshd_config에는 SSH 서버의 동작과 인증 방법을 결정하는 다양한 설정이 존재한다.

문서에서 중요하게 다루는 항목은 다음 세 가지이다.

PermitRootLogin
PubkeyAuthentication
PasswordAuthentication

 

PermitRootLogin

root 계정의 SSH 원격 로그인을 허용할지 결정한다.

 

PubkeyAuthentication

공개키 기반 인증을 사용할지 결정한다.

PubkeyAuthentication yes

 

PasswordAuthentication

비밀번호 기반 로그인을 허용할지 결정한다.

PasswordAuthentication yes

따라서 SSH 서버의 인증 방식을 이해할 때는 비밀번호 인증과 공개키 인증의 차이를 파악하는 것이 중요하다.

 

8. SSH 설정 변경과 적용

SSH 서버의 설정 파일을 수정했다고 해서 기존 실행 중인 SSH 서버에 즉시 설정이 적용되는 것은 아니다.

설정을 변경한 후에는 SSH 서비스에 변경 내용을 적용해야 한다.

문서에서는 다음과 같이 서비스를 다시 시작하는 방법을 제시한다.

systemctl restart sshd

즉,

설정 파일 수정
      ↓
sshd 서비스 재시작
      ↓
변경된 설정 적용

이라는 흐름을 이해해야 한다.

 

9. 공개키 기반 인증

SSH에서는 비밀번호 대신 공개키 기반 인증을 사용할 수 있다.

기본적인 구조는 다음과 같다.

클라이언트
 ├─ 개인키
 └─ 공개키
        ↓
      서버에 등록

클라이언트의 개인키
        ↓
서버가 등록된 공개키와 확인
        ↓
인증 성공

중요한 점은 개인키는 클라이언트가 안전하게 보관하고, 공개키를 서버에 등록한다는 것이다.

따라서 서버에 공개키가 등록되어 있으면 이후 SSH 접속 과정에서 비밀번호 대신 키를 이용해 인증할 수 있다.

 

10. SSH 개인키와 공개키

OpenSSH에서는 여러 종류의 키가 존재할 수 있다.

예를 들어 서버의 /etc/ssh에는 다음과 같은 형태의 파일이 존재할 수 있다.

ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub

ssh_host_ed25519_key
ssh_host_ed25519_key.pub

ssh_host_rsa_key
ssh_host_rsa_key.pub

일반적으로 이름 뒤에 .pub이 붙은 파일은 공개키이고, 그렇지 않은 파일은 개인키에 해당한다.

개인키는 외부에 노출되지 않도록 권한을 제한하여 관리하는 것이 중요하다.\

 

11. SSH 접속과 키 인증

키 기반 인증을 사용할 경우 클라이언트는 자신의 개인키를 이용하여 서버에 인증한다.

문서에서는 다음과 같은 형태의 SSH 접속을 예시로 보여준다.

ssh -i /home/nobreak/.ssh/client_key testuser@192.168.58.88

여기서 -i 옵션을 이용해 사용할 개인키를 지정할 수 있다.

키 기반 인증의 핵심은 다음과 같다.

클라이언트 개인키
        ↓
SSH 서버에 등록된 공개키와 인증
        ↓
비밀번호 없이 로그인

최초에 공개키를 서버에 등록하는 과정에서는 비밀번호 인증이 필요할 수 있다.

 

12. .ssh 디렉터리

SSH와 관련된 사용자별 키 및 설정 정보는 일반적으로 사용자의 홈 디렉터리 아래 .ssh에 저장된다.

대표적인 SSH 관련 파일은 다음과 같다.

~/.ssh/

키 기반 인증을 사용할 때 공개키 및 개인키를 관리하는 중요한 위치이다.

개인키는 외부에 노출되지 않도록 보호해야 한다.

 

13. known_hosts

SSH에는 서버의 신원을 확인하기 위한 기능도 있다.

클라이언트는 접속했던 서버의 공개키 정보를 known_hosts에 저장할 수 있다.

~/.ssh/known_hosts

이 파일에는 접속한 서버의 IP 주소와 서버 키 정보가 기록된다.

이를 통해 클라이언트는 이후 같은 서버에 접속할 때 서버의 신원이 이전에 알고 있던 서버와 일치하는지 확인할 수 있다.

이는 중간자 공격(MITM, Man-in-the-Middle Attack)을 방어하는 데 도움이 된다.

 

14. SCP

SSH 환경에서 함께 알아야 하는 명령어가 scp이다.

scp는 SSH 기반으로 파일을 안전하게 복사할 때 사용하는 명령어이다.

즉,

SSH → 원격 서버 접속
SCP → SSH를 이용한 파일 전송

이라고 연결해서 이해하면 된다.