infra
Platform

모듈 맵

[Infra Ops] SFTP/배치 파일 송수신과 외부 기관 연계 실무

0 / 52 완료

펼치기
0 / 52 완료0%

인프라 운영 & SRE · 29 / 52

[Infra Ops] SFTP/배치 파일 송수신과 외부 기관 연계 실무

SFTP 접속 설정, 키 기반 인증, 파일 권한/경로 관리, 배치 처리 자동화까지

🚨INCIDENT ALERT
HIGH

보험사와 데이터를 연계하는 업무를 맡았습니다. 매일 새벽 2시에 CSV 파일을 상대방 SFTP 서버에 올리고, 처리 결과 파일을 내려받아야 합니다. 처음에는 수동으로 했는데 이제 자동화해야 합니다. 개인키 인증 설정, 파일 올리는 스크립트, 전송 완료 확인 — 어떻게 하면 될까요?

외부 기관 파일 연계는 생각보다 자주 있는 업무입니다. SFTP 구조와 키 기반 인증, 배치 자동화 패턴을 실무 중심으로 익혀봅니다.

이번 챕터에서 배울 것
  • 1SFTP, SCP, rsync의 차이를 설명하고 상황에 맞게 선택할 수 있다
  • 2SSH 키 기반 SFTP 인증을 설정하고 연결을 테스트할 수 있다
  • 3sftp -b 옵션으로 배치 업로드 스크립트를 작성할 수 있다
  • 4전송 완료 여부를 파일 크기 비교와 md5 체크섬으로 검증할 수 있다
  • 5chroot 격리의 개념과 경로 혼동 문제를 설명할 수 있다

파일 전송 도구 비교

💡개념

SFTP vs SCP vs rsync — 언제 무엇을 쓰나

파일을 원격으로 전송하는 도구가 여러 개 있어 헷갈립니다. 각각 강점이 다르고, 외부 기관 연계에 적합한 것은 SFTP입니다.

SFTP vs SCP vs rsync — 언제 무엇을 쓰나확대

보험사와 파일 연계를 시작했는데, 자동화 스크립트가 매일 새벽 실패합니다. 어제는 SCP로 올렸더니 상대방이 "파일이 안 보인다"고 하고, rsync를 써보니 방화벽에서 막힙니다. 파트너사마다 요구하는 전송 방식이 다르고, 각 도구의 동작 방식을 모르면 장애 원인도 파악하기 어렵습니다. 외부 기관 파일 연계에서 가장 많이 쓰이는 도구는 SFTP입니다. 포트 22번 하나로 디렉터리 탐색, 업로드, 다운로드, 권한 확인을 모두 처리할 수 있어 방화벽 규정을 충족하기 쉽고, 대부분의 금융·공공 기관 시스템이 SFTP 서버를 표준으로 운영합니다.

도구전송 방식대화형배치증분 동기화재시작주 사용
SCPSSH 위 복사불가가능불가불가단순 파일 복사
SFTPSSH 서브시스템가능가능불가부분 가능외부 기관 연계
rsyncSSH + rsync 프로토콜불가가능가능가능백업, 미러링

SFTP가 외부 기관 연계에 적합한 이유:

  • 상대방 서버 디렉터리 구조를 탐색하며 파일 위치 확인 가능
  • 표준 SSH 22번 포트만 열면 돼 방화벽 규정 충족이 쉬움
  • 대부분의 파트너 시스템(은행, 보험사, 공공기관)이 SFTP를 표준으로 지원
  • chroot 격리로 서버 측 보안 설정 용이
💡개념

SSH 키 기반 SFTP 인증 설정

비밀번호 인증은 자동화에서 사용할 수 없습니다. 배치 스크립트가 비밀번호를 코드에 넣는 것은 보안상 금지입니다. SSH 키 기반 인증으로 패스워드 없이 자동 접속하는 구조를 만들어야 합니다.

로컬 터미널
# 1. 전용 SFTP 키 쌍 생성 (배치 작업용 별도 키 권장)
ssh-keygen -t ed25519 -f ~/.ssh/sftp_partner_key -N "" -C "sftp-batch@myapp"
# -N ""  → passphrase 없음 (자동화용)
# 생성 파일: ~/.ssh/sftp_partner_key (개인키)
#            ~/.ssh/sftp_partner_key.pub (공개키)

