Целта на този документ е да покаже по какъв начин един HPC портален сървър (в системата който потребилите влизат и задават за изпълнение задачи или проверяват статуса им), взаимодейства със записите, направени за POSIX потребителите в LDAP директорийния сървър, съгласно процедурата описана в документа "Инсталиране и конфигуриране на 389 директориен сървър за удостоверяване на потребителите в HPC под CentOS 7 и Scientific Linux 7". Отбележете следното важно обстоятелство (важи за повечето HPC инфраструктури):

Порталните сървъри в HPC инфраструктурата УДОСТОВЕРЯВАТ POSIX потребители, но не изпълняват изчислителни задачи върху себе си. Не бива да позволявате удостоверяване на потребителите с парола по протокол SSH, защото паролите не осигуряват нужната висока сигурност на достъпа. Вместо пароли използвайте само OpenSSH ключове.

За да може да направите сравнение с HPC изчислителните сървъри, относно специфичния достъп до информация за потребителите, може да използвате документа "Настройка на HPC изчислителен сървър за извличане на POSIX потребителска информация от LDAP директориен сървър".

Следвайте описанието в "Настройка за криптиране на обменяната с LDAP сървъра информация, чрез TLS" (това е част от "Настройка на HPC изчислителен сървър за извличане на POSIX потребителска информация от LDAP директориен сървър"). В тази си част, конфигурацията за HPC изчислителен сървър и HPC портал е една и съща.

Следвайте описанието в "Използване на authconfig-tui за създаване на настройките за извличане на потребителска информация за POSIX потребителите от LDAP директориен сървър" (това е част от "Настройка на HPC изчислителен сървър за извличане на POSIX потребителска информация от LDAP директориен сървър"). В тази си част, конфигурацията за HPC изчислителен сървър и HPC портал е една и съща.

В "Създаване на POSIX потребители в LDAP директорията на 389 директориен сървър под CentOS 7 и Scientific Linux 7 и управлението им" е описана цялата процедура по създаване на dn-обекти за POSIX потребители в LDAP директорията. Същи там е описано и въвеждането (записването) на OpenSSH публичен ключ в dn-обекта на потребителя. Този OpenSSH ключ може да е предоставен от потребителя директно (въведен в LDAP през потребителски интерфейс), или да бъде извлечен с помощта на приложение от добре познати PKI X.509 и OpenPGP сертификати на потребителя. Повече информация за това може да намерите в "Използване на ключове от PKCS#12 контейнери, X.509 сертификати и OpenPGP ключове в SSH под Linux и Mac OS X".

Това, което трябва да се направи на HPC порталите (и което е различно от настройките за HPC изчислителните сървър) е да се извърши синхронизация на потребителските OpenSSH ключове. Този процес на синхронизация е еднопосочен и целта му е да извлече от LDAP директорията всички тези OpenSSH ключове, които не са в налични в локалната система (но са описани в LDAP) да бъдат изтеглени и поставени локално в съответните authorizied_keys файлове.

Както е обяснено в "Позициониране на потребителските OpenSSH ключове в HPC порталния сървър и HPC изчислителните сървъри", файловете authorized_keys в HPC порталния сървър, не трябва да се намират в домашните директории на потребителите (както е по подразбиране), а в специална директория, където са извън домашните директории. Отбележете следното. Преди потребителят да влезе за първи път в HPC портала, неговата домашйна директория върху файловата система не съществува. Тя се създава след като той се удостовери успешно за първи път в системата. Следователно, няма как OpenSSH ключа да бъде поставен на подразбиращото се място, в ~/.ssh, защото тази директория не съществува преди първото влизане на потребителя, а ако тя не същестува, той не може да се удостовери. Причините за това алтернативно позициониране и начина, по който то следва да се осъществи, са описани детайлно в "Позициониране на потребителските OpenSSH ключове в HPC порталния сървър и HPC изчислителните сървъри". Това, което е дадено по-долу като рецепта е как, при такова алтернативно позициониране, OpenSSH ключовете да бъдат изтеглени от LDAP директорията и бъдат поставени в authorized_keys.

Има достатъчно причини да бъде избягвано създаването на домашната директория на потребителя във файловата система на HPC портала, от системен скрипт. Множество лицензни споразумения, правни норми и прочие, изискват да се знае кога даден потребител е влязал за първи път в системата. Ако домашната директория на потребителя и всички подразбиращи се системни файлове и поддиректории, са създадени служебно (без негово участие), това може да създаде съмнения. Именно поради това, потребителската директория трябва да бъде създавана от потребители при първото му влизане, като доказателство, че той напълно съзнателно приема използването на своя потребителски профил в HPC портала и политиката за използване на ресурсите.

