보험사와 데이터를 연계하는 업무를 맡았습니다. 매일 새벽 2시에 CSV 파일을 상대방 SFTP 서버에 올리고, 처리 결과 파일을 내려받아야 합니다. 처음에는 수동으로 했는데 이제 자동화해야 합니다. 개인키 인증 설정, 파일 올리는 스크립트, 전송 완료 확인 — 어떻게 하면 될까요?
외부 기관 파일 연계는 생각보다 자주 있는 업무입니다. SFTP 구조와 키 기반 인증, 배치 자동화 패턴을 실무 중심으로 익혀봅니다.
- 1SFTP, SCP, rsync의 차이를 설명하고 상황에 맞게 선택할 수 있다
- 2SSH 키 기반 SFTP 인증을 설정하고 연결을 테스트할 수 있다
- 3sftp -b 옵션으로 배치 업로드 스크립트를 작성할 수 있다
- 4전송 완료 여부를 파일 크기 비교와 md5 체크섬으로 검증할 수 있다
- 5chroot 격리의 개념과 경로 혼동 문제를 설명할 수 있다
파일 전송 도구 비교
SFTP vs SCP vs rsync — 언제 무엇을 쓰나
파일을 원격으로 전송하는 도구가 여러 개 있어 헷갈립니다. 각각 강점이 다르고, 외부 기관 연계에 적합한 것은 SFTP입니다.
확대
보험사와 파일 연계를 시작했는데, 자동화 스크립트가 매일 새벽 실패합니다. 어제는 SCP로 올렸더니 상대방이 "파일이 안 보인다"고 하고, rsync를 써보니 방화벽에서 막힙니다. 파트너사마다 요구하는 전송 방식이 다르고, 각 도구의 동작 방식을 모르면 장애 원인도 파악하기 어렵습니다. 외부 기관 파일 연계에서 가장 많이 쓰이는 도구는 SFTP입니다. 포트 22번 하나로 디렉터리 탐색, 업로드, 다운로드, 권한 확인을 모두 처리할 수 있어 방화벽 규정을 충족하기 쉽고, 대부분의 금융·공공 기관 시스템이 SFTP 서버를 표준으로 운영합니다.
| 도구 | 전송 방식 | 대화형 | 배치 | 증분 동기화 | 재시작 | 주 사용 |
|---|---|---|---|---|---|---|
| SCP | SSH 위 복사 | 불가 | 가능 | 불가 | 불가 | 단순 파일 복사 |
| SFTP | SSH 서브시스템 | 가능 | 가능 | 불가 | 부분 가능 | 외부 기관 연계 |
| rsync | SSH + 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단계입니다.
[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 배치 스크립트
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 비교로 무결성 재확인 필요
-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 비교를 추가로 수행할 것
파일이 전송됐다고 가정하지 말고, 실제로 완전히 전송됐는지 확인합니다. 두 가지 방법을 씁니다.
# 방법 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.csv → ls -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 -Rv | SELinux 컨텍스트 복구(RHEL) | .ssh 키 인증 거부 시 |
관련 모듈로 더 깊이:
- 써드파티 API와 공공 인프라 연계 실무 — 파일 외에 API로 외부 기관과 연계하는 방식
- Cron/Quartz 장애 분석과 배치 재처리 실무 — SFTP 송수신을 자동화하는 배치·스케줄러 운영
- SSH 접속 보안 강화와 배스천 호스트 기반 접근 제어 — SFTP의 기반인 SSH 키 인증과 접근 제어
다음 모듈에서는 JDBC Connection Pool 설정과 DB 장애 시 서비스 격리 실무를 다룹니다.