sss_ssh_authorizedkeys − отримати уповноважені ключі OpenSSH
sss_ssh_authorizedkeys [параметри] КОРИСТУВАЧ |
sss_ssh_authorizedkeys отримує відкриті ключі SSH для користувача КОРИСТУВАЧ і виводить їх у форматі authorized_keys OpenSSH (щоб дізнатися більше, див. розділ “ФОРМАТ ФАЙЛІВ AUTHORIZED_KEYS” на сторінці підручника (man) з sshd(8)).
sshd(8) можна налаштувати на використання sss_ssh_authorizedkeys для розпізнавання користувачів за відкритими ключами, якщо програму зібрано із підтримкою параметра “AuthorizedKeysCommand”. Будь ласка, зверніться до сторінки підручника sshd_config(5), щоб дізнатися більше про цей параметр.
Якщо передбачено підтримку “AuthorizedKeysCommand”, sshd(8) можна налаштувати на використання ключів за допомогою таких інструкцій у sshd_config(5):
AuthorizedKeysCommand
/usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody
КЛЮЧІ
З
СЕРТИФІКАТІВ
Окрім
відкрити
ключів SSH
для
користувача
КОРИСТУВАЧ,
sss_ssh_authorizedkeys може
повертати
ключі SSH,
які
походять
від
відкритого
ключа
сертифіката
X.509.
Щоб уможливити це, слід встановити для параметра “ssh_use_certificate_keys” значення true (типове значення) у розділі [ssh] файла sssd.conf. Якщо запис користувача містить сертифікати (див “ldap_user_certificate” на сторінці sssd-ldap(5), щоб дізнатися більше) або існує сертифікат у записі перевизначення для користувача (див. sss_override(8) або sssd-ipa(5), щоб дізнатися більше), а сертифікат є чинним, SSSD видобуде відкритий ключі з сертифіката і перетворить його до формату, який може використовувати sshd.
Окрім “ssh_use_certificate_keys”, може бути використано параметри
• ca_db
• p11_child_timeout
• certificate_verification
для керування способом встановлення чинності сертифікатів (докладніше див. sssd.conf(5)).
Перевірка чинності є перевагою використання сертифікатів X.509 замість ключів SSH безпосередньо, оскільки, наприклад, це поліпшує можливості керування часом придатності ключів. Якщо клієнт ssh налаштовано не використання закритих ключів з смарткартки за допомогою бібліотеки PKCS#11 спільного використання (див. ssh(1), щоб дізнатися більше), може дратувати те, що розпізнавання залишається працездатним, навіть якщо пов'язаний із ним сертифікат X.509 на смарткартці вже втратив чинність, оскільки ні ssh, ні sshd не братимуть сертифікат до уваги взагалі.
Слід зауважити, що похідний відкритий ключ SSH все одно можна додати до файла authorized_keys користувача, щоб обійти перевірку чинності сертифіката, якщо налаштування sshd надають змогу це робити.
−d,−−domain ДОМЕН
Шукати відкриті ключі користувачів у домені SSSD ДОМЕН.
−?,−−help
Показати довідкове повідомлення і завершити роботу.
У випадку успіху значення стану виходу дорівнює 0. У всіх інших випадках програма повертає 1.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-files(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/