# 2. 개인키 권한 설정 (반드시)
chmod 600 ~/.ssh/sftp_partner_key
chmod 700 ~/.ssh/

# 3. 공개키를 파트너에게 전달 (보안 채널로)
cat ~/.ssh/sftp_partner_key.pub
# ssh-ed25519 AAAAC3NzaC1lZDI... sftp-batch@myapp
# 이 내용을 파트너 서버의 ~/.ssh/authorized_keys에 추가 요청

# 4. 접속 테스트
# StrictHostKeyChecking=no는 사용하지 않습니다. 파트너가 전달한 호스트 키 지문을
# 별도 채널로 확인해 ~/.ssh/known_hosts에 등록한 뒤 접속하세요.
sftp -i ~/.ssh/sftp_partner_key \
     batchuser@sftp-partner.example.com

# 5. SSH config로 편하게 관리 (~/.ssh/config)
# Host sftp-partner
#     HostName sftp-partner.example.com
#     User batchuser
#     IdentityFile ~/.ssh/sftp_partner_key
#     Port 22
#     StrictHostKeyChecking accept-new

# config 설정 후 접속
sftp sftp-partner
💡개념

파일 하나가 SFTP 배치로 오가는 순서 — 연결부터 후처리까지 6단계

새벽 2시에 도는 배치가 CSV를 올리고 결과 파일을 내려받습니다. 실패했을 때 "어느 단계에서 막혔나"를 알면 원인이 금방 좁혀집니다 — 연결에서 끊긴 것인지, 경로를 잘못 짚은 것인지, 전송은 됐는데 상대가 못 집은 것인지가 대응을 가릅니다. 아래는 파일 한 개가 배치 세션 안에서 지나는 6단계입니다.

TEXT
[cron 02:00]  sftp -i key -b cmds.txt batchuser@partner
   │
   ① 연결·인증   SSH 22 연결 → 키 인증 (BatchMode=yes, 비번 프롬프트 없이)
   │
   ② 탐색·이동   cd /upload · ls로 대상 경로·기존 파일 확인
   │              (chroot면 사용자에겐 /upload, 실제는 /sftp/user/upload)
   │
   ③ 전송        put은 임시 이름(.tmp)으로 올린 뒤 최종 이름으로 rename
   │              → 상대가 '쓰는 중' 파일을 집는 부분 전송 방지
   │
   ④ 무결성      원격 크기·md5를 로컬과 대조
   │
   ⑤ 후처리      .done 마커 업로드 / 결과 파일 get / 처리분 이동
   │
   ⑥ 종료        bye → exit code 확인 (0 성공 · 1 명령 실패 · 255 연결 실패)
   ▼
[로그 기록]  성공·실패와 체크섬을 파일로 남김 (감사 대비)

각 단계에서 무슨 일을 하고, 막히면 어떤 증상인가:

단계하는 일여기서 막히면
① 연결·인증SSH 22로 붙어 개인키로 인증 (BatchMode=yes)키 권한이 600보다 느슨 → Permissions too open으로 거부 / 호스트 키 변경 → exit 255(연결 자체 실패)
② 탐색·이동cd·ls로 대상 경로와 기존 파일 확인chroot 경로 착각 → 엉뚱한 위치에 업로드돼 상대가 "파일이 없다"
③ 전송put·get. 임시 이름으로 올린 뒤 원자적 rename최종 이름으로 바로 흘려 쓰면 상대가 반쯤 쓰인 파일을 집음(부분 전송)
④ 무결성원격 크기·md5sum을 로컬과 대조크기 다름 → 부분 전송(네트워크 단절) / 크기 같은데 해시 다름 → 전송 중 비트 오류·인코딩 변형
⑤ 후처리.done 마커·결과 다운로드·처리분 이동마커를 데이터보다 먼저 올리면 상대가 미완성 데이터를 집음 / 이동 누락 시 다음 배치가 같은 파일 재처리(중복)
⑥ 종료bye 후 exit code로 성공·실패 판정$? 확인을 sftp 바로 다음 줄에 안 두면 다른 명령이 코드를 덮어써 실패를 놓침

