itlifebetter

SSH와 SFTP는 모두 보안을 위해 사용하는 프로토콜이며, 일반적으로 같은 포트(22번)를 사용합니다.
그래서 종종 이런 질문이 나옵니다

"SFTP는 되게 하면서 SSH는 막을 수 있을까?"

이번 글에서는 이 질문에 대한 답을 기술적인 배경과 함께 정리하고,
실제로 SFTP만 허용하는 방법까지 친절하게 설명해드릴게요! 😊

🔍 SFTP와 SSH의 관계

• SFTP는 SSH를 기반으로 동작하는 파일 전송 프로토콜입니다.
• 즉, SFTP는 SSH의 한 기능이라고 보면 됩니다.
• 두 프로토콜 모두 기본적으로 TCP 22번 포트를 사용합니다.

💡 그래서 기본 설정에서는 SFTP가 가능하면 SSH도 가능하다는 것이 원칙입니다.

🚫 포트나 방화벽으로 SFTP만 허용할 수 있을까?

❌ 불가능합니다.
포트 기반 차단은 SSH와 SFTP를 구분하지 못합니다. 둘 다 같은 포트를 사용하니까요.

✋ 포트를 막으면 SFTP와 SSH 모두 차단됩니다!

✅ SFTP만 허용하고 SSH는 차단하려면?

특정 사용자에게만 SFTP를 허용하고, 쉘 접속(SSH)은 막는 방법이 있습니다.
즉, SSH 자체는 열려 있지만, 접속 유저를 제한하는 방식입니다.

🔧 방법 1: sshd_config에서 사용자별 SFTP 전용 설정

/etc/ssh/sshd_config 파일에 아래처럼 추가합니다

Match User sftpuser
    ForceCommand internal-sftp
    ChrootDirectory /home/sftpuser
    PermitTunnel no
    AllowAgentForwarding no
    AllowTcpForwarding no
    X11Forwarding no

✔️ sftpuser는 이제 SSH로 접속해도 쉘을 실행할 수 없고, SFTP만 사용할 수 있게 됩니다.
🔐 보안도 강화되고, 불필요한 접근을 막을 수 있어요!

🛠️ 방법 2: SFTP 전용 셸 (rssh, scponly) 사용

전용 셸을 설정하면 해당 사용자는 SFTP/파일 전송만 가능하고 SSH 쉘 접근은 차단됩니다

usermod -s /usr/bin/rssh sftpuser

✔️ rssh는 SFTP, SCP 등만 허용하고 나머지는 차단해줍니다.
📦 다중 사용자 환경에서 특히 유용합니다.

🧾 요약 정리

🛡️ 주의할 점

1. ChrootDirectory 경로는 root가 소유하고, 사용자에게 쓰기 권한이 없어야 합니다.
   → /home/sftpuser 디렉토리는 root:root이어야 정상 작동합니다.
2. 설정 변경 후에는 SSH 서비스를 재시작해야 적용됩니다
3. SSH가 아예 다 막히는 건 아니고, 다른 사용자들은 기존대로 SSH 접속이 가능합니다.

sudo systemctl restart sshd

✅ 디렉토리 구조 및 권한 설정 방법

예: 사용자 이름이 sftpuser이고, 홈 디렉토리가 /home/sftpuser인 경우

1️⃣ 상위 디렉토리 (/home/sftpuser)는 root가 소유해야 함

sudo chown root:root /home/sftpuser 
sudo chmod 755 /home/sftpuser

• ✅ 소유자: root:root
• ✅ 권한: rwxr-xr-x (755)
• ❌ sftpuser에게는 여기에 직접 쓰기 권한이 있으면 안 됨

2️⃣ 실제 파일 업로드 디렉토리 만들기

root 소유 디렉토리 아래에 실제 업로드할 디렉토리를 따로 만듭니다.

