Mountain Duck SFTP: die tweede aanmelding ná die VPN

Die VPN verbind, die kieslysbalk wys ’n tonnel, en Mountain Duck vra steeds vir ’n aanmelding. Dan vra dit vir ’n kode. Niks is stukkend nie: twee verskillende stelsels verifieer jou, en die tweede een het nog nooit van die eerste gehoor nie. Die VPN se MFA bewys iets aan die poort. Die SFTP-bediener vra sy eie bewys, teen sy eie rekening.

Twee opdragte, twee stelsels

Die poort en die lêerbediener is afsonderlike beleidsdomeine. Hulle deel dalk ’n gids, of het dalk niks gemeen buiten die persoon wat hulle gebruik nie. Om ’n eenmalige kode by die VPN in te voer skep nie ’n sessie op die SFTP-gasheer nie, en die SFTP-gasheer kan nie sien of jy hoegenaamd ’n tonnel gebruik het nie. Elke stelsel dink hy is die enigste een wat vra.

Behandel die drie as afsonderlike rye in jou notas. Wanneer een faal, sê die ry watter konsole oop te maak, en dit is die grootste deel van die werk.

Gebruik die SFTP-administrateur se adres

’n Boekmerk het die gasheernaam en poort nodig waarop die lêerdiens werklik luister, wat nie noodwendig die VPN-bediener se adres is nie. Vra die administrateur wat die SFTP-diens bestuur, en gebruik dieselfde gasheernaam wat ander kliënte gebruik.

Hou die bedieneridentiteit se kontrole ongeskonde. Mountain Duck en Cyberduck wys die gasheersleutel by die eerste verbinding, en om dit te vergelyk met ’n waarde wat die administrateur buite die kanaal verskaf, is die stap wat keer dat ’n verkeerde bediener jou geloofsbriewe ontvang. Om daardie kontrole af te skakel sodat ’n boekmerk kan verbind, is ’n permanente besluit vermom as ’n gerief. Dit verwyder ook die enigste bewyse wat jy daarna sou hê dat die lêer gegaan het waar jy bedoel het.

Antwoord die uitdaging wat die bediener stuur

Die projek se SFTP-dokumentasie beskryf uitdagingsrespons-ondersteuning vir eenmalige wagwoorde: ’n aanvanklike aanmeldopdrag, dan ’n tweede opdrag vir die kode, soos die bediener dit vra. Die vloei hoort by die bediener se konfigurasie, en ’n kliënt kan nie tweefaktor-afdwinging aan die bedienerkant byvoeg deur nog ’n waarde in sy wagwoordveld te stoor nie.

Die boekmerk moet dus die gewone rekeninggeloofsbrief hou, en die kode moet getik word wanneer die opdrag verskyn. Om ’n veranderende kode as die permanente wagwoord te stoor, lewer ’n boekmerk wat een keer werk, dan misluk op ’n manier wat soos ’n verkeerde wagwoord lyk. Om die kode in die VPN se geloofsbriefveld te sit, misluk anders: die poort verwerp dit, en die tonnel kom nooit op nie. Twee opdragte, twee plekke, en om hulle te ruil breek albei.

Outomatiese montering kan nie ’n knoppie druk nie

As die boekmerk in die agtergrond weer verbind, het ’n interaktiewe uitdaging niemand om dit te antwoord nie. Die montering probeer weer, die bediener vra weer, en die log loop vol pogings wat nie kan slaag nie. Dit is die eerlike resultaat van ’n beleid wat ’n mens vereis.

Beplan vir die interaksie: verbind die tonnel en die boekmerk terwyl jy teenwoordig is, en hanteer latere outomatiese herverbindings dan as beste poging. As die werkvloei werklik onbewaakte toegang nodig het, moet die bediener se eienaar ’n ander verifikasiereëling goedkeur, wat ’n beleidsverandering is eerder as ’n boekmerkinstelling.

’n Montering is nie ’n toestemming nie

’n Gekoppelde volume bewys dat ’n sessie verifieer het. Dit bewys nie dat die rekening oral op daardie bediener mag skryf nie. Gaan die beoogde gids na, probeer die bewerking wat jy werklik nodig het, en bevestig die resultaat van die bediener se kant wanneer die antwoord saak maak. Die Finder-sybalk wys ’n volume; dit sê niks oor die regte daaronder nie.

Vir ’n ander protokol, gebruik daardie verskaffer se gedokumenteerde verifikasiemetode eerder as om hierdie volgorde na te maak. ’n Wolk-aanmelding en ’n SSH-uitdaging kan in die sybalk identies lyk en onderlangs heeltemal anders werk.