즉 배치가 실패했을 때 exit code가 1차 이정표입니다 — 255면 ①의 연결·인증(키 권한·호스트 키)에서, 1이면 ②~⑤의 어떤 sftp 명령(경로·권한)에서 멈춘 것이고, exit 0인데 상대가 "못 받았다"면 ③⑤의 가시성 문제(부분 전송·마커 순서)입니다. sftp -vvv로 어느 단계 로그까지 찍혔는지 보면 범위가 좁혀집니다. 인코딩은 ④를 통과해도(바이트는 동일) 상대 파서에서 깨질 수 있으므로, CSV 헤더·개행(CRLF vs LF)·문자셋은 연계 규약으로 미리 맞춰야 합니다.

SFTP 배치 스크립트

1SFTP 대화형 접속 및 기본 명령어

SFTP 접속 후 사용하는 기본 명령어를 익힙니다. 자동화 전에 대화형으로 먼저 경로와 권한을 확인합니다.

로컬 터미널
sftp -i ~/.ssh/sftp_key batchuser@sftp-server

# SFTP 프롬프트에서 사용하는 명령어
sftp> pwd            # 원격 현재 경로
sftp> ls -la         # 원격 파일 목록
sftp> cd /upload     # 원격 디렉터리 이동
sftp> lpwd           # 로컬 현재 경로 (l 접두어 = local)
sftp> lcd /tmp       # 로컬 디렉터리 이동
sftp> put data.csv   # 로컬→원격 업로드
sftp> get result.csv # 원격→로컬 다운로드
sftp> ls -la data.csv  # 업로드 후 원격 파일 크기 확인
sftp> bye            # 종료
sftp -i ~/.ssh/sftp_key batchuser@sftp-server
🔍실행 후 확인할 것
  • sftp 접속 시 비밀번호 프롬프트가 나오면 키 인증 실패 — ~/.ssh/authorized_keys 확인 전에 키 파일 권한부터 체크(chmod 600 ~/.ssh/sftp_key). 권한이 644 이상 느슨하면 SSH가 키를 무시함
  • sftp> 프롬프트가 나온 후 pwd 결과가 기대 경로와 다르면 — chroot 설정이 다른 경로를 가리키거나 사용자 홈 디렉터리 설정 오류. 이 상태에서 put 하면 파일이 엉뚱한 위치에 생성됨
  • put 성공 후 ls -la로 원격 파일 크기가 로컬과 동일해야 정상 — 크기가 0이면 전송 도중 연결이 끊어진 것. 1바이트라도 차이나면 md5sum 비교로 무결성 재확인 필요
2sftp -b 옵션으로 배치 업로드 스크립트 작성

-b 옵션은 명령어 파일을 stdin처럼 읽어 순차적으로 실행합니다. 이를 이용해 배치 업로드 스크립트를 만듭니다.

로컬 터미널
#!/bin/bash
# /opt/batch/scripts/upload_daily.sh

SFTP_HOST="sftp-partner.example.com"
SFTP_USER="batchuser"
SFTP_KEY="/home/appuser/.ssh/sftp_partner_key"
LOCAL_FILE="/opt/batch/data/export_$(date +%Y%m%d).csv"
REMOTE_DIR="/upload/incoming"
LOG_FILE="/opt/batch/logs/sftp_$(date +%Y%m%d).log"

echo "[$(date)] 배치 업로드 시작" >> "$LOG_FILE"

# SFTP 명령어 파일 생성 (임시)
SFTP_BATCH_FILE=$(mktemp)
cat > "$SFTP_BATCH_FILE" << 'SFTP_EOF'
cd /upload/incoming
put /opt/batch/data/export_20260530.csv
ls -la export_20260530.csv
bye
SFTP_EOF

# 실제 스크립트에서는 날짜를 동적으로 처리
REMOTE_FILENAME="export_$(date +%Y%m%d).csv"
printf "cd %s\nput %s\nls -la %s\nbye\n" \
    "$REMOTE_DIR" "$LOCAL_FILE" "$REMOTE_FILENAME" \
    > "$SFTP_BATCH_FILE"

# SFTP 실행
sftp -i "$SFTP_KEY" \
     -o BatchMode=yes \
     -o StrictHostKeyChecking=accept-new \
     -b "$SFTP_BATCH_FILE" \
     "${SFTP_USER}@${SFTP_HOST}" >> "$LOG_FILE" 2>&1

EXIT_CODE=$?
rm -f "$SFTP_BATCH_FILE"

