Mankas la TOTP-demando de OpenConnect en NetworkManager: kvar kontroloj

La enirejo akceptas la pasvorton, petas kodon, kaj la dialogaĵo proponas neniun kampon por ĝi. Nenio estis mistajpita: la NetworkManager-kromaĵo finis la sekretan interŝanĝon sen peti la sesciferan valoron. Trapasu la kvar kontrolojn sube laŭ ordo, ĉar nur unu el ili ŝanĝas la klienton. La resto de la listo ekskludas la enirejon, la konton kaj la konstruon de la kromaĵo.

Unua kontrolo: legu, kie haltis la aŭtentigo

Malĝusta pasvorto malsukcesas tuj. Mankanta dua faktoro malsukcesas post la akreditila paŝo, kutime per ripetita peto aŭ tempolimo ĉe la enireja flanko. La tempigo kaj la protokolo de la enirejo montras, kiu raŭndo restis senresponda.

Legu la konektan protokolon antaŭ ol tuŝi la profilon. Se la enirejo raportas nekompletan aŭtentigon aŭ eksvalidiĝintan defion, la kliento neniam sendis la kodon. Se ĝi raportas nevalidajn akreditilojn, la pasvorto estas la problemo kaj neniu TOTP-agordo ĝin riparos.

Notu la precizan petosekvencon, kiun la enirejo atendas: uzantnomo, pasvorto, poste kodo, aŭ uzantnomo, kodo, poste pasvorto. Kelkaj enirejoj reordigas la raŭndojn, kaj kliento, kiu konas nur la unuan ordon, haltos ĉe la dua.

Dua kontrolo: uzu la klienton, kiu posedas la defion

OpenConnect mem realigas la tutan interparolon, inkluzive de la defia raŭndo. Rekta ruligo estas la plej antaŭvidebla maniero konfirmi, ke la konto kaj la enirejo funkcias:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

La kliento demandas laŭ la ordo, laŭ kiu demandas la enirejo. La uzantagento gravas, ĉar kelkaj enirejoj tajloras la ensalutan fluon por konata kliento, kaj ĝenerala signoĉeno povas produkti pli mallongan fluon, kiu neniam petas la kodon. Rulu ĝin unufoje en la antaŭplano antaŭ ol aranĝi ajnan fonan servon.

Se la komandlinio demandas ĝuste, la konto, la enirejo kaj la dua faktoro estas en ordo. La restanta problemo estas la dialogaĵo de la kromaĵo, ne la aŭtentiga servo. Tio izolas la misan komponanton sen tuŝi la servilon. Konservu la eligon de la komando kun la incidenta registro.

Se ankaŭ la komandlinio preterlasas la peton, haltu kaj kontrolu la agordon de la enirejo kun ĝia posedanto. Neniu labortabla kliento povas respondi defion, kiun la servilo neniam sendas.

Tria kontrolo: vidu, ĉu via kromaĵo montras TOTP-reĝimon

Kelkaj NetworkManager OpenConnect-konstruoj montras ĵetonreĝimon kaj uzantagentan kampon en la langeto Identity de la konekto. Agordu la uzantagenton al la valoro, kiun la enirejo atendas, elektu manan TOTP-enigon kaj konservu la konekton.

Ĉu tiuj kampoj ekzistas dependas de la versio de la kromaĵo kaj de tio, kiun konektoredaktilon la labortablo uzas. Sendependa redaktilo povas montri opciojn, kiujn la GNOME-panelo kaŝas, aŭ male. Kontrolu la version de la instalita pako antaŭ ol serĉi kaŝitan agordon.

Se la ĵetonreĝimo ekzistas kaj la peto tamen ne aperas, la konstruo mankas la defian transdonon inter la kromaĵo kaj la ĝenerala sekreta dialogaĵo. Retajpi la pasvorton, reinstali la saman pakon aŭ malplenigi la ŝlosilringon ne kreos kampon, kiun la konstruo ne realigas.

Kvara kontrolo: traktu generitan kodon kiel kompromison

Skripto povas voki oathtool por la aktuala kodo kaj enigi uzantnomon, pasvorton kaj kodon en nmcli connection up --ask. La sinsekvo funkcias, sed la komuna sekreto finiĝas stokita ie, legebla de ĉiu, kiu povas malfermi la skripton, kaj tiu leganto povas fari kodojn porĉiame. Tio estas permanenta plivastigo de la akreditila surfaco, ne klienta riparo.

Ĉiu, kiu elektas tion, limigu la sekretan dosieron al root, tenu generitajn valorojn ekster la ŝela historio kaj traktu la skripton kiel akreditilan materialon. Ĉirkaŭaĵo, kiu eĥas la kodon al la terminalo, forĵetas la duan faktoron. Unue testu la ĉirkaŭaĵon per foruzebla konto.

La skripto ankaŭ devas sekvi la petosekvencon de la enirejo. Se la servilo petas la kodon antaŭ la pasvorto, fiksa eniga sinsekvo sendas la malĝustan valoron al la malĝusta peto kaj produktas la saman nekompletan aŭtentigon. Ekzercu ĝin per testa konto antaŭ ol ligi ĝin al ensaluta tasko.

Konfirmu la saman enirejon kaj konton

Testu ĉiun provizoran solvon kontraŭ la sama enirejo, la sama konto kaj la sama tunela grupo. Enirejo, kiu ankaŭ postulas aparatan atestilon povas rifuzi la komandlinian klienton pro kialo senrilata al TOTP, kaj la petosekvenco povas malsami de la ekzercita.

Notu la klienton, ĝian version, la uzantagenton kaj la petosekvencon, kiu funkciis. Tiu registro diras al la sekva persono, ĉu la problemo estas la kromaĵa konstruo, la enireja fluo aŭ la konta politiko, sen plia raŭndo de pasvortaj restarigoj.

Finu per unufoja rekonekto post plena elsaluto. Kaŝmemorita sekreto povas igi rompitan fluon aspekti riparita ĝis la sekva sesio, kaj ĉe la dua konekto la mankanta peto kutime revenas.