VPN을 통한 SSHFS 마운트는 사용자 세션이 소유해야 합니까?

VPN이 올라온 뒤 공유 폴더를 마운트하는 일에는 혼동하기 쉬운 두 가지 신원이 관련됩니다: 네트워크를 구성할 권한이 있는 구성 요소와 파일 서버에 로그인할 권한이 있는 계정. 둘이 같은 경우는 드뭅니다. root 소유의 VPN 훅은 데스크톱 사용자의 SSHFS 마운트를 시작하기에 나쁜 장소인데, 사용자의 에이전트도 의도된 마운트 소유권도 없기 때문입니다. 소유권을 먼저 올바르게 정하면 트리거는 단순해집니다.

두 신원, 두 개의 별도 권한

VPN 클라이언트는 경로와 인터페이스를 변경할 권한이 필요합니다. SSHFS 마운트에는 파일 서버가 허용하는 SSH 신원과 파일을 읽을 계정이 소유한 FUSE 마운트가 필요합니다. root로 실행되는 스크립트 하나는 첫 번째 요구를 충족하고 두 번째를 조용히 깨뜨립니다.

root로 마운트하면 파일이 데스크톱 세션 밖에 남고 사용자의 키를 보관하는 에이전트에 접근하지 못할 수 있습니다. 마운트는 존재하지만 사용자가 그를 통해 쓸 수 없고, 실패는 서버 측 권한 문제처럼 보입니다. 그 오진은 반나절과 스토리지 팀에 보낼 티켓을 낭비합니다.

자동화를 작성하기 전에, 그 선택이 트리거가 사는 위치와 도달할 수 있는 자격 증명을 결정하기 때문에, 어느 계정이 마운트를 소유하는지 결정하세요.

먼저 손으로 사용자 소유 마운트를 설정하세요

빈 마운트 지점, 승인된 SSH 계정, 터널을 통한 서버로의 작동 경로를 가진 로그인 사용자에서 시작하세요. 수동 마운트는 모든 자동화가 재현해야 하는 기준선을 설정합니다.

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

이름은 예시이므로 서버가 실제로 제공하는 호스트와 내보내기 경로로 바꾸세요. 첫 연결에서 승인된 절차를 통해 호스트 키를 확인하세요. VPN 계정 비밀번호가 자동으로 스토리지 계정의 자격 증명이 아니라는 점에 유의해야 하며, 이것이 실패한 시도의 흔한 원인입니다.

해당 사용자가 소유한 마운트 지점으로 일반 사용자로 실행하세요. 기본적으로 마운트하는 계정만 파일에 도달하며 allow_other는 그 경계를 모든 로컬 사용자로 넓힙니다. 이는 의도적인 접근 확대이지 자동화를 위한 우회가 아닙니다.

트리거가 같은 세션 컨텍스트에서 작동하게 하세요

지원되는 VPN 이벤트 통합이 사용자 세션 작업을 실행하도록 요청하게 하되, 권한 있는 콜백이 데스크톱 자격 증명을 빌릴 수 있다고 가정하지 마세요. 트리거를 우연히 tun0라는 인터페이스가 아니라 의도된 연결 식별자로 제한하세요. 잘못된 대상과 일치하는 디스패처 규칙은 이 마운트와 무관한 변경을 포함해 모든 네트워크 변경에서 발동합니다.

작업은 예상 호스트 이름을 확인하고, 기존 마운트를 알아차리고, 한 번의 제한된 시도를 해야 합니다. 몇 초마다 새 SSHFS 프로세스를 시작하거나 서버가 중단된 동안 자격 증명 프롬프트를 재시도하는 폴링 루프는 짧은 장애를 막힌 프로세스 더미로 바꿉니다. 시도를 타임아웃과 한 번의 재시도로 제한하세요.

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

첫 번째 명령은 디스패처가 일치시켜야 할 연결 식별자를 제공합니다. 나머지 두 개는 시도가 이미 실행 중인지 보여 주며, 이것이 중복을 막는 확인입니다.

무인 서비스는 자체 실행 컨텍스트에서 자체 승인된 자격 증명과 자체 호스트 확인을 갖추어야 합니다. 그래픽 에이전트가 잠금 해제되어 있다고 가정할 수 없으며, 잠금을 해제하려고 시도해서도 안 됩니다.

강제 정리 전에 연결 해제를 계획하세요

계획된 연결 해제의 경우 파일 작업을 마치고 마운트하는 사용자 자신의 워크플로에서 마운트를 해제하세요. 프로세스가 아니라 마운트 지점을 대상으로 하고, 성공을 보고하기 전에 결과를 확인하세요.

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

이 워크플로가 만든 마운트만 해제하고, 사용 중이라면 그것은 애플리케이션의 결정입니다. 훅이 성공을 반환하게 하려고 존재하는 강제 분리는 데이터 손실을 막는 대신 숨깁니다.

예기치 않은 손실은 다르게 동작합니다. SSHFS는 네트워크 중단이 파일 시스템 작업을 차단할 수 있으며 reconnect 옵션이 핸들을 복원하지 않고 전송을 복원한다고 문서화합니다. 재연결 전에 연 파일은 다음 쓰기에서 실패할 수 있고 중단된 쓰기는 보존되지 않습니다. 이 차이는 파일 하나를 몇 시간씩 열어 두는 편집자에게 가장 중요하므로, 복구를 가정하지 말고 다시 여는 단계를 계획하세요.

의존하기 전에 일회용 파일로 동작을 테스트하세요. 터널이 돌아온 뒤 디렉터리가 다시 나타난다고 해서 이전 핸들이나 저장되지 않은 작업이 살아남았다는 증거는 아닙니다.