if [ $EXIT_CODE -eq 0 ]; then
    echo "[$(date)] 업로드 성공" >> "$LOG_FILE"
else
    echo "[$(date)] 업로드 실패 (exit code: $EXIT_CODE)" >> "$LOG_FILE"
    # 알림 발송 등 추가 처리
    exit 1
fi
sftp -i /home/appuser/.ssh/sftp_key -b /tmp/sftp_commands.txt batchuser@sftp-server
🔍실행 후 확인할 것
  • 로그 파일에 "[날짜] 업로드 성공" 메시지를 먼저 확인 — 없으면 sftp -b 명령의 exit code 확인(echo $?). 0이면 정상, 1이면 sftp 명령 실패, 255면 SSH 연결 자체 실패
  • sftp -b exit code가 0인데 로그에 성공 메시지가 없으면 — 스크립트의 echo 출력 경로 오류. $? 체크가 sftp 실행 바로 다음 줄에 있어야 정확함(다른 명령이 중간에 있으면 $?가 덮어씌워짐)
  • 로컬과 원격 파일 크기가 같아도 md5sum 불일치가 나오면 — 전송 중 비트 오류로 파일 손상. SFTP 자체 체크섬 검증(put의 기본 동작)이 됐더라도 대용량 파일은 md5sum 비교를 추가로 수행할 것
3전송 완료 확인 — 파일 크기 비교와 md5 체크섬

파일이 전송됐다고 가정하지 말고, 실제로 완전히 전송됐는지 확인합니다. 두 가지 방법을 씁니다.

로컬 터미널
# 방법 1: 파일 크기 비교
LOCAL_SIZE=$(stat -c%s /opt/batch/data/export_20260530.csv)
REMOTE_SIZE=$(ssh -i ~/.ssh/sftp_key batchuser@sftp-server \
              "stat -c%s /upload/incoming/export_20260530.csv" 2>/dev/null)

if [ "$LOCAL_SIZE" = "$REMOTE_SIZE" ]; then
    echo "파일 크기 일치: ${LOCAL_SIZE} bytes"
else
    echo "크기 불일치! 로컬: ${LOCAL_SIZE}, 원격: ${REMOTE_SIZE}"
fi

# 방법 2: md5 체크섬 비교 (더 정확)
LOCAL_MD5=$(md5sum /opt/batch/data/export_20260530.csv | awk '{print $1}')
REMOTE_MD5=$(ssh -i ~/.ssh/sftp_key batchuser@sftp-server \
             "md5sum /upload/incoming/export_20260530.csv" | awk '{print $1}')

if [ "$LOCAL_MD5" = "$REMOTE_MD5" ]; then
    echo "체크섬 일치 — 전송 완료 확인"
else
    echo "체크섬 불일치 — 재전송 필요"
fi

# 방법 3: 마커 파일 방식 (파트너와 약속한 규약)
# 전송 완료 후 .done 파일 생성
sftp -i ~/.ssh/sftp_key batchuser@sftp-server << 'EOF'
put export_20260530.csv /upload/incoming/export_20260530.csv
symlink /upload/incoming/export_20260530.csv /upload/incoming/export_20260530.done
EOF
ssh -i ~/.ssh/sftp_key batchuser@sftp-server stat /upload/incoming/export_20260530.csv
🔍실행 후 확인할 것
  • ls -la ~/.ssh/sftp_key로 파일 권한을 먼저 확인 — "-rw-------" (600)이어야 SSH가 키를 사용함. 644 이상이면 "Permissions too open" 오류가 나며 키 인증 자체가 거부됨
  • 배치 스크립트 로그에 "업로드 성공"이 있고 원격 파일 크기가 로컬과 바이트 단위로 일치하면 전송 성공 — 크기는 같은데 md5sum이 다르면 전송 중 오류로 재전송 필요
  • md5sum 비교에서 두 해시값이 다른 경우와 크기 불일치인 경우를 구분 — 크기 불일치는 부분 전송(네트워크 단절), 크기 같은데 해시 불일치는 전송 중 비트 오류로 원인과 대처가 다름

chroot 보안 격리

💡개념

chroot — SFTP 사용자를 지정 디렉터리에 가두기

외부에서 SFTP로 접속하는 계정이 서버 전체 파일 시스템을 볼 수 있으면 보안 위험입니다. sshd_config의 chroot 설정으로 SFTP 사용자를 특정 디렉터리에 격리합니다.

