13강 / 20강

사용자와 SSH — 서버에 사람 들이기

계정을 만들고, 열쇠로 문을 열고

쇼핑몰이 커져서 친구 민준이가 함께 관리하게 되었습니다. 민준이에게 내 계정 비밀번호를 알려 줄까요? 절대 안 됩니다.

이유는 세 가지입니다.
① 누가 무엇을 했는지 구분할 수 없습니다
② 민준이에게 필요 없는 권한까지 전부 주게 됩니다
③ 민준이가 그만두면 내 비밀번호를 바꿔야 합니다

그래서 사람마다 계정을 따로 만듭니다.

고등학생서버에 사람 들이기

7강에서 권한을 배웠습니다. 그 권한을 누구에게 줄지 정하는 강이에요.

사람마다 자기 계정을 준다 — 공유하지 않는다

왜 계정을 나누나

이유	설명
추적	누가 무엇을 했는지 남는다
격리	한 사람의 실수가 번지지 않는다
회수	나가면 그 계정만 지운다

계정을 공유하면 셋 다 안 된다

비유 — 회사 출입증

	공용 출입증	개인 출입증
누가 들어왔나	모른다	기록된다
한 명이 퇴사하면	전부 바꿔야	그것만 정지 ✔

사고가 났을 때 추적할 수 있느냐 가 갈린다

서비스 계정도 따로 만듭니다

계정	용도
사람 계정	로그인해서 작업
서비스 계정	앱이 이 권한으로 돈다 (14강)

서비스 계정은 로그인 못 하게 만든다 — 셸을 nologin 으로

사람이 쓸 일이 없으니 로그인 기능을 뺍니다. 공격자가 그 계정을 얻어도 들어올 수 없어요.

이 서버를 쓰는 모든 계정 — 사람만 있는 게 아닙니다

bash 내 가상 Ubuntu 서버에서 실행

cat /etc/passwd

한 줄을 뜯어봅시다. jit:x:1000:1000:School Admin:/home/jit:/bin/bash

jit계정 이름로그인할 때 쓰는 것

x비밀번호 자리진짜는 /etc/shadow 에 (root만 읽음)

1000UID0 = root · 1000부터 사람

/home/jit홈 디렉터리로그인하면 여기서 시작

/bin/bash기본 셸nologin 이면 로그인 불가

www-data 를 보세요. 셸이 /usr/sbin/nologin 입니다. 사람이 아니라 nginx 가 쓰는 계정이라 로그인할 필요가 없거든요. 누가 훔쳐도 로그인할 수 없습니다. 이것도 보안입니다.

고등학생UID 0 은 특별합니다

note 의 이 설명에 중요한 함의가 있습니다.

root 가 특별한 것은 이름이 아니라 UID 0 이다

그래서 이런 일이 가능합니다

계정	UID	권한
root	0	전부
admin (UID 를 0으로)	0	전부 ⚠

이름을 바꿔도 UID 0 이면 root 다

보안 점검 항목

awk -F: '$3==0 {print $1}' /etc/passwd

결과가 root 하나가 아니면 이상한 것입니다.

공격자가 UID 0 계정을 몰래 만드는 수법이 있다

UID 의 범위

범위	용도
0	root
1~999	시스템 계정 — 서비스용
1000+	사람 계정

번호만 봐도 사람인지 서비스인지 안다

비유 — 사원 번호

회사에서 1번 사원 번호가 창업자인 경우가 있죠. 번호 자체에 의미가 붙는 겁니다.

번호	뜻
0	모든 권한
1000+	일반 직원

이름은 바뀌어도 번호는 남는다 — 시스템은 번호로 판단한다

파일 소유자도 번호로 저장됩니다. 계정을 지워도 파일에 번호가 남아 ls 에 숫자가 보이는 이유예요.

계정 만들기

계정 · 그룹 · 홈 디렉터리가 한 번에 만들어집니다

bash 내 가상 Ubuntu 서버에서 실행

sudo adduser minjun
id minjun
ls -ld /home/minjun

그룹 — 여러 사람에게 같은 권한을 한 번에

민준이도 sudo 를 쓸 수 있어야 합니다. 사용자 하나하나에 권한을 주는 대신, sudo 그룹에 넣으면 됩니다.

-aG 는 append to Group — 기존 그룹은 그대로 두고 추가

bash 내 가상 Ubuntu 서버에서 실행

groups minjun
sudo usermod -aG sudo minjun
groups minjun

고등학생-a 를 빠뜨리면 큰일 납니다

note 의 이 경고가 사고가 잦은 곳입니다.

명령	결과
`usermod -aG docker 사용자`	docker 그룹을 추가 ✔
`usermod -G docker 사용자`	그룹을 docker 하나로 교체 ⚠

-a = append(추가) — 없으면 덮어쓴다

무슨 일이 벌어지나

그 사용자가 sudo 그룹에 있었다면?

전	후
sudo, docker, www-data	docker 만 ⚠

sudo 권한을 잃는다 — 그리고 되돌릴 sudo 도 없다

이게 왜 심각한가

내가 유일한 관리자였다면 아무도 sudo 를 못 씁니다.