sudo mkdir /home/sftpuser/upload 
sudo chown sftpuser:sftpuser /home/sftpuser/upload 
sudo chmod 755 /home/sftpuser/upload

• ✅ 여기는 sftpuser가 소유하고 자유롭게 파일 업로드 가능
• ❗ 이 경로를 접속 후 루트 디렉토리로 보여지게 하려면 internal-sftp가 자동으로 ChrootDirectory 하위 디렉토리로 진입합니다.

🧩 마무리

서버 보안을 유지하면서 파일 전송만 허용하고 싶을 때,
SSH를 제한하고 SFTP만 열어두는 방식은 매우 유용합니다.

✅ 특정 사용자만 SFTP 접근 가능
✅ 쉘 로그인 차단
✅ 불필요한 공격 노출 감소

꼭 필요한 사용자만 SFTP 접근하도록 설정해서
더 안전한 서버 운영을 해보세요! 🔐💪

소프트웨어를 배포하거나 로컬 환경에서 특정 바이너리를 실행할 때, 필요한 라이브러리(의존성)가 누락되어 문제가 생기는 경우가 많습니다. 이 글에서는 운영체제별로 바이너리 의존성을 확인하는 방법을 소개합니다.

📌 바이너리 의존성이란?

바이너리는 일반적으로 다른 공유 라이브러리에 의존합니다. 예를 들어, 리눅스에서 컴파일된 실행 파일은 libc.so나 libpthread.so 등 여러 라이브러리와 연결되어 있어야 정상적으로 실행됩니다.

이러한 외부 의존성을 확인하는 것은 다음과 같은 상황에서 매우 중요합니다:

• 실행 파일이 다른 시스템에서 작동하는지 확인할 때
• 컨테이너 이미지 최적화 및 디버깅
• 배포 패키지에 필요한 라이브러리를 모두 포함했는지 검토할 때

🐧 리눅스: ldd 명령어

ldd ./my_binary

이 명령은 바이너리가 동적으로 링크된 라이브러리를 보여줍니다.

예시 출력

linux-vdso.so.1 =>  (0x00007ffd2a3f0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8ad3a23000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8ad3654000)

otool -L ./my_binary

예시 출력

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
@rpath/libexample.dylib (compatibility version 1.0.0, current version 1.2.3)

💡 @rpath, @loader_path, @executable_path 등 macOS 특유의 경로 지정도 함께 확인할 수 있습니다.

🔧 팁: 정적 vs 동적 링크 여부 확인

• 정적 링크된 바이너리는 외부 의존성이 거의 없습니다.
• 리눅스에서 file 명령으로 확인할 수 있습니다

file ./my_binary

예시

ELF 64-bit LSB executable, dynamically linked, ...

리눅스 서버를 운영하다 보면 어느 순간 용량이 꽉 차면서 서버가 멈추거나 경고 메시지가 발생하는 경우가 있습니다.
이럴 때 가장 먼저 확인해야 할 것은 디렉토리별 용량 사용 현황입니다.

특히 다음과 같은 상황에서 필수적으로 확인해야 하죠:

• 💾 서버 디스크 용량 부족 경고 발생
• 📂 /var, /home, /tmp 등에 공간이 갑자기 소모되었을 때
• 🔧 서버 성능 이슈 발생 전 사전 점검

이 글에서는 리눅스 서버에서 디렉토리 용량을 확인하는 방법을
du, df 명령어를 중심으로 쉽고 정확하게 정리했습니다.
구글 검색에서 자주 찾는 명령어 예제도 함께 제공합니다. 👇

✅ 1. du -sh * : 현재 디렉토리 하위 용량 요약 확인

du -sh *

📌 의미

• -s: 디렉토리별 요약
• -h: 사람이 읽기 쉬운 단위 (KB, MB, GB)

💡 예시

$ du -sh *
1.1G   var
432M   etc
3.9G   home

✅ 2. du -h --max-depth=1 /경로 : 하위 디렉토리별 용량 상세