로컬 터미널
# /etc/ssh/sshd_config 에서 SFTP 전용 그룹 chroot 설정
Match Group sftpusers
    ChrootDirectory /sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

# 주의: ChrootDirectory는 root 소유, 755 이상 권한이어야 함
# chroot 대상 경로 생성
sudo mkdir -p /sftp/batchuser/upload
sudo chown root:root /sftp/batchuser       # root 소유 필수
sudo chmod 755 /sftp/batchuser
sudo chown batchuser:sftpusers /sftp/batchuser/upload
sudo chmod 775 /sftp/batchuser/upload

chroot 경로 혼동 주의: chroot 설정 후 SFTP 사용자가 접속하면 /sftp/batchuser가 루트(/)로 보입니다. 사용자는 cd /upload로 이동하지만, 실제 서버 경로는 /sftp/batchuser/upload입니다. 파트너에게 경로를 안내할 때 사용자 관점의 경로(/upload)로 알려줘야 혼동이 없습니다.

배치 작업 패턴 — 안전한 파일 전송 구성확대

트러블슈팅

원인: 키 기반 인증에 필요한 파일의 권한이 잘못됐거나, 공개키가 서버에 올바르게 등록되지 않았습니다.

로컬 터미널
# 1. 클라이언트 측 권한 확인
ls -la ~/.ssh/
# drwx------  → .ssh 디렉터리: 700 이어야 함
# -rw-------  → 개인키: 600 이어야 함

# 권한 수정
chmod 700 ~/.ssh
chmod 600 ~/.ssh/sftp_partner_key

# 2. SSH 디버그 모드로 접속해 원인 확인
sftp -i ~/.ssh/sftp_partner_key -vvv batchuser@sftp-server 2>&1 | head -50
# "Offering public key" 후 "Server refused our key" 메시지 → 서버 측 authorized_keys 문제
# "Permission denied" 바로 나오면 → 클라이언트 키 권한 문제

# 3. 서버 측 authorized_keys 확인 (서버 접근 가능한 경우)
sudo cat /home/batchuser/.ssh/authorized_keys
# 공개키(sftp_partner_key.pub 내용)가 있는지 확인

# 4. 서버 측 .ssh 디렉터리 권한 확인
sudo ls -la /home/batchuser/.ssh/
# .ssh: 700, authorized_keys: 600 이어야 함
sudo chmod 700 /home/batchuser/.ssh
sudo chmod 600 /home/batchuser/.ssh/authorized_keys

# 5. SELinux 문제 (CentOS/RHEL)
sudo restorecon -Rv /home/batchuser/.ssh/

원인: chroot 설정으로 인해 사용자 관점의 경로와 실제 서버 경로가 다릅니다. 파트너에게 잘못된 경로를 알려줬거나, 파트너 시스템이 서버 실제 경로로 조회하고 있습니다.

로컬 터미널
# 1. SFTP 접속 후 현재 경로 확인
sftp -i ~/.ssh/sftp_key batchuser@sftp-server
sftp> pwd
# Remote working directory: /upload   ← 사용자 관점 경로
# (실제 서버 경로는 /sftp/batchuser/upload)

# 2. 서버 측에서 실제 파일 위치 확인
sudo find /sftp/batchuser -name "export_*.csv" -ls

# 3. 파트너에게 경로 재확인
# 파트너가 서버에서 직접 접근하는 경로: /sftp/batchuser/upload/파일명
# 파트너가 SFTP로 접근하는 경로: /upload/파일명
# 둘 다 동일한 파일을 가리키지만 표현이 다름

# 4. 업로드 후 즉시 경로 확인하는 검증 추가
sftp -i ~/.ssh/sftp_key batchuser@sftp-server << 'EOF'
put /opt/batch/data/export_20260530.csv
ls -la /upload/export_20260530.csv
EOF
# sftp 출력에 파일이 보이면 정상 업로드됨

심화 — 전송은 성공했는데 왜 사고가 나는가

💡개념

심화: 원자적 파일 가시성 — 크기·체크섬이 맞아도 상대는 '쓰는 중'에 집어간다

