SFTP 포트 가이드: SSH를 통한 보안 파일 전송

SFTP는 암호화가 추가된 FTP가 아닙니다. 이는 SSH 세션 내에서 실행되는 별도의 프로토콜입니다. 클라이언트는 SSH 서버에 연결하고 비밀번호, 키, 인증서 또는 기타 SSH 지원 방법으로 인증한 다음 SFTP 하위 시스템을 시작하여 디렉터리 나열, 파일 업로드, 파일 다운로드, 경로 이름 변경 및 권한 관리를 수행합니다.

SFTP는 SSH를 기반으로 하기 때문에 SSH 암호화, 호스트 키 확인 및 성숙한 인증 제어의 이점을 누릴 수 있습니다. 따라서 대부분의 배포에서 SFTP 포트는 TCP 22입니다. 일부 조직에서는 백그라운드 검색 소음을 줄이기 위해 SSH 및 SFTP를 다른 포트로 이동하지만 포트를 변경해도 인증 및 권한 부여 제어가 대체되지는 않습니다.

클래식 FTP는 일반적으로 명령용으로 포트 21을 사용하고 전송용으로 별도의 데이터 포트를 사용합니다. 이는 방화벽과 NAT를 더욱 복잡하게 만들고 일반 FTP는 암호화 없이 자격 증명과 데이터를 보냅니다. FTPS는 FTP에 TLS를 추가하지만 여전히 명령 및 데이터 채널이 있는 FTP 모델을 유지합니다.

SFTP는 하나의 SSH 연결을 사용하는데, 이는 일반적으로 방화벽을 통과하고 감사하기가 더 쉽습니다. SCP도 SSH를 사용하지만 SFTP는 보다 풍부한 파일 관리 작업을 제공하며 대화형 전송, 파트너 삭제 및 자동화된 파일 워크플로에 더 나은 기본값입니다.

파트너, 자동화 작업, 백업 프로세스, 배포 파이프라인 또는 내부 팀이 서버와 안전하게 파일을 교환해야 하는 경우 SFTP 액세스를 엽니다. 일반적인 예로는 공급업체 데이터 피드, 야간 내보내기, 로그 수집, 보안 문서 전달, 고객 또는 현장 장치에 대한 제어된 업로드 영역 등이 있습니다.

SFTP가 암호화됐다고 해서 널리 노출시키지 마세요. 인터넷 연결 SSH 서비스는 자격 증명 공격과 자동 검색을 유도합니다. 소규모 그룹에만 액세스가 필요한 경우 소스 IP를 제한하고, VPN 또는 개인 네트워크 뒤에 SFTP를 게시하거나, 더 강력한 정책 제어가 가능한 관리형 전송 게이트웨이를 사용하세요.

SFTP용 포트 22를 열기 전에 SSH 서버가 설치되어 실행 중이며 SFTP 하위 시스템을 허용하도록 구성되어 있는지 확인하세요. 그런 다음 연결해야 하는 사용자 또는 서비스 계정, 볼 수 있는 디렉터리, 비밀번호 인증 허용 여부, 업로드 및 다운로드 기록 방법을 결정합니다.

계정 인증과 네트워크 연결성을 분리합니다. 포트 검사기는 인터넷에서 TCP 22에 연결할 수 있는지 여부를 표시할 수 있지만 특정 사용자가 로그인할 수 있는지 또는 chroot 디렉터리가 올바른지 증명할 수는 없습니다. SFTP 클라이언트 또는 SSH 명령줄 테스트를 사용하여 애플리케이션 수준 동작을 확인하세요.

Windows Server에서 OpenSSH 서버를 설치 및 활성화하고, Windows Defender 방화벽에서 인바운드 TCP 22를 허용하고, sshd 서비스가 실행 중인지 확인합니다. 서버가 클라우드 환경에 있는 경우 클라우드 방화벽이나 보안 그룹에서도 포트 22를 허용합니다. 광범위한 관리자 액세스보다는 전용 계정을 사용하십시오.

Linux에서는 OpenSSH 서버를 설치하고, sshd가 포트 22에서 수신 대기하는지 확인하고, sshd_config에서 SFTP 하위 시스템이 활성화되어 있는지 확인하세요. 제한된 파일 전송 계정의 경우 사용자가 대화형 셸을 얻을 수 없도록 chroot 디렉터리, 소유권 규칙 및 ForceCommand 내부-sftp를 구성합니다.

macOS에서는 내장된 SSH 서비스를 통해 SFTP를 사용할 수 있습니다. 로컬 네트워크, 개발 머신 또는 랩 환경에 가장 자주 사용됩니다. 신뢰할 수 있는 네트워크 외부에 노출하는 경우 서버에서 사용하는 것과 동일한 키 기반 인증 및 방화벽 규칙을 적용하세요.

공개 호스트 이름이나 IP 주소 및 포트 22에 대해 외부 포트 확인으로 시작합니다. 포트가 열려 있으면 SSH 서비스에 대한 TCP 경로에 연결할 수 있습니다. 그런 다음 SFTP 클라이언트를 사용하거나 sftp user@example.com을 실행하여 인증, 호스트 키 신뢰, 디렉터리 액세스 및 업로드 권한을 확인하세요.

더 낮은 수준의 세부 정보가 필요한 경우 ssh -vvv user@example.com을 사용하여 SSH 핸드셰이크를 테스트하거나 ss -tlnp, netstat 또는 PowerShell을 사용하여 서버의 리스너를 확인하세요. 클라우드 서버의 경우 두 계층 모두 연결을 허용해야 하므로 호스트 방화벽 규칙을 클라우드 보안 그룹과 비교하세요.

SFTP 포트가 닫힌 것으로 표시되면 sshd가 실행 중이 아니거나, 다른 포트에서 수신 대기 중이거나, 호스트 방화벽에 의해 차단되었을 수 있습니다. 확인 시간이 초과되면 클라우드 보안 그룹, 라우터 NAT 규칙, ISP 필터, VPN 정책 또는 소스 IP 허용 목록이 패킷이 서버에 도달하기 전에 패킷을 삭제할 수 있습니다.

포트가 열려 있지만 SFTP 로그인에 실패한 경우 사용자 이름, 키 권한, 비밀번호 정책, MFA 요구 사항, 허용된 사용자, chroot 소유권, ForceCommand 규칙 및 서버 로그를 검사하세요. 일반적인 실수는 사용자에게 chroot 디렉토리 쓰기 권한을 부여하는 것입니다. OpenSSH에서는 chroot가 안전하게 작동하려면 특정 소유권 및 권한 패턴이 필요합니다.

비밀번호보다 SSH 키나 인증서 기반 인증을 선호합니다. 루트 로그인을 비활성화하고, 연결할 수 있는 사용자를 제한하고, 키를 순환하고, 사용하지 않는 계정을 제거하고, 암호나 하드웨어 지원 스토리지로 개인 키를 보호하세요. 파트너 액세스의 경우 파트너당 하나의 계정을 생성하여 활동을 명확하게 표시하고 취소할 수 있습니다.

chroot 또는 제한된 범위의 디렉터리를 사용하여 파일 시스템 액세스를 제한하고, 필요한 경우를 제외하고 쓰기 가능한 공유 폴더를 피하고, 로그인 실패 및 비정상적인 전송 볼륨을 모니터링합니다. SFTP가 인터넷에 연결된 경우 속도 제한, 소스 허용 목록, 침입 탐지 및 SSH 서버의 정기 패치를 결합합니다.