Да ли је --key-password у OpenConnect-у лозинка вашег VPN налога?

Прочитајте назив опције буквално. Она именује кључ, а забуна почиње када се датотека која се откључава помеша са налогом који се аутентификује. Налепите лозинку налога у ту опцију и клијент ће њоме покушати да отвори датотеку кључа, што не успева из разлога који немају везе са пријавом на VPN.

Збуњујуће је то што једна веза може легитимно да захтева оба тајна податка. Аутентификација клијентским сертификатом може да захтева шифровани кључ, а исти приступник може и после прихватања сертификата да спроведе размену аутентификације корисника. Ниједан тајни податак не задовољава другу фазу, а неуспех у једном споља изгледа врло слично неуспеху у другом.

Два тајна податка, два различита посла

Читајте улоге као приступ датотеци насупрот дозволи приступа мрежи. Лозинка кључа дешифрује PEM приватни кључ наведен у --sslkey како би могао да се представи TLS клијентски сертификат. То дешифровање се одвија локално, унутар процеса клијента, и сама лозинка никада не путује до приступника. Приступник види сертификат и потпис направљен кључем. OpenConnect приручник држи --key-password уз --certificate и --sslkey, а у верзијама које могу да користе кључ у TPM-у иста опција уместо тога носи лозинку коренског кључа складиштења.

Лозинка налога је другачија по врсти. Она улази у размену аутентификације: образац са корисничким именом и лозинком, токен, SAML круг или неку комбинацију коју приступник оглашава. Неке инсталације је уопште не траже када је сертификат једини фактор, а неке је траже и после сертификата, јер сертификат доказује уређај, а налог доказује особу.

Мешање двају ствара заваравајуће грешке. Приступник који одбија пријаву обично јавља неуспех аутентификације, док погрешна лозинка кључа обично пада раније, када TLS слој не може да прочита датотеку кључа. То су различите фазе са различитим исправкама, а називи су довољно слични да их људи замене и затим лове погрешан записник. Забележите који се упит појавио пре него што промените било коју поставку, јер је текст упита најјефтинија дијагностика коју имате.

Када је лозинка кључа заиста потребна

Опција има смисла само када постоји шифровани кључ који треба откључати. Ако се повезујете корисничким именом и лозинком и без клијентског сертификата, --key-password нема на шта да делује и његово укључивање ништа не мења. Ако се повезујете са --certificate и --sslkey, сопствени формат датотеке кључа одлучује да ли ће се лозинка уопште тражити.

Оба тајна податка у једној наредби уобичајена су у управљаним окружењима: сертификат уређаја у шифрованом кључу плус пријава за сваког корисника. Исправан след је пустити клијент да локално затражи лозинку кључа, довршити руковање сертификатом и затим одвојено обрадити упит приступника за налог. Покушај да се оба унапред попуне једном поново коришћеном скриптом место је где збрка обично почиње.

Корисна дијагностика је погледати када се квар догађа. Ако се клијент заустави пре него што почне икаква мрежна аутентификација, посумњајте у датотеку кључа, њен формат или лозинку. Ако је TLS сесија успостављена и приступник затим одбије корисника, кључ је одрадио свој посао и проблем је у размени за налог.

Држите оба тајна податка изван историје љуске

Аргументе наредбене линије други локални корисници могу да читају кроз табелу процеса и често се хватају у историју љуске, скрипте и транскрипте подршке. OpenConnect може да чита лозинку налога са стандардног улаза помоћу --passwd-on-stdin, а лозинка кључа може да дође из интерактивног упита или агента уместо из аргумента. Ниједан механизам сам по себи не чини тајни податак сигурним, али оба га држе изван најизложенијих места.

Датотеке заслужују исту пажњу. Скрипта која лозинку записује у привремену датотеку требало би да је створи са ограниченим овлашћењима, избрише је при изласку и избегава директоријуме читљиве свима. Лозинка која преживи сесију у привременом директоријуму копија је коју сте заборавили да направите. Променљиве окружења видљиве су подређеним процесима и често их исписују алати за отклањање грешака, па нису бесплатна надоградња у односу на аргументе.

Дијагностички излаз је тихо цурење. Записници клијента при већој разини детаља могу да прикажу тела захтева или вредности опција, а копирани транскрипт терминала лако се залепи у тикет, па прочитајте излаз пре него што га поделите.

Мртва типка на радној површини друга је врста квара

Унос VPN-а на радној површини који покаже вртњу и затим ништа обично уопште није проблем аутентификације. Типка припада мрежном управљачу, програмчету произвођача или додатку који покреће OpenConnect у ваше име, а компонента која недостаје или нечитљив профил могу да произведу управо тај симптом. Пронађите који процес типка покреће и прочитајте његову грешку пре него што дирате акредитиве.

Примамљиво је олабавити проверу сертификата или искључити проверу када GUI одбија повезивање. То претвара квар интеграције клијента у снижење безбедности и ретко поправља проблем покретања. Сачувајте проверу сервера нетакнутом, потврдите да профил показује на намеравани приступник и проверите да ли је помоћник који GUI очекује заиста инсталиран.

Кратак списак провера раздваја случајеве. Локални квар пре него што изађе било који пакет упућује на кључ или инсталацију клијента. Одбијање приступника после TLS сесије упућује на размену за налог. Типка која никада не покрене клијент упућује на интеграцију са радном површином. Три различита квара, од којих је један лозинка коју сте управо хтели да залепите у погрешно поље.