SFTP를 통한 scp: 실제로 해석되는 원격 경로 쓰기

수년간 스크립트에서 작동하던 scp 명령이 현재 클라이언트에서 터널과 아무 관련 없는 경로 오류로 실패할 수 있습니다. VPN은 바이트를 운반했지만, 클라이언트는 서버가 해석할 수 없는 이름을 서버에 요청했습니다. 현재 OpenSSH scp는 기본적으로 SFTP로 전송하며, SFTP는 예전 프로토콜처럼 셸 방식 확장을 하지 않습니다. 명령을 자신의 계정에서 바깥으로 따라가면 경로가 실제로 어디서 해석되는지 보입니다.

계정에서 시작하고, 그다음 쓸 수 있는 디렉터리에서 시작하세요

콜론은 두 이름 공간을 나누며, 왼쪽만 입력 중인 컴퓨터에 속합니다. 그 뒤의 모든 것은 서버가 인증한 계정 아래에서, 그 계정이 가진 파일 시스템 보기 안에서 해석합니다. 명령을 구성하기 전에 둘 다 확인하세요. 관리자에게 맞는 경로가 전송 사용자에게도 자동으로 맞는 것은 아닙니다. 이 차이가 네트워크 장애처럼 보이는 대부분의 권한 오류 원인입니다.

서버에 그 자체의 보기를 물어보세요: ssh [email protected] pwd 및 ssh [email protected] ls -ld /srv/archive. 두 번째 명령이 권한 거부를 보고하면 터널은 정상이고 그 계정에는 경로를 쓸 수 없습니다. 전송이 진행되도록 권한을 넓히는 대신 소유권을 고치거나 다른 대상을 고르세요.

제한된 SFTP 구성은 chroot를 파일 시스템의 루트로 제시할 수 있습니다. 그 보기 안에서 절대 경로는 chroot 안의 절대 경로이며, 관리자가 호스트에서 보는 위치와 같지 않습니다.

콜론의 양쪽을 명시적으로 지정하세요

업로드는 로컬 기본 이름이 반대편에서 받아들여질 것이라고 가정하지 말고 원격 파일 이름을 밝혀야 합니다.

scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csv

다운로드는 정확히 같은 이유로 로컬 대상을 밝혀야 합니다. 두 이름 공간은 독립적이며, 일치한다고 가정하는 스크립트는 원격 트리가 다른 배치를 쓰는 첫 순간 깨집니다.

scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csv

유지 관리하는 스크립트에서는 ~otheruser를 피하세요. 다른 계정의 홈 디렉터리를 확장하는 것은 원격 셸 기능이었고, SFTP 서버는 이를 흉내 내는 확장을 구현하지 않을 수 있습니다. 계정이 실제로 열 수 있는 절대 경로를 쓰고, 공백이 있는 로컬 경로는 서버의 셸을 위해 쓰인 따옴표 층을 복사하지 말고 따옴표로 감싸세요.

당신의 scp가 실제로 어떤 프로토콜을 쓰는지 아세요

OpenSSH 9.0부터 클라이언트는 기본적으로 SFTP를 사용하며, 배포판은 자체 일정에 따라 그 동작을 채택하거나 백포트합니다. 버전 문자열은 클라이언트의 의도를 알려 주지만 공급업체 빌드는 업스트림과 다를 수 있으므로 실제로 실행하는 클라이언트를 확인하세요: ssh -V.

두 프로토콜은 이름을 다르게 해석합니다. 예전 SCP는 원격 사용자 셸에 경로 확장을 요청하므로 와일드카드와 물결표를 그 셸이 자체 규칙으로 처리합니다. SFTP는 대신 파일 전송 작업을 내보내므로 와일드카드는 클라이언트가 확장하거나 전혀 확장되지 않습니다. 둘 다 SSH 안에서 같은 컴퓨터로 가므로 한 호스트가 두 클라이언트 아래에서 다르게 동작할 수 있습니다.

scp -v는 요청하는 하위 시스템을 출력하고, sftp 하위 시스템 줄은 최신 경로가 사용 중임을 확인합니다. scp -O는 지원되고 정말 필요한 곳에서 예전 프로토콜을 강제하며, 자체 인용 규칙도 함께 되돌립니다. 이것은 VPN 옵션이 아니고, 서버에서 무언가를 활성화하는 방법도 아니며, 호스트 키 검사를 느슨하게 할 이유도 아닙니다.

스크립트가 의존하기 전에 경로를 시험하세요

경로 문제는 아무도 지켜보지 않는 밤의 자동 작업에서 최악의 순간에 드러납니다. 먼저 작은 파일과 작업이 쓰는 정확한 계정으로 대상을 증명하고, 그 테스트 명령을 작업 정의 옆에 두세요. 테스트에 다른 계정이나 다른 디렉터리가 필요하면 작업에도 필요합니다.

서버 쪽도 확인하세요. grep -i subsystem /etc/ssh/sshd_config는 SFTP 하위 시스템이 구성되었는지 보여 주고, sftp -b /dev/null [email protected]는 그 하위 시스템이 응답할 때만 성공적으로 종료됩니다. SSH 로그인은 받아들이지만 하위 시스템이 없는 호스트는 로그인 테스트에서 완전히 건강해 보여도 모든 최신 전송에서 실패합니다.

클라이언트 버전, 사용 중인 프로토콜, 절대 원격 경로를 작업 메모에 기록하세요. 다음 업그레이드가 기본값을 바꿀 때, 그 메모가 다섯 분짜리 수정과 한나절 추측의 차이입니다.