Копирането на OpenSSH ключа от LDAP директорията във файловата система на HPC портала, трябва да става само след валидация на цифровия подпис върху OpenSSH публичния ключ и да се провери дали цифровия отпечатък на ключа не е в включен в черен списък (поддържането на такъв не е описано тук - всеки администратор може да го организира по начина, по който намери за добре). За да проверите дали цифровия подпис върху OpenSSH ключа е валиден, трябва да разполагате с копие от X.509 сертификата на удостоверителя, който е начало на сертификатната верига водеща до сертификата, с който е направено подписа.

За примера по-долу се предполага, че LDAP сървъра има име на хост hpc-service-host.unite.uni-sofia.bg, дървото с потребителските dn-обекти е "ou=Users,dc=HPC,o=unite-bg.eu", потребителят, с чиито права ще се удостоверите пред LDAP сървъра е с dn-обект "uid=useradmin,ou=Special Users,o=unite-bg.eu", POSIX потребтеля, за който ще се извлича OpenSSH публичния ключ, ще има име vesso, а X.509 сертификата на удостоверителя за проверка на сертификатната верига ще е във файла SU_ECC_Root_CA.crt. С всички тези предварителни уговорки, изтеглянето на копието на OpenSSH публичния ключ може да стане чрез инструмента инструмента ldapsearch (вземете предвид бележките по използването на инструментите от openldap-clients в "LDAP клиентски софтуер за достъп до LDAP сървъра"), така:

$ ldapsearch -o ldif-wrap=no -H ldaps://hpc-service-host.unite.uni-sofia.bg -D "uid=useradmin,ou=Special Users,o=unite-bg.eu" -b "ou=Users,dc=HPC,o=unite-bg.eu" -x -W 'uid=vesso' sshpublickey-p7b | grep ^sshpublickey-p7b | awk '{print $2}' | base64 -d | openssl cms -verify -inform DER -CAfile SU_ECC_Root_CA.crt -out /tmp/openssh.out

Ако като резултат получите:

Verification successful

продължете с продецурата по-долу.

АКО НЕ ПОЛУЧИТЕ РЕЗУЛТАТА "Verification successful", проверте дали всичко е наред със сертификата, указан след -CAfile и ако не откритете проблем, свържете се с администратора на LDAP диреткторийния сървър, за да установите защо се проваля проверката на подписа и дали изобщо има успешно установена комуникация с LDAP сървъра.

След като получите за резултат "Verification successful", трябва да изчислите контролната сума на ключа, който се намира във файла openssh.out:

$ ssh-keygen -l -f openssh.out | awk '{print $2}' | awk -F ':' '{print $2}'

Резултатът от тази операция (изведената контролна сума) ще бъде подобен на:

NbXAQezxhQ9jBUPWpmiYeBxx6YufDWZKEn9yOTfMSh4

Проверете дали файла authorized_keys за потребителя, чиито ключ ще бъде поставен локално (или подменен), съществува и ако съществува, изчислете контролната сума на ключа, който се намира в него:

$ [ -f /opt/ssh/authorized_keys/vesso/authorized_keys ] && ssh-keygen -l -f /opt/ssh/authorized_keys/vesso/authorized_keys | awk '{print $2}' | awk -F ':' '{print $2}'

Ако файлът authorized_keys за конкретния потребител съществува, ще бъде изведена контролната сума на ключа с него. Трябва да я сравните с тези, която е изчислена по-горе. Ако при сравнението двете контролни суми:

• съвпадат:

  Не е нужно да предприемате нищо. OpenSSH ключа в authorized_keys файла е същия като този, който е зададен за потребителя в неговия dn-обект в LDAP директорията.

• не съвпадат:

  Преместете създадения файл /tmp/openssh.out като /opt/ssh/authorized_keys/vesso/authorized_keys (заменете vesso с конкретното потребителско име).

Ако файлът authorized_keys за потребителя не съществува, няма да бъде изведено нищо и в този случай просто преместете създадения файл /tmp/openssh.out като /opt/ssh/authorized_keys/vesso/authorized_keys (заменете vesso с конкретното потребителско име).

Възмножно е да автоматизирате тази процедура, като създадете скрипт, който да се изпълнява на всяка 1 минута и да синрхронизира OpenSSH ключовете на потребителите в локалната система, спрямо тези в LDAP директорията.