OpenVPN väntar på en systemd-lösenordsbegäran: bör du svara?

Det visas ett meddelande om systemd-tty-ask-password-agent i terminalen, och tunneln är inte uppe. Den frestande läsningen är att VPN avvisade ett lösenord och att något nu väntar på en rättelse. Mer exakt har en tjänst bett systemd om interaktiv inmatning, och begäran är ännu inte besvarad. Vilken tjänst som frågade, och vilken hemlighet den vill ha, är två frågor du kan avgöra innan du skriver något.

Två villkor avgör vem som bör svara

Det första villkoret är om du startade den här instansen med avsikt. En begäran som följer på en handling du utförde är din att svara på, och en som dyker upp utan en motsvarande handling tillhör något annat. Det andra är om hemligheten är kontoauth eller nyckelskydd, eftersom de bor på olika platser och reser genom olika kodvägar. Båda svaren syns i journalen om du tittar innan du agerar.

När båda svaren är tydliga är beslutet enkelt: svara via tjänstens egen stödda begäransväg. När något av dem är otydligt är rätt steg att undersöka i stället för att skriva ett lösenord i en begäran du inte kan hänföra.

Det är hela regeln, och den är värd att säga före kommandona. Allt nedan följer av den.

Lista begäran innan du skriver något

Agenten kan lista vad som är utestående utan att svara på något. sudo systemd-tty-ask-password-agent --list skriver ut de öppna begärandena, och den utskriften är beviset du behöver för att koppla en begäran till en enhet. Läs den innan du lämnar en inloggningsuppgift, och håll begärandebeskrivningar borta från varje offentlig diagnostisk inklistring.

Korrelera listan med operationen du startade och med enheten som äger den. Om inget i listan stämmer med din handling tillhör begäran du såg en annan tjänst och är inte din att lösa. Enhetsnamnet i listan är den enda tillförlitliga kopplingen mellan en begäran och en tjänst.

Svara inte på en begäran du inte kan hänföra. Kostnaden för att vänta är en fördröjning, medan kostnaden för att svara på fel begäran är en inloggningsuppgift på fel plats.

Vilken hemlighet behöver instansen egentligen?

auth-user-pass gäller kontoauth mot VPN-tjänsten, och utan en inloggningsuppgiftsfil är det dokumenterade beteendet att fråga på konsolen. askpass hämtar i stället lösenfrasen som låser upp skyddat nyckelmaterial, och gör det innan processen går i bakgrunden. Det är olika hemligheter med olika livslängd.

Filformaten skiljer sig också. Kontoformen förväntar sig en användarnamnsrad och en lösenordsrad, medan nyckelns lösenfrasfil läser första raden som sitt lösenord. Att kopiera ett inloggningsuppgiftsfilrecept från den andra rollen ger vanligtvis ännu en begäran i stället för en lösning. En fil med fel form är värre än ingen fil, eftersom felet flyttar till en plats ingen övervakar.

Kontrollera vilket direktiv instansen använder innan du bestämmer vad du ska skriva. Direktivets namn berättar vilken hemlighet begäran gäller.

Vad --query gör som --list inte gör

--query behandlar varje utestående begäran på terminalen som anropar det, vilket är en mycket bredare åtgärd än att svara på en begäran. Det är inte en OpenVPN-väljare, och på en upptagen maskin kan det svara på begäranden som tillhör andra enheter. Bevakningsläget är ännu bredare, eftersom det fortsätter att hantera begäranden när de kommer in.

Använd den smalaste mekanismen som fungerar. För en enda tjänst är den tjänstens eget begäransflöde smalare än en global agent, och det håller svaret knutet till enheten som frågade.

Att göra en engångsbegäran till en obemannad global agent därför att ett meddelande dök upp en gång är hur en tillfällig irritation blir en permanent design. Samma försiktighet gäller för att inaktivera lösenordsaviseringsenheter på hela värden.

Bestäm, och registrera sedan valet

För en obemannad driftsättning, kom överens med den som äger anslutningen om inloggningsuppgiftskällan, filbehörigheterna och förnyelseschemat. En interaktiv andra faktor kan behöva en person eller en egen tjänsteidentitet. Att undertrycka begäran ger inte den autentiseringen, och att ta bort auth-user-pass bryter bara en tjänst som behöver det.

Efter interaktionen, titta på samma instans för dess nästa händelse och testa den privata resursen. Om inget är utestående, gå tillbaka till instansens tillstånd i stället för att starta varje OpenVPN-enhet på värden.