Mountain Duck SFTP: la dua ensaluto post la VPN
La pordego kaj la dosier-servilo aŭtentigas malsamajn aferojn. Uzu la hostnomon de la SFTP-administranto, respondu al ĝia invito, kaj konservu la kontrolon de la host-ŝlosilo.
La VPN konektiĝas, la menuo montras tunelon, kaj Mountain Duck tamen petas ensaluton. Poste ĝi petas kodon. Nenio estas difektita: du malsamaj sistemoj aŭtentigas vin, kaj la dua neniam aŭdis pri la unua. La MFA de la VPN pruvas ion al la pordego. La SFTP-servilo petas sian propran pruvon, kontraŭ sia propra konto.
Du invitoj, du sistemoj
La pordego kaj la dosier-servilo estas apartaj politikaj domajnoj. Ili eble dividas dosierujon, aŭ eble havas nenion komunan krom la persono, kiu uzas ilin. Trapasi unufojan kodon ĉe la VPN ne kreas seancon sur la SFTP-gastiganto, kaj la SFTP-gastiganto ne povas scii, ĉu vi entute uzis tunelon. Ĉiu sistemo kredas, ke ĝi estas la sola, kiu demandas.
| Layer | What it authenticates | Where the account lives |
|---|---|---|
| VPN | The tunnel endpoint | Gateway or identity provider |
| SFTP | The file session | SSH server or its directory |
| Folder access | Read and write within the share | Filesystem permissions |
Traktu la tri kiel apartajn vicojn en viaj notoj. Kiam unu malsukcesas, la vico diras al vi, kiun konzolon malfermi, kaj tio estas la plej granda parto de la laboro.
Uzu la adreson de la SFTP-administranto
Legosigno bezonas la hostnomon kaj pordon, sur kiuj la dosier-servo efektive aŭskultas, kio ne nepre estas la adreso de la VPN-servilo. Demandu la administranton, kiu funkciigas la SFTP-servon, kaj uzu la saman hostnomon, kiun uzas aliaj klientoj.
Konservu la kontrolon de servila identeco sendifekta. Mountain Duck kaj Cyberduck montras la host-ŝlosilon ĉe la unua konekto, kaj kompari ĝin kun valoro, kiun la administranto provizas per alia kanalo, estas la paŝo, kiu malhelpas malĝustan servilon ricevi viajn akreditilojn. Malŝalti tiun kontrolon por ke legosigno konektiĝu estas permanenta decido kaŝita kiel komforto. Ĝi ankaŭ forigas la solan pruvon, kiun vi poste havus, ke la dosiero iris tien, kien vi intencis.
Respondu al la defio, kiun la servilo sendas
La SFTP-dokumentaro de la projekto priskribas subtenon de defio-respondo por unufojaj kodoj: komenca ensaluta invito, poste dua invito por la kodo, kiel la servilo postulas. La fluo apartenas al la agordo de la servilo, kaj kliento ne povas aldoni servoflankan dufaktoran devigon per stokado de alia valoro en sia pasvorda kampo.
Do la legosigno tenu la ordinarajn kontajn akreditilojn, kaj la kodon oni tajpu kiam la invito aperas. Stokado de ŝanĝiĝanta kodo kiel la permanenta pasvorto kreas legosignon, kiu funkcias unufoje, poste malsukcesas tiel, ke ĝi aspektas kiel malĝusta pasvorto. Meti la kodon en la akreditilan kampon de la VPN malsukcesas alimaniere: la pordego rifuzas ĝin, kaj la tunelo neniam leviĝas. Du invitoj, du lokoj, kaj interŝanĝi ilin rompas ambaŭ.
Aŭtomata muntado ne povas premi butonon
Se la legosigno rekonektiĝas en fono, interaga defio havas neniun, kiu respondu. La muntado reprovas, la servilo redemandas, kaj la protokolo pleniĝas per provoj, kiuj ne povas sukcesi. Tio estas la honesta rezulto de politiko, kiu postulas homon.
Planu la interagon: konektu la tunelon kaj la legosignon dum vi ĉeestas, poste traktu postajn aŭtomatajn rekonektojn kiel plejbonan provon. Se la laborfluo vere bezonas senprizorgan aliron, la servila posedanto devas aprobi alian aŭtentigan aranĝon, kio estas politika ŝanĝo, ne legosigna agordo.
Muntado ne estas permeso
Muntita volumo pruvas, ke seanco aŭtentiĝis. Ĝi ne pruvas, ke la konto rajtas skribi ĉie sur tiu servilo. Kontrolu la celitan dosierujon, provu la operacion, kiun vi efektive bezonas, kaj konfirmu la rezulton el la servila flanko kiam la respondo gravas. La flanka breto de Finder montras volumon; ĝi diras nenion pri la permesoj malantaŭ ĝi.
Por alia protokolo, uzu la dokumentitan aŭtentigan metodon de tiu provizanto anstataŭ kopii ĉi tiun sinsekvon. Nuba ensaluto kaj SSH-defio povas aspekti identaj en la flanka breto kaj konduti tute alie sube.