Mountain Duck SFTP: VPN 이후의 두 번째 로그인

VPN이 연결되고 메뉴 막대에 터널이 표시되는데도 Mountain Duck은 여전히 로그인을 요구합니다. 그러고 나서 코드를 요구합니다. 고장 난 것이 아니라, 서로 다른 두 시스템이 당신을 인증하고 있고, 두 번째는 첫 번째에 대해 들어본 적이 없습니다. VPN의 MFA는 게이트웨이에 무언가를 증명합니다. SFTP 서버는 자기 계정에 대해 자기 증명을 요구합니다.

두 개의 프롬프트, 두 개의 시스템

게이트웨이와 파일 서버는 별개의 정책 영역입니다. 디렉터리를 공유할 수도 있고, 사용하는 사람 외에는 공통점이 없을 수도 있습니다. VPN에서 일회용 코드를 통과시켜도 SFTP 호스트에 세션이 생기지 않으며, SFTP 호스트는 터널을 사용했는지조차 알 수 없습니다. 각 시스템은 자신만 묻고 있다고 믿습니다.

세 가지를 메모에서 별개의 행으로 다루십시오. 하나가 실패하면 그 행이 어느 콘솔을 열지 알려 주고, 작업의 대부분은 그것입니다.

SFTP 관리자의 주소 사용

북마크에는 파일 서비스가 실제로 수신 대기하는 호스트 이름과 포트가 필요하며, 그것이 반드시 VPN 서버의 주소는 아닙니다. SFTP 서비스를 운영하는 관리자에게 물어보고, 다른 클라이언트가 쓰는 것과 같은 호스트 이름을 사용하십시오.

서버 신원 검사는 그대로 두십시오. Mountain Duck과 Cyberduck은 첫 연결에서 호스트 키를 보여 주며, 관리자가 다른 경로로 제공한 값과 그것을 비교하는 것이 잘못된 서버가 당신의 자격 증명을 받지 못하게 막는 단계입니다. 북마크가 연결되게 하려고 그 검사를 끄는 것은 편의로 위장한 영구적인 결정입니다. 그것은 파일이 의도한 곳으로 갔다는 나중의 유일한 증거도 없앱니다.

서버가 보내는 챌린지에 응답

프로젝트의 SFTP 문서는 최초 로그인 프롬프트가 있고 이어서 서버가 요청할 때 코드를 위한 두 번째 프롬프트가 있는 일회용 코드의 챌린지-응답 지원을 설명합니다. 이 흐름은 서버 구성에 속하며, 클라이언트가 암호 필드에 다른 값을 저장하는 것으로 서버 측 이중 인증을 강제할 수는 없습니다.

따라서 북마크에는 일반 계정 자격 증명이 들어가야 하고, 코드는 프롬프트가 나타날 때 입력해야 합니다. 변하는 코드를 영구 암호로 저장하면 한 번만 작동하고 그다음에는 잘못된 암호처럼 보이는 방식으로 실패하는 북마크가 됩니다. 코드를 VPN 자격 증명 필드에 넣으면 게이트웨이가 거부하고 터널은 절대 올라오지 않는다는 식으로 다르게 실패합니다. 두 개의 프롬프트, 두 개의 장소이며, 그것을 맞바꾸면 둘 다 깨집니다.

자동 마운트는 버튼을 누를 수 없다

북마크가 백그라운드에서 다시 연결되면 대화형 챌린지에 응답할 사람이 없습니다. 마운트가 재시도하고 서버가 다시 묻고, 로그는 성공할 수 없는 시도로 가득 찹니다. 그것이 사람을 요구하는 정책의 정직한 결과입니다.

당신이 있을 때 터널과 북마크를 연결하고 이후의 자동 재연결은 최선의 시도로 다루도록 상호작용을 계획하십시오. 워크플로에 정말로 무인 접근이 필요하다면 서버 소유자가 다른 인증 방식을 승인해야 하며, 그것은 북마크 설정이 아니라 정책 변경입니다.

마운트는 권한이 아니다

마운트된 볼륨은 세션이 인증되었음을 증명합니다. 그 서버 어디에나 계정이 쓸 수 있다는 것을 증명하지는 않습니다. 의도한 폴더를 확인하고, 정말로 필요한 작업을 시도하고, 답이 중요할 때는 서버 쪽에서 결과를 확인하십시오. Finder 사이드바는 볼륨을 보여 줄 뿐 그 뒤의 권한에 대해서는 아무 말도 하지 않습니다.

다른 프로토콜이라면 이 순서를 복사하는 대신 그 공급자가 문서화한 인증 방법을 사용하십시오. 클라우드 로그인과 SSH 챌린지는 사이드바에서 똑같아 보일 수 있지만 속은 전혀 다르게 동작합니다.