Исправка: OpenVPN није могао да прочита Auth корисничко име са стандардног улаза
Грешка OpenVPN «could not read Auth username from stdin» је локални квар улаза. Дајте услузи читљив извор акредитива; script-security нема везе с тим.
could not read Auth username from stdin изгледа као проблем са аутентификацијом и није. OpenVPN је покушао да затражи корисничко име са стандардног улаза, није нашао ништа читљиво и зауставио се пре него што је уопште контактирао сервер. Налог може бити потпуно важећи; процес једноставно нема кога да пита.
Зато је први користан корак да потврдите шта клијент чита, а не да понављате везу или мењате подешавања на страни сервера. Прођите кроз провере испод редом и зауставите се на првој која не успе.
Читајте грешку као локални квар улаза
Када се auth-user-pass појави без аргумента датотеке, клијент очекује питање. У интерактивној љусци то питање ради јер процес поседује терминал. Под systemd-ом, cron задатком или контејнером стандардни улаз је обично празан и читање се одмах враћа са грешком коју видите.
Порука такође наводи поље које није успело, корисничко име или лозинку, што показује докле је читање стигло. Недостајуће корисничко име значи да процес није успео да прочита баш ништа. Недостајућа лозинка после успешног корисничког имена значи да се ток улаза завршио између два читања, што је типично за напола написану датотеку или затворену цев.
Потврдите поглед самог клијента пре него што промените било шта друго. Покрените га у предњем плану са истом конфигурацијом и истим корисником и посматрајте да ли се питање појављује. Ако се појављује у вашој љусци, али не под управником услуга, разлика је у извору улаза, а не у акредитивима. Брзо поређење unit датотеке и окружења ваше љуске обично показује које од њих обезбеђује терминал.
Дајте услузи подржани извор акредитива
Подржани извор за рад без надзора је датотека са акредитивима прослеђена као аргумент за auth-user-pass. Датотека се чита као обичан текст: први ред је корисничко име, други је лозинка. Упутите на њу апсолутном путањом, на пример /etc/openvpn/client/creds , како радни директоријум сервисног налога не би могао да промени значење директиве.
Дозволе су важне колико и путања. Датотека мора бити читљива за налог који покреће клијента, а не за све остале, и требало би да припада сервисном налогу или root-у са групом која укључује услугу. Проверите читљивост као тај налог, без исписивања садржаја.
Релативна путања је тихи режим квара. Профил може бити у једном директоријуму док systemd покреће процес негде другде, па се датотека која се разрешава у вашој љусци не разрешава за услугу. Преместите акредитиве на фиксно место и упутите на њих апсолутно. Затим једном покрените услугу и потврдите да се користи иста путања, уместо да верујете приказу уређивача профила.
Ако распоређивање захтева једнократни код или други интерактивни изазов, одлучите да ли радни ток клијента то заиста подржава без надзора. Датотека са статичном лозинком не може да одговори на код који се мења, а понављање питања на које нема одговора не додаје информацију.
Зашто script-security неће помоћи
script-security контролише да ли клијент сме да покреће скрипте и колико сме да им пренесе, укључујући да ли лозинка може да се пренесе скрипти преко променљиве окружења. О томе одакле корисничко име и лозинка првобитно долазе не говори ништа.
Подизање на виши ниво је уобичајен рефлекс јер порука помиње Auth, али мења дозволе скрипти, а не извор улаза, и проширује шта клијент сме да изврши. Ако је помоћна скрипта део дизајна, прво поправите извор улаза и држите ниво безбедности на најнижој вредности која је потребна распоређивању.
Интерфејс за управљање је легитимна алтернатива. Предњи део може да се повеже са њим, прими захтев за акредитиве и одговори корисничким именом и лозинком, тако раде неки GUI. Ако га користите, вежите га за локалну адресу, заштитите га датотеком лозинке за управљање и ограничите ко може да се повеже, јер је то контролни канал за клијента.
Проверите следећу фазу пошто клијент прочита датотеку
Када клијент може да прочита акредитиве, следећи квар је стварна размена са сервером и његова порука има другачије значење. Неуспех аутентификације у тој фази значи да је сервер одбио налог; одговор изазова значи да сервер жели други фактор. Третирајте их као нове проблеме, а не као понављање истог.
Тестирајте цео пут онако како ће га услуга покренути: исти налог, исти радни директоријум, исто unit окружење. Веза која ради само када се покрене из ваше љуске знак је да су променљива окружења или терминал још увек део тока.
Затим држите тајне тамо где им је место. Лозинке у аргументима командне линије појављују се у табели процеса, а лозинке у излазу за отклањање грешака завршавају у тикетима. Користите заштићену датотеку или интерфејс за управљање, држите дневнике на нивоу који не понавља акредитиве и замените датотеку када неко са приступом оде.
Контролна листа: апсолутна путања до акредитива, читљива као сервисни налог, терминал није потребан, script-security на минимуму, интерфејс за управљање само ако је везан и аутентификован, а добијени одговор сервера се третира као засебан догађај.