체크섬까지 대조했는데도 파트너가 "깨진 파일을 받았다"고 하는 사고가 있습니다. 원인은 전송 무결성이 아니라 파일이 언제부터 상대에게 보이는가입니다. 이 경합을 이해해야 배치가 간헐적으로만 터지는 유령 장애를 잡습니다.

  • put은 최종 이름으로 흘려 씁니다: put data.csv를 하는 순간부터 상대 디렉터리엔 data.csv가 0바이트에서 풀사이즈로 커지며 존재합니다. 상대의 수신 배치(cron 폴러)가 그 사이에 파일을 발견하면, 반쯤 쓰인 파일을 그대로 읽어 갑니다. 내 쪽 크기·md5 검증은 전송이 끝난 뒤라 이 순간을 못 막습니다.
  • 표준 해법은 원자적 이름 바꾸기: 임시 이름(.data.csv.tmp 같은 점 프리픽스)으로 올린 뒤, 전송이 끝나면 최종 이름으로 rename합니다. 같은 파일시스템 안의 rename은 원자적이라, 상대에겐 파일이 "없다가 완성된 채로 갑자기" 나타납니다.
  • rename이 막힌 상대라면 컨트롤 파일 규약: 데이터 파일을 다 올린 뒤 별도의 작은 .done/.ctl 마커를 마지막에 올리고, 상대는 마커가 있을 때만 데이터를 집습니다. 순서(데이터 먼저, 마커 나중)가 핵심입니다.
  • 한계: rename은 같은 파일시스템 안에서만 원자적입니다. 임시 파일과 최종 파일을 다른 마운트·다른 chroot 경로에 두면 rename이 복사로 바뀌어 경합이 되살아납니다. 반드시 같은 디렉터리(같은 마운트) 안에서 이름만 바꿔야 합니다.

그래서 전송 스크립트의 마지막 줄은 put이 아니라 rename(또는 마커 업로드)이어야 합니다.

상황: cron으로 도는 SFTP 배치가 어느 날부터 아무것도 못 올리고 종료 코드 255로 죽습니다. 로그엔 전송 시도조차 없습니다. 방화벽, 개인키 권한(600), 계정, 스크립트 모두 그대로라 원인이 안 잡힙니다. 배치 계정 HOME에서 sftp -vvv로 붙어 보면 인증 단계에 가기도 전에 끊깁니다.

원인: 파트너가 서버를 재구축·교체하면서 호스트 키(서버 신원)가 바뀌었습니다. 배치 계정의 ~/.ssh/known_hosts엔 옛 호스트 키가 핀(pin)돼 있어, SSH는 "서버 신원이 달라졌다 = 중간자 공격 가능성"으로 보고 연결을 거부합니다. StrictHostKeyChecking=accept-new처음 보는 호스트만 자동 등록할 뿐, 바뀐 키는 거부합니다 — 배치가 멈춘 것이 오히려 정상 방어입니다.

진단: sftp -vvv(배치 계정 HOME 기준) 출력에서 인증 전에 Host key verification failed 또는 REMOTE HOST IDENTIFICATION HAS CHANGED 경고가 뜹니다. ssh-keygen -F sftp-partner.example.com으로 known_hosts에 남은 옛 지문을 확인하고, 파트너가 공지한 새 지문과 다른지 대조합니다.

해결: 파트너에게 대역 외(전화·티켓)로 새 호스트 키 지문을 확인한 뒤, ssh-keygen -R sftp-partner.example.com으로 옛 항목을 지우고 검증한 새 키만 등록합니다. StrictHostKeyChecking=no로 끄거나 ssh-keyscan으로 무작정 덮으면 진짜 중간자 공격까지 통과시키므로 금물입니다. 서버 교체가 예정돼 있으면 파트너와 키 교체 일정을 미리 공유해 배치 중단을 예방합니다.

💼
실무 맥락
현업 패턴

실제 업무에서 이 지식이 쓰이는 상황:

외부 기관과의 파일 연계는 금융, 공공, 의료 도메인에서 특히 자주 있습니다. 실무에서 반복되는 세 가지 상황입니다.

1. 신규 외부 기관 연계 설정:

로컬 터미널
# 표준 체크리스트
# □ 전용 배치 계정 생성 (batchuser_파트너명)
# □ 전용 키 쌍 생성 (기존 키 재사용 금지)
# □ 공개키 전달 (보안 채널: 암호화된 이메일 또는 직접 전달)
# □ 개인키 권한 600 확인
# □ SSH config에 등록
# □ 방화벽 아웃바운드 22번 허용 (상대방 IP 명시)
# □ 접속 테스트 (sftp -vvv로 디버그)
# □ 배치 스크립트 crontab 등록