복구 방법	가능한가
다른 관리자에게	있으면 ✔
콘솔로 단일 사용자 모드	물리 접근 필요
클라우드 복구 모드	가능하지만 다운타임

클라우드 서버라면 몇 시간이 날아간다

비유 — 열쇠 꾸러미

동작	결과
열쇠를 하나 더 단다 (-aG)	기존 것 + 새것 ✔
꾸러미를 새로 만든다 (-G)	기존 열쇠를 다 버린다 ⚠

"추가" 와 "설정" 은 다른 말이다

안전 습관

groups 사용자          # 먼저 확인
usermod -aG 그룹 사용자  # -a 를 반드시
groups 사용자          # 다시 확인

바꾸기 전에 보고 바꾼 뒤에 또 본다 — 되돌릴 수 없는 명령의 원칙

🎮 권한 매트릭스

사용자와 파일을 바꿔 가며 누가 무엇을 할 수 있는지 확인해 보세요. 7강의 rwx 와 이번 강의 그룹이 어떻게 맞물리는지 보입니다.

SSH — 멀리서 서버에 들어가기

서버는 대개 다른 도시의 데이터센터에 있습니다. 거기까지 갈 수는 없으니 인터넷으로 터미널을 연결합니다. 그게 SSH예요.

ssh [email protected]

이 한 줄이면 지구 반대편 서버의 프롬프트가 내 화면에 뜹니다. 지금까지 배운 모든 명령을 그대로 쓸 수 있고요.

이 실습 서버는 바깥으로 나갈 수 없지만, 쓰는 법은 이렇습니다

bash 내 가상 Ubuntu 서버에서 실행

ssh jit@203.0.113.42

비밀번호 대신 열쇠를 쓰는 이유

🔑 비밀번호 방식

사람이 외울 만큼 짧다
로봇이 하루에 수만 번 시도한다
언젠가 뚫린다

아래 로그에서 직접 보게 됩니다

🗝️ 공개키 방식

내 컴퓨터에 개인키 (절대 안 나감)
서버에 공개키 (알려져도 안전)
사실상 못 뚫는다

서버 관리자의 기본 👍

지금 이 순간에도 누군가 문을 두드리고 있습니다

bash 내 가상 Ubuntu 서버에서 실행

sudo grep "Failed password" /var/log/auth.log

45.148.10.72 가 admin, root 로 계속 시도하고 있죠? 전 세계 서버가 매일 겪는 일입니다. 비밀번호 로그인을 꺼 버리면 이 시도는 전부 무의미해집니다.

이 서버는 이미 안전하게 설정되어 있습니다

bash 내 가상 Ubuntu 서버에서 실행

sudo cat /etc/ssh/sshd_config

PermitRootLogin noroot 직접 로그인 금지일반 계정 → sudo 로만

PasswordAuthentication no비밀번호 로그인 금지열쇠만 받겠다

PubkeyAuthentication yes공개키 허용열쇠 방식 켜기

고등학생개인키는 반드시 600

note 가 두 번 강조하는 이유가 있습니다.

SSH 는 열쇠 권한이 느슨하면 아예 거부한다

왜 그렇게 엄격한가

개인키는 비밀번호 그 자체입니다. 남이 읽으면 내가 되는 거예요.

권한	누가 읽나
644	서버의 모든 사용자 ⚠
600	나만 ✔

7강의 4·2·1 이 여기서 실제 보안이 된다

SSH 열쇠가 비밀번호보다 나은 이유

	비밀번호	열쇠
길이	사람이 외울 만큼	수천 비트
무차별 대입	가능	사실상 불가능
서버에 저장되는 것	해시	공개키 — 유출돼도 안전
재사용	여러 곳에 같은 것 ⚠	서버마다 다르게

서버가 털려도 공개키만 나간다 — 그걸로는 못 들어온다

비유 — 자물쇠와 열쇠

	비유
공개키	자물쇠 — 서버에 걸어 둔다 · 공개해도 된다
개인키	열쇠 — 내가 가진다 · 절대 안 준다

자물쇠 사진을 봐도 열쇠를 만들 수 없다

확인할 권한들

대상	권한
`~/.ssh`	700
`~/.ssh/id_ed25519`	600 ⭐
`~/.ssh/authorized_keys`	600

"Permissions are too open" 오류를 보면 이것이다

🤔 확인 문제

함께 일하는 사람에게 서버 접근을 줄 때 가장 올바른 방법은?

해설 계정을 나누면 누가 무엇을 했는지 기록에 남고(/var/log/auth.log), 필요한 권한만 줄 수 있으며, 그만둘 때 그 계정만 지우면 됩니다.

🤔 확인 문제

www-data 계정의 셸이 /usr/sbin/nologin 인 이유는?

🤔 확인 문제

SSH 에서 비밀번호 대신 공개키 방식을 권하는 가장 큰 이유는?

해설 /var/log/auth.log 에서 봤듯 지금 이 순간에도 무차별 시도가 들어옵니다. 개인키는 서버로 전송되지 않고 컴퓨터에만 남아 있어서, 훔칠 통신 자체가 없습니다.