Mountain Duck SFTP: a doua autentificare după VPN

VPN-ul se conectează, bara de meniu arată un tunel, iar Mountain Duck cere totuși o autentificare. Apoi cere un cod. Nimic nu este stricat: două sisteme diferite vă autentifică, iar al doilea nu a auzit niciodată de primul. MFA-ul VPN-ului dovedește ceva gateway-ului. Serverul SFTP cere propria dovadă, față de propriul cont.

Două solicitări, două sisteme

Gateway-ul și serverul de fișiere sunt domenii de politică separate. Pot împărți un director sau nu pot avea nimic în comun în afară de persoana care le folosește. Trecerea unui cod de unică folosință la VPN nu creează o sesiune pe gazda SFTP, iar gazda SFTP nu poate ști dacă ați folosit un tunel. Fiecare sistem crede că este singurul care întreabă.

Tratați cele trei ca rânduri separate în notele dumneavoastră. Când unul eșuează, rândul vă spune ce consolă să deschideți, și aceasta este cea mai mare parte a muncii.

Folosiți adresa administratorului SFTP

Un marcaj are nevoie de numele de gazdă și portul pe care serviciul de fișiere ascultă cu adevărat, care nu este neapărat adresa serverului VPN. Întrebați administratorul care administrează serviciul SFTP și folosiți același nume de gazdă ca ceilalți clienți.

Păstrați intactă verificarea identității serverului. Mountain Duck și Cyberduck afișează cheia de gazdă la prima conexiune, iar compararea ei cu o valoare pe care administratorul o furnizează pe alt canal este pasul care împiedică un server greșit să vă primească acreditările. Dezactivarea acestei verificări ca un marcaj să se conecteze este o decizie permanentă deghizată în comoditate. Elimină și singura dovadă pe care ați avea-o mai târziu că fișierul a ajuns unde intenționați.

Răspundeți provocării trimise de server

Documentația SFTP a proiectului descrie suportul provocare-răspuns pentru coduri de unică folosință: o solicitare inițială de autentificare, apoi o a doua solicitare pentru cod, după cum cere serverul. Fluxul aparține configurației serverului, iar un client nu poate adăuga impunerea autentificării în doi factori pe partea serverului stocând altă valoare în câmpul de parolă.

Deci marcajul ar trebui să conțină acreditările obișnuite ale contului, iar codul ar trebui tastat când apare solicitarea. Stocarea unui cod care se schimbă ca parolă permanentă produce un marcaj care funcționează o dată, apoi eșuează într-un mod care arată ca o parolă greșită. Punerea codului în câmpul de acreditări al VPN-ului eșuează altfel: gateway-ul îl respinge, iar tunelul nu se ridică niciodată. Două solicitări, două locuri, iar schimbarea lor le strică pe amândouă.

Montarea automată nu poate apăsa un buton

Dacă marcajul se reconectează în fundal, o provocare interactivă nu are cine să răspundă. Montarea reîncearcă, serverul întreabă din nou, iar jurnalul se umple cu încercări care nu pot reuși. Acesta este rezultatul onest al unei politici care cere o persoană.

Planificați interacțiunea: conectați tunelul și marcajul cât timp sunteți prezent, apoi tratați reconectările automate ulterioare ca efort optim. Dacă fluxul de lucru are cu adevărat nevoie de acces nesupravegheat, proprietarul serverului trebuie să aprobe altă soluție de autentificare, ceea ce este o schimbare de politică, nu o setare a marcajului.

Montarea nu este o permisiune

Un volum montat dovedește că o sesiune a fost autentificată. Nu dovedește că contul poate scrie oriunde pe acel server. Verificați folderul vizat, încercați operațiunea de care aveți cu adevărat nevoie și confirmați rezultatul din partea serverului când răspunsul contează. Bara laterală din Finder arată un volum; nu spune nimic despre permisiunile din spate.

Pentru alt protocol, folosiți metoda de autentificare documentată a acelui furnizor în loc să copiați această secvență. O autentificare în cloud și o provocare SSH pot arăta identic în bara laterală și se pot comporta complet diferit dedesubt.