2. 배치 전송 실패 대응:

로컬 터미널
# 로그 먼저 확인
tail -50 /opt/batch/logs/sftp_$(date +%Y%m%d).log
# exit code 확인 → 0이 아니면 재전송
# 재전송 전 원격 파일 존재 여부 확인 (중복 방지)

3. 전송 파일 감사: 외부 기관과의 파일 연계는 감사 대상입니다. 무엇을 언제 보냈는지 로그와 체크섬을 파일로 남겨두는 것이 중요합니다. 장애 발생 시 "우리가 파일을 제대로 보냈는지"를 증명해야 할 때가 있습니다.


명령어·단축키 빠른 참조

이 모듈에서 다룬 SFTP 전송·키 인증·전송 검증 명령을 실전 옵션과 함께 모았습니다.

명령어/단축키용도자주 쓰는 예
sftp -i <키> user@host키 기반 대화형 접속접속 후 put/get/ls/cd
sftp -b <명령파일>배치(비대화) 자동 전송sftp -o BatchMode=yes -b cmds.txt user@host
put / get업로드 / 다운로드put data.csvls -la data.csv로 크기 확인
ssh-keygen -t ed25519배치 전용 키 쌍 생성ssh-keygen -t ed25519 -f ~/.ssh/sftp_key -N ""
chmod 600 <개인키>개인키 권한 잠금(필수)644면 "Permissions too open"으로 거부
ssh ... stat -c%s원격 파일 크기 비교로컬 stat -c%s와 대조해 전송 완료 확인
md5sum체크섬 무결성 대조로컬·원격 해시가 같아야 정상
ssh-keygen -F <host>known_hosts의 옛 지문 조회호스트 키 변경 여부 확인
ssh-keygen -R <host>바뀐 호스트 키 항목 제거대역 외 지문 검증 후에만 실행
ssh-keyscan호스트 키 수집(주의)무작정 덮으면 MITM 노출 — 지문 검증 병행
sftp -vvv접속 실패 디버깅인증·호스트키 단계 로그 확인
rsync -avP대용량 증분·이어받기 동기화rsync -avP dir/ user@host:/dir/
restorecon -RvSELinux 컨텍스트 복구(RHEL).ssh 키 인증 거부 시

관련 모듈로 더 깊이:

다음 모듈에서는 JDBC Connection Pool 설정과 DB 장애 시 서비스 격리 실무를 다룹니다.

지식 확인

퀴즈 — 8문제

Q1

보험사 SFTP 서버에 매일 새벽 CSV 파일을 자동으로 업로드하고, 결과 파일을 가져오는 배치 스크립트를 작성해야 합니다. 이 작업에 SCP 대신 SFTP를 선택해야 하는 이유는?

Q2

SSH 개인키 파일 권한을 600으로 설정해야 하는 이유는?

Q3

파일을 업로드했는데 상대방 시스템이 파일을 처리하지 못한다. 가장 먼저 확인할 사항은?

Q4

배치 파일 전송이 완료됐음을 확인하는 가장 안전한 방법은?

Q5

외부 협력사에 SFTP 계정을 내줘야 하는데, 그 계정이 서버의 다른 디렉터리를 돌아다니지 못하게 하려면?

Q6

수백 GB 디렉터리를 매일 원격으로 동기화하는데, 매번 전체를 SCP로 보내니 시간이 너무 걸린다. rsync가 더 적합한 이유는?

Q7

[심화] 크기·md5 체크섬 검증까지 통과했는데도 파트너가 깨진 파일을 받았다고 한다. 전송 무결성 문제가 아니라면 무엇 때문인가?

Q8

[심화] 어제까지 정상이던 새벽 SFTP 배치가 오늘부터 exit 255로 전부 실패한다. 방화벽·키 권한·계정은 그대로이고, -vvv로 붙어 보면 인증 단계 전에 끊긴다. 가장 유력한 원인은?

0 / 8 답변

🧪 실습으로 확인하기

Nginx 설치 및 기동

초급

Linux 서버에 Nginx를 설치하고 systemd 서비스로 등록하여 80포트에서 응답하는 상태까지 만든다.

40📋 3단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요