du -h --max-depth=1 /경로

📌 사용 이유:

• 특정 디렉토리 하위 폴더들의 사용량을 1단계 깊이로 확인
• 대용량 폴더 빠르게 찾기 용이

💡 예시

du -h --max-depth=1 /home

✅ 3. df -h : 전체 디스크 사용량 확인

df -h

📌 의미:

• 전체 파일시스템의 용량, 사용량, 남은 공간 확인
• % 사용률로 용량 상태를 직관적으로 파악

💡 예시 출력:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   42G  5.5G  89% /
/dev/sdb1       100G   20G   80G  20% /data

✅ 4. du -sh /경로 : 특정 디렉토리 전체 용량 확인

du -sh /var/log

📌 예:

• /var/log, /tmp, /home/user 등 공간을 많이 차지하는 경로를 빠르게 스캔

✅ 5. du --apparent-size : 실제 파일 크기 기준 확인

du -sh --apparent-size /경로

📌 차이점:

• du는 실제 디스크에 사용된 공간 기준
• --apparent-size는 파일이 차지하는 논리적 크기 기준

🔄 실전 활용 예시: 서버 용량 점검 루틴

df -h du -sh /* du -h --max-depth=1 /var | sort -hr

🎯 결론

리눅스 서버에서는 주기적인 디렉토리 용량 확인이 중요합니다.
du, df 명령어만 잘 활용해도 대부분의 디스크 문제를 빠르게 진단할 수 있어요.

💡 특히 /var, /home, /tmp 경로는 자주 확인하고,
용량 부족 시에는 로그 정리, 캐시 삭제 등을 통해 공간 확보가 필요합니다.

서버에 SSH로 접속하거나 콘솔에서 로그인할 때
"Your must change your password now and login again"
이라는 메시지를 본 적 있나요? 😨

이 메시지는 단순한 에러가 아니라, 비밀번호 만료나 보안 정책에 따른 강제 비밀번호 변경 요구입니다.
특히 Linux 서버나 Active Directory(AD), LDAP 환경에서 자주 발생하죠.

이 포스팅에서는 이 메시지의 원인과 해결 방법을 단계별로 설명합니다.
👨‍💻 리눅스 서버 관리자라면 꼭 알고 있어야 할 정보!
🔐 보안 정책에 따른 시스템 메시지를 이해하고 빠르게 조치하는 방법을 알려드릴게요.

1️⃣ 이 에러 메시지의 정체는?

"Your must change your password now and login again"
→ "지금 비밀번호를 변경하고 다시 로그인해야 합니다"

이 메시지는 서버에서 비밀번호가 만료되었거나,
보안 정책에 따라 비밀번호를 강제로 변경해야 할 때 출력됩니다.

📍 주요 원인:

• 🕒 비밀번호 유효기간 만료
• 🧑‍💻 초기 비밀번호 사용 중 (최초 로그인 후 변경 필수)
• 🔒 보안 정책(PAM, LDAP, AD 등)에 의한 강제 변경 요구
• 👨‍🏫 passwd -e user 같은 명령어로 수동 만료 설정된 경우

2️⃣ 리눅스 서버에서 해결하는 방법 (SSH 기준)

접속 시 메시지가 나타난다면 아래 순서대로 입력하세요

$ ssh user@server
Your password has expired. You must change your password now and login again!
Changing password for user user.
(current) UNIX password: [기존 비밀번호 입력]
New password: [새 비밀번호 입력]
Retype new password: [다시 입력]

✅ 비밀번호를 변경하고 나면 자동으로 로그아웃되며,
다시 SSH 접속하면 정상적으로 로그인됩니다.

3️⃣ root 계정에서 강제 해결 (비밀번호 수동 리셋)

관리자(root) 권한으로 다음 명령을 실행하면 사용자 비밀번호 상태를 초기화할 수 있어요.

# 유저 비밀번호 재설정
passwd username

# 만료 설정 초기화
chage -E -1 -M 99999 username

📌 비밀번호 만료 여부 확인

chage -l username

4️⃣ PAM & 보안 정책 설정 확인 (선택 사항)

🔍 /etc/login.defs, /etc/pam.d/common-password, /etc/shadow 파일에서
비밀번호 유효기간과 정책을 조정할 수 있습니다.

• PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE 등 설정 확인
• AD/LDAP 연동 시, 외부 정책에 따라 비밀번호 만료됨

5️⃣ 자주 묻는 질문 (FAQ)

💬 Q. 꼭 변경해야 하나요?
🔑 네! 시스템이 보안상 변경을 요구하므로, 변경 없이 우회는 어렵습니다.

💬 Q. GUI 환경에서는 어떻게 하나요?
🖥️ GUI에서도 로그인 시 동일 메시지가 나타나며,
비밀번호 변경 창이 자동으로 뜨는 경우가 많습니다.

✅ 마무리

이 메시지는 단순 오류가 아니라 보안 정책에 따른 시스템 조치입니다.
이를 무시하거나 방치하면 계정 잠금이나 로그인 차단으로 이어질 수 있어요.
안전하고 빠르게 대응하려면 즉시 비밀번호를 변경하고 재로그인하세요! 🔐

서버 운영에 있어 포트 관리는 보안의 기본입니다. 불필요하게 열려 있는 포트는 외부 공격에 노출될 수 있어, 수시로 점검하고 필요한 경우 방화벽으로 차단하는 것이 중요합니다. 이번 글에서는 리눅스 서버에서 오픈된 포트를 확인하고, 특정 포트를 차단하는 방법을 실습 중심으로 정리했습니다.

✅ 1. 오픈 포트 확인하기

리눅스에서는 대표적으로 ss, netstat, lsof 명령어를 활용해 서버에서 열려 있는 포트를 확인할 수 있습니다.

🔸 ss -tuln

ss -tuln

옵션 설명

• -t: TCP
• -u: UDP
• -l: Listening 상태만
• -n: 포트 번호 숫자로 출력

예시 출력

LISTEN  0  128  0.0.0.0:22     0.0.0.0:*   # SSH 포트
LISTEN  0  128  0.0.0.0:3030   0.0.0.0:*   # 커스텀 서비스

🔸 포트를 사용 중인 프로세스 확인 (ss -tulnp)

sudo ss -tulnp

✅ 2. 특정 포트 차단하기 (iptables 기준)

불필요하거나 외부 접근을 막아야 할 포트는 iptables를 사용해 차단할 수 있습니다.

🔸 TCP 3030 포트 차단

sudo iptables -A INPUT -p tcp --dport 3030 -j DROP

• DROP: 요청 무시 (보안상 은폐 효과 있음)
• REJECT: 요청 거부 응답 전송 (접속자에게 명확히 알림

🔸 차단 룰 확인

sudo iptables -L INPUT -n --line-numbers | grep 3030

✅ 3. 외부에서 포트 열림 여부 확인

서버 내부에서 포트가 열려 있어도, 방화벽이나 보안 그룹이 막고 있을 수 있습니다. 외부에서 실제 접근이 가능한지 확인하려면 다음과 같이 테스트합니다.

🔸 telnet 또는 nc 사용

telnet 서버IP 3030
# 또는
nc -zv 서버IP 3030

✅ 4. 방화벽 정책 확인

🔸 firewalld 사용 시 (CentOS 7 이상)

sudo firewall-cmd --list-all

🔸 ufw 사용 시 (Ubuntu)

sudo ufw status

📚 마무리

서버 보안은 열려 있는 포트를 관리하는 것에서 시작됩니다.
필요한 포트만 열고, 나머지는 차단 또는 비공개로 유지하세요.
정기적인 ss, iptables, nc 점검으로 보안 사고를 미연에 방지할 수 있습니다.