OpenVPN atendas systemd-pasvortpeton: ĉu respondi ĝin?
systemd-pasvorta invito estas peto de servo, ne verdikto de la enirejo. Decidu, kiun sekreton oni petas, kaj kiu devus respondi ĝin.
En la terminalo aperas mesaĝo pri systemd-tty-ask-password-agent, kaj la tunelo ne estas aktiva. La alloga legado estas, ke la VPN malakceptis pasvorton kaj io nun atendas korekton. Pli ĝuste estas diri, ke servo petis de systemd interagan enigon, kaj ke la peto ankoraŭ ne estas respondita. Kiun servon demandis, kaj kiun sekreton ĝi volas, estas du demandoj, kiujn vi povas solvi antaŭ ol tajpi ion ajn.
Du kondiĉoj decidas, kiu devus respondi
La unua kondiĉo estas, ĉu vi lanĉis ĉi tiun instancon intence. Peto, kiu sekvas agon, kiun vi faris, estas via por respondi, kaj unu, kiu aperas sen kongrua ago, apartenas al io alia. La dua estas, ĉu la sekreto estas konta aŭtentigo aŭ ŝlosila protekto, ĉar tiuj loĝas en malsamaj lokoj kaj vojaĝas tra malsamaj kodaj vojoj. Ambaŭ respondoj videblas en la ĵurnalo, se vi rigardas antaŭ ol agi.
Kiam ambaŭ respondoj estas klaraj, la decido estas simpla: respondu tra la propra subtenata petvojo de la servo. Kiam iu ajn estas malklara, la ĝusta movo estas esplori anstataŭ tajpi pasvorton en peton, kiun vi ne povas atribui.
Tio estas la tuta regulo, kaj indas diri ĝin antaŭ la komandoj. Ĉio sube sekvas el ĝi.
Listigu la peton antaŭ ol vi tajpos ion ajn
La agento povas nombri, kio atendas, sen respondi ion ajn. sudo systemd-tty-ask-password-agent --list presas la pritraktendajn petojn, kaj tiu eligo estas la pruvo, kiun vi bezonas por ligi peton al unito. Legu ĝin antaŭ ol doni legitimilon, kaj tenu petpriskribojn for de ajna publika diagnoza algluaĵo.
Kunrilatu la liston kun la operacio, kiun vi komencis, kaj kun la unito, kiu posedas ĝin. Se nenio en la listo kongruas kun via ago, la peto, kiun vi vidis, apartenas al alia servo kaj ne estas via por solvi. La unita nomo en la listo estas la sola fidinda ligo inter peto kaj servo.
Ne respondu peton, kiun vi ne povas atribui. La kosto de atendo estas prokrasto, dum la kosto de respondi la malĝustan peton estas legitimilo en la malĝusta loko.
Kiun sekreton la instanco efektive bezonas?
auth-user-pass temas pri konta aŭtentigo al la VPN-servo, kaj sen legitimila dosiero la dokumentita konduto estas demandi en la konzolo. askpass anstataŭe akiras la pasfrazon, kiu malŝlosas protektitan ŝlosilmaterialon, kaj ĝi faras tion antaŭ ol la procezo foniĝas. Tiuj estas malsamaj sekretoj kun malsamaj vivdaŭroj.
Ankaŭ la dosierformoj diferencas. La konta formo atendas linion de uzantnomo kaj linion de pasvorto, dum la ŝlosil-pasfraza dosiero legas la unuan linion kiel sian pasvorton. Kopii legitimilan dosierrecepton el la alia rolo kutime produktas ankoraŭ unu peton anstataŭ solvon. Dosiero kun malĝusta formo estas pli malbona ol neniu dosiero, ĉar la malsukceso moviĝas al loko, kiun neniu observas.
Kontrolu, kiun direktivon la instanco uzas, antaŭ ol decidi, kion tajpi. La direktiva nomo diras al vi, por kiu sekreto la peto estas.
Kion --query faras, kion --list ne faras
--query prilaboras ĉiun atendantan peton en la alvokanta terminalo, kio estas multe pli larĝa ago ol respondi unu peton. Ĝi ne estas OpenVPN-elektilo, kaj sur okupata maŝino ĝi povas respondi petojn de aliaj unitoj. Observa reĝimo estas eĉ pli larĝa, ĉar ĝi daŭre traktas petojn dum ili alvenas.
Uzu la plej mallarĝan mekanismon, kiu funkcias. Por unu servo, la propra petfluo de tiu servo estas pli mallarĝa ol tutmonda agento, kaj ĝi tenas la respondon ligita al la unito, kiu demandis.
Turni unufojan peton en senprizorgan tutmondan agenton ĉar sciigo aperis unufoje estas la maniero, per kiu provizora ĝeno fariĝas daŭra dezajno. La sama singardo validas por malŝalti pasvort-sciigajn unitojn tra la tuta gastiganto.
Decidu, poste registru la elekton
Por senprizorga starigo, interkonsentu la legitimilan fonton, dosierpermesojn kaj renovigan horaron kun tiu, kiu posedas la konekton. Interaga dua faktoro povas bezoni personon aŭ dediĉitan servan identecon. Subpremi la peton ne produktas tiun aŭtentigon, kaj forigi auth-user-pass nur rompas servon, kiu bezonas ĝin.
Post la interago, rigardu la saman instancon por ĝia sekva evento kaj testu la privatan rimedon. Se nenio atendas, revenu al la instanca stato anstataŭ lanĉi ĉiun OpenVPN-uniton sur la gastiganto.