SSH-KEYGEN(1) | General Commands Manual | SSH-KEYGEN(1) |
ssh-keygen
—
Допоміжна
програма OpenSSH
для роботи
із ключами
розпізнавання
ssh-keygen
[-q
]
[-a
раундів]
[-b
бітність]
[-C
коментар]
[-f
вихідний_файл_ключа]
[-m
формат]
[-N
нова_парольна_фраза]
[-O
параметр]
[-t
dsa
|
ecdsa
| ecdsa-sk
|
ed25519
| ed25519-sk
|
rsa
] [-w
постачальник]
[-Z
шифр]
ssh-keygen
-p
[-a
раундів]
[-f
файл_ключа]
[-m
формат]
[-N
нова_парольна_фраза]
[-P
стара_парольна_фраза]
[-Z
шифр]
ssh-keygen
-i
[-f
вхідний_файл_ключа]
[-m
формат_ключа]
ssh-keygen
-e
[-f
вхідний_файл_ключа]
[-m
формат_ключа]
ssh-keygen
-y
[-f
вхідний_файл_ключа]
ssh-keygen
-c
[-a
раундів]
[-C
коментар]
[-f
файл_ключа]
[-P
парольна_фраза]
ssh-keygen
-l
[-v
] [-E
геш_відбитка]
[-f
вхідний_файл_ключа]
ssh-keygen
-B
[-f
вхідний_файл_ключа]
ssh-keygen
-D
pkcs11 ssh-keygen
-F
назва_машини
[-lv
] [-f
файл_відомих_машин]
ssh-keygen
-H
[-f
файл_відомих_машин]
ssh-keygen
-K
[-a
раундів]
[-w
постачальник]
ssh-keygen
-R
назва_машини
[-f
файл_відомих_машин]
ssh-keygen
-r
назва_машини
[-g
] [-f
вхідний_файл_ключа]
ssh-keygen
-M
generate
[-O
параметр]
вихідний_файл
ssh-keygen
-M
screen
[-f
вхідний_файл]
[-O
параметр]
вихідний_файл
ssh-keygen
-I
сертифікат_ідентичності
-s
ca-ключ
[-hU
] [-D
постачальник_pkcs11]
[-n
керівник]
[-O
параметр]
[-V
інтервал_чинності]
[-z
серійний_номер]
file ... ssh-keygen
-L
[-f
вхідний_файл_ключа]
ssh-keygen
-A
[-a
раундів]
[-f
префікс_до_шляху]
ssh-keygen
-k
-f
файл_krl
[-u
] [-s
публічний_ca]
[-z
номер_версії]
file ... ssh-keygen
-Q
[-l
]
-f
файл_krl
file ... ssh-keygen
-Y
find-principals
[-O
параметр]
-s
файл_сигнатури
-f
файл_дозволених_підписантів
ssh-keygen
-Y
match-principals
-I
ідентичність_підписанта
-f
файл_дозволених_підписантів
ssh-keygen
-Y
check-novalidate
[-O
параметр]
-n
простір_імен
-s
файл_сигнатури
ssh-keygen
-Y
sign
[-O
параметр]
-f
файл_ключа
-n
простір_імен
file ... ssh-keygen
-Y
verify
[-O
параметр]
-f
файл_дозволених_підписантів
-I
ідентичність_підписанта
-n
простір_імен
-s
файл_сигнатури
[-r
файл_відкликання]
ssh-keygen
створює
ключі
розпізнавання,
керує
ключами
розпізнавання
та
перетворює
ключі
розпізнавання
для ssh(1).
ssh-keygen
може
створювати
ключі для
використання
версії
протоколу SSH
2.
Тип
згенерованого
ключа
визначається
параметром
-t
. Якщо
виконати
без жодних
аргументів,
ssh-keygen
згенерує
ключ RSA.
ssh-keygen
також
використовується
для
генерування
груп, що
використовуються
в обміні
груп
Діффі-Геллмана
(DH-GEX).
Детальніше
дивіться
MODULI GENERATION.
І нарешті,
ssh-keygen
можна
використовувати,
щоб
генерувати
та
оновлювати
Списки
Відкликання
Ключів, і
щоб
тестувати,
чи надані
ключі були
відкликані
через
список. Див.
розділ
KEY REVOCATION LISTS
щодо
подробиць.
Зазвичай кожний користувач, що хоче використовувати SSH з автентифікацією відкритим ключем запускає це один раз, щоб створити ключ автентифікації в in ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk або ~/.ssh/id_rsa. Додатково, системний адміністратор може використовувати це, що генерувати ключі машин.
Зазвичай,
ця
програма
генерує
ключ і
питає про
файл, в
якому
зберегти
приватний
ключ.
Відкритий
ключ
зберігається
у файлі з
таким
самим ім'ям,
але з
доданим
“.pub”.
Програма
також
запитує
фразу
пароля
Фраза
пароля
може бути
порожньою,
що означає
її
відсутність
(ключі
машин
повинні
мати
порожні
фрази
пароля), або
вона може
бути
рядком
довільної
довжини.
Фраза
пароля
схожа на
пароль,
окрім того,
що вона
може
містити
декілька
слів,
пунктуацію,
числа,
пробіли
або
будь-яку
послідовність
символів.
Добрі
фрази
пароля
містять 10-30
символів,
не є
простими
реченнями
і не є
легковгадуваними
(англійська
проза має
ентропію
лише 1-2
бітів на
символ, і
надає
досить
погані
фрази
паролів), і
містити
суміш
верхнього
та
нижнього
регістрів,
цифр та
символи,
які не є
літерами
чи цифрами.
Фразу
пароля
можна
змінити
через
параметр
-p
.
Втрачену фразу пароля відновити неможливо. Якщо фразу пароля втрачено або забуто, потрібно згенерувати новий ключ та скопіювати відповідний відкритий ключ на інші машини.
ssh-keygen
,
типово,
записує
ключі у
форматі,
який є
специфічний
OpenSSH. Цей
формат є
бажаним,
оскільки
він
забезпечує
кращий
захист для
зберігання
ключів, а
також
уможливлює
зберігання
коментарів
до ключів у
самому
файлі
закритого
ключа.
Коментар
до ключа
може бути
корисним
для
ідентифікації
ключа.
Коментар
ініціалізується
значенням
“user@host” при
створенні
ключа, але
коментар
можна
змінити за
допомогою
параметра
-c
.
У ssh-keygen
зберігається
можливість
записувати
у раніше
використовуваному
форматі PEM
закритих
ключів за
допомогою
прапорця
-m
. Цим
можна
скористатися
при
створенні
ключів, а
наявні
ключі у
новому
форматі
можна
перетворити
за
допомогою
цього
параметра
у
поєднанні
із
прапорцем
-p
(змінити
пароль).
Після
створення
ключа, ssh-keygen
запитає
куди
помістити
ключі, щоб
вони були
активованими.
Параметри є такими:
-A
-f
, його
аргумент
буде
використано
як префікс
до
типового
шляху для
отриманих
файлів
ключа
вузла. Цим
користуються
скрипти
адміністрування
системи
для
створення
ключів
вузлів.-a
цикли-B
-b
бітність-b
визначає
довжину
ключа,
вибираючи
один із
трьох
розмірів
еліптичної
кривої: 256, 384
або 521 біт.
Спроба
використання
довжини
бітів,
відмінної
від цих
трьох
значень,
для ключів
ECDSA буде не
вдалою.
Ключі ECDSA-SK, Ed25519 і
Ed25519-SK мають
фіксовану
довжину і
прапорець
-b
ігноруватиметься.-C
коментар-c
-D
pkcs11-s
цей
параметр
вказує, що
ключ
служби
сертифікації
(CA)
зберігається
у жетоні PKCS#11
(див.
розділ
СЕРТИФІКАТИ,
щоб
дізнатися
більше).-E
геш_відбитка-e
-m
.
Типовим
форматом
експортування
є “RFC4716”. За
допомогою
цього
параметра
можна
експортувати
ключі OpenSSH для
використання
в інших
програмах,
зокрема
декількох
комерційних
реалізацій
SSH.-F
назва_машини
|
[назва_машини]:порт-H
для
виведення
знайдених
ключів у
хешованому
форматі.-f
назва_файла-g
-r
.-H
ssh
і
sshd
, але
вони не
надають
безпосереднього
доступу до
ідентифікаційних
даних, якщо
вміст
файла буде
кимось
викрадено.
Використання
цього
параметра
не
призведе
до зміни
наявних
хешованих
назв
вузлів,
тому його
можна
безпечно
використовувати
для файлів,
у яких
поєднуються
хешовані і
нехешованими
назвами.-h
-I
профіль_сертифікації-i
-m
, і
виведення
сумісного
із OpenSSH
закритого
(або
відкритого)
ключа до stdout.
За
допомогою
цього
параметра
можна
імпортувати
ключі з
іншого
програмного
забезпечення,
зокрема
декількох
комерційних
реалізацій
SSH. Типовим
форматом є
“RFC4716”.-K
-k
ssh-keygen
створить
файл KRL у
місці,
вказаному
за
допомогою
прапорця
-f
, який
призводить
до
відкликання
усіх
ключів або
сертифікатів,
які
вказано у
рядку
команди.
Ключі або
сертифікати,
які слід
відкликати,
можна
вказати за
файлом
відкритого
ключа або
за
допомогою
формату,
описаного
у розділі
СПИСКИ
ВІДКЛИКАННЯ
КЛЮЧІВ.-L
-l
ssh-keygen
намагається
знайти
відповідний
файл
відкритого
ключа і
вивести
його
відбиток.
Якщо
поєднати
із
параметром
-v
, разом
із ключем
буде
показано
зображення
із
символів ASCII,
яке
відповідає
ключу.-M
generate
-M
screen
-m
формат_ключа-i
(імпорт),
-e
(експорт) і
дії зі
зміни
пароля
-p
.
Останніми
можна
скористатися
для
перетворення
форматів
закритих
ключів OpenSSH і
закритих
ключів PEM.
Підтримувані
формати
ключів: “RFC4716”
(відкритий
або
закритий
ключ RFC 4716/SSH2), “PKCS8”
(відкритий
або
закритий
ключ PKCS8) або
“PEM”
(відкритий
ключ PEM).
Типово, OpenSSH
запише
новостворені
закриті
ключі у
власному
форматі,
але при
перетворенні
типовим
форматом
експортування
відкритих
ключів є
“RFC4716”.
Встановлення
формату
“PEM” при
створенні
або
оновленні
підтримуваного
типу
закритого
ключа
призведе
до того, що
ключ буде
збережено
у
застарілому
форматі
закритих
ключів PEM.-N
нова_парольна_фраза-n
реєстраційні_записи-O
параметрssh-keygen
.
При підписуванні сертифікатів тут можна вказати один із параметрів зі списку розділу СЕРТИФІКАТИ.
При виконанні створення або перевірки модулів може бути вказано один з параметрів зі списку у розділі СТВОРЕННЯ МОДУЛІВ.
При створенні ключів на основі ідентифікатора FIDO можна вказати один із параметрів зі списку розділу ЗАСІБ РОЗПІЗНАВАННЯ FIDO.
Коли
виконуємо
параметри,
пов'язані
з
підписами,
за
допомогою
прапорця
-Y
,
приймаються
наступні
параметри:
hashalg
=алгоритмprint-pubkey
verify-time
=часова_позначкаПараметр
-O
можна
вказувати
декілька
разів.
-P
пароль-p
-Q
-l
, буде
виведено
вміст KRL.-q
ssh-keygen
.-R
назва_вузла
|
[назва_вузла]:порт-H
вище).-r
назва_вузла-s
ключ_caПри
створенні
KRL -s
визначає
шлях до
файла
відкритого
ключа
служби
сертифікації
(CA), який буде
використано
для
відкликання
сертифікатів
безпосередньо
за
ідентифікатором
ключа або
серійним
номером.
Див.
розділ
СПИСКИ
ВІДКЛИКАННЯ
КЛЮЧІВ,
щоб
дізнатися
більше.
-t
dsa
|
ecdsa
|
ecdsa-sk
|
ed25519
|
ed25519-sk
|
rsa
Цим прапорцем можна скористатися для визначення бажаного типу підпису при підписуванні сертифікатів за допомогою ключа RSA служби сертифікації. Варіантами підписів RSA є “ssh-rsa” (підписи SHA1, не рекомендовано), “rsa-sha2-256” і “rsa-sha2-512” (типовий).
-U
-s
або
-Y
sign
цей
параметр
вказує, що
ключ
служби
сертифікації
(CA)
зберігається
у ssh-agent(1). Див.
розділ
СЕРТИФІКАТИ,
щоб
дізнатися
більше.-u
-k
, ключі
зі списку,
отриманого
з рядка
команди,
буде
додано до
наявного KRL,
а не
записано
до
новоствореного
KRL.-V
validity_intervalПочатковий час можна вказати так:
Кінцевий час можна вказати у спосіб, подібний до початкового часу:
Приклад:
-v
ssh-keygen
виводити
діагностичні
повідомлення
щодо
поступу
обробки
завдань.
Корисно
для
діагностики
створення
модулів.
Додавання
декількох
параметрів
-v
підвищує
докладність.
Максимально
докладним
є режим із 3
параметрами.-w
provider-Y
find-principals
-s
у
файлі
уповноважених
підписантів,
який
вказано за
допомогою
прапорця
-f
.
Формат
файла
дозволених
підписантів
задокументовано
у розділі
ДОЗВОЛЕНІ
ПІДПИСАНТИ
нижче. Якщо
буде
знайдено
один або
декілька
відповідних
реєстраційних
записів, їх
буде
повернуто
до
стандартного
виведення.-Y
match-principals
-I
, у
файлі
уповноважених
підписантів,
вказаному
за
допомогою
прапорця
-f
. Якщо
буде
знайдено
один або
декілька
відповідних
реєстраційних
записи, їх
буде
повернуто
до
стандартного
виведення.-Y
check-novalidate
ssh-keygen
-Y
sign
так
коректність
структури.
Перевірку
не буде
пройдено,
якщо
підпис
походить
від
уповноваженого
підписанта.
При
перевірці
підпису
ssh-keygen
отримує
повідомлення
та простір
назв
підпису на
стандартному
джерелі
вхідних
даних за
допомогою
прапорця
-n
. Також
має бути
надано
файл, що
містить
відповідний
підпис, за
допомогою
прапорця
-s
.
Сигналом
про
проходження
перевірки
для ssh-keygen
буде
повернутий
нульовий
стан
виходу.-Y
sign
ssh-keygen
приймає
нуль або
більше
файлів у
рядку
команди.
Якщо
файлів не
вказано,
ssh-keygen
підпише
дані, які
надано зі
стандартного
джерела
вхідних
даних.
Підписи
буде
записано
до
каталогу
файла
вхідних
даних до
файла із
назвою
файла
вхідних
даних із
додаванням
суфікса
“.sig” або до
стандартного
виведення,
якщо
повідомлення,
яке слід
підписати,
було
прочитано
зі
стандартного
джерела
вхідних
даних.
Ключ,
який буде
використано
для
підписування,
задається
за
допомогою
параметра
-f
і може
бути або
закритим
ключем
або
відкритим
ключем із
закритою
частиною,
яка
доступна
за
допомогою
ssh-agent(1).
Додатковий
простір
назв
підписів,
який
використовують
для
запобігання
конфліктам
між
різними
областями
використання
(наприклад,
підписування
файлів і
підписування
повідомлень
електронної
пошти), має
бути
надано за
допомогою
прапорця
-n
.
Просторами
назв є
довільні
рядки,
зокрема
“file” для
підписування
файлів, “email”
для
підписування
повідомлень
електронної
пошти. Для
нетипових
використань
рекомендуємо
використовувати
назви у
форматі
НАЗВА_ПРОСТОРУ@ВАШ.ДОМЕН,
щоб
створювати
однозначну
прив'язку
просторів
назв.
-Y
verify
ssh-keygen
-Y
sign
, як це
описано
вище. При
перевірці
підпису
ssh-keygen
приймає
повідомлення
на
стандартному
джерелі
вхідних
даних і
простір
назв, який
вказано за
допомогою
прапорця
-n
. Також
має бути
вказано
файл, що
містить
відповідний
підпис, за
допомогою
прапорця
-s
, а
також
профіль
підписанта
за
допомогою
прапорця
-I
та
список
дозволених
підписантів
за
допомогою
прапорця
-f
.
Формат
файла
дозволених
підписантів
документовано
у розділі
ДОЗВОЛЕНІ
ПІДПИСАНТИ
нижче.
Файл, у
якому
містяться
дані щодо
відкликаних
ключів,
можна
передати
за
допомогою
прапорця
-r
. У
файлі
відкликаних
ключів
може бути KRL
або список
відкритих
ключів по
одному на
рядок.
Сигналом
про
проходження
уповноваженим
підписантом
перевірки
для ssh-keygen
буде
повернутий
нульовий
стан
виходу.-y
-Z
шифр-z
серійний_номерПри
створенні
KRL
прапорець
-z
буде
використано
для
задання
номеру
версії KRL.
ssh-keygen
можна
скористатися
для
породження
груп для
протоколу
обміну
групами
Діффі-Гелмана
(DH-GEX).
Породження
цих груп є
двокроковим
процесом:
спочатку,
програма
породжує
прості
числа —
кандидати
за
допомогою
швидкого,
але
вимогливого
до об'єму
пам'яті
процесу. Ці
кандидати
— прості
числа
потім на
наступному
кроці
перевіряють
на
придатність
(вимогливий
до
ресурсів
процесора
процес).
Породження
простих
чисел
виконують
за
допомогою
параметра
-M
generate
.
Бажану
довжину
простих
чисел
можна
вказати за
допомогою
параметра
-O
bits
.
Приклад:
# ssh-keygen -M generate -O bits=2048
moduli-2048.candidates
Типово,
пошук
простих
чисел
розпочинається
з
випадкової
позиції у
бажаному
діапазоні
довжин.
Перевизначити
таку
поведінку
можна за
допомогою
параметра
-O
start
,
який
вказує
іншу
початкову
точку (у
форматі
шістнадцяткового
числа).
Щойно
буде
створено
набір
кандидатів,
його має
бути
перевірено
на
придатність.
Зробити це
можна за
допомогою
параметра
-M
screen
. У
цьому
режимі
ssh-keygen
читатиме
кандидати
зі
стандартного
джерела
вхідних
даних (або
файла, який
вказано за
допомогою
параметра
-f
).
Приклад:
# ssh-keygen -M screen -f
moduli-2048.candidates moduli-2048
Типово,
кожне
число-кандидат
підлягає 100
перевіркам
на
простоту.
Перевизначити
кількість
перевірок
можна за
допомогою
параметра
-O
prime-tests
.
Для
відповідних
простих
чисел
автоматично
буде
вибрано
значення
породжувача
ДГ. Якщо
бажаним є
якийсь
інший
породжувач,
вказати
його можна
за
допомогою
параметра
-O
generator
.
Коректними
значеннями
для
породжувача
є 2, 3 і 5.
Перевірені групи ДГ може бути встановлено до /etc/ssh/moduli. Важливо, щоб цей файл містив модулі у діапазоні бітових довжин.
Доступ до
деяких
параметрів
для
породження
модулів та
перевірки
можна
отримати
за
допомогою
прапорця
-O
:
lines
=числоstart-line
=номер-рядкаcheckpoint
=назва-файлаmemory
=мегабайтиstart
=шістнадцяткове-значенняgenerator
=значенняУ ssh-keygen
передбачено
підтримку
підписування
ключів для
отримання
сертифікатів,
якими
можна
скористатися
для
розпізнавання
користувача
або вузла
зв'язку.
Сертифікати
складаються
з
відкритого
ключа,
деяких
даних
профілю,
нуля або
більшої
кількості
назв
реєстраційних
записів
(користувача
або вузла
зв'язку) і
набору
параметрів,
які
підписано
ключем
служби
сертифікації
(Certification Authority або CA).
Клієнти
або
сервери
можуть
довіряти
лише ключу CA
і
перевіряти
його
підпис і
сертифікат,
а не
встановлювати
довіру до
багатьох
ключів
користувачів
або вузлів
зв'язку.
Зауважте,
що
сертифікати
OpenSSH мають
інший, і
набагато
простіший,
формат за
сертифікати
X.509, які
використано
у ssl(8).
У ssh-keygen
передбачено
підтримку
двох типів
сертифікатів:
сертифікатів
користувача
і вузла. За
сертифікатами
користувачів
відбувається
розпізнавання
користувачів
на
серверах, а
сертифікати
вузлів
використовують
для
розпізнавання
серверних
вузлів на
боці
користувача.
Для
створення
сертифіката
користувача
скористайтеся
такою
командою:
$ ssh-keygen -s
/шлях/до/ключа_ca
-I
ідентифікатор_ключа
/шлях/до/ключа_користувача.pub
Сертифікат-результат
буде
збережено
до файла
/шлях/до/ключа_користувача-cert.pub.
Для
створення
сертифіката
вузла
потрібно
вказати
параметр
-h
:
$ ssh-keygen -s
/шлях/до/ключа_ca
-I
ідентифікатор_ключа
-h
/шлях/до/ключа_вузла.pub
Сертифікат вузла буде виведено до файла /шлях/до/ключа_вузла-cert.pub.
Підписування
можна
виконати
за
допомогою
ключа CA,
який
зберігається
у жетоні PKCS#11,
вказавши
бібліотеку
жетонів за
допомогою
параметра
-D
і
визначивши
ключ CA
шляхом
надання
його
відкритої
частини як
аргументу
параметра
-s
:
$ ssh-keygen -s
ключ_ca.pub -D libpkcs11.so -I
ідентифікатор_ключа
ключ_користувача.pub
Так само,
можна
задати
ключ CA для
зберігання
у ssh-agent(1).
Вказати
про це
можна за
допомогою
прапорця
-U
і,
знову ж
таки, ключ CA
має бути
вказано за
його
відкритою
частиною.
$ ssh-keygen -Us
ключ_ca.pub -I
ідентифікатор_ключа
ключ_користувача.pub
В усіх випадках ідентифікатор_ключа є «ідентифікатором ключа», який записується до журналу сервером, коли сертифікат використовують для розпізнавання.
Чинність сертифікатів може бути обмежено набором назв реєстраційних записів (користувача або вузла). Типово, створені сертифікати є чинними для усіх користувачів і вузлів. Щоб створити сертифікат для вказаного набору реєстраційних даних, скористайтеся такими командами:
$ ssh-keygen -s
ключ_ca -I
ідентифікатор_ключа
-n
користувач1,користувач2
ключ_користувача.pub
$ ssh-keygen -s
ключ_ca -I
ідентифікатор_ключа
-h -n
вузол.домен
ключ_вузла.pub
Додаткові обмеження щодо чинності і використання сертифікатів користувача можна вказати за допомогою параметрів сертифіката. Параметр сертифіката може вимкнути можливості сеансу SSH, обмежити чинність певними адресами джерела або обмежити використання сертифіката певною командою.
Коректні параметри для сертифікатів користувача:
clear
critical
:назва[=вміст]extension
:назва[=вміст]force-command
=командаno-agent-forwarding
no-port-forwarding
no-pty
no-user-rc
no-x11-forwarding
permit-agent-forwarding
permit-port-forwarding
permit-pty
permit-user-rc
permit-X11-forwarding
no-touch-required
ecdsa-sk
та
ed25519-sk
.
source-address
=список_адресverify-required
ecdsa-sk
і
ed25519-sk
. У
поточній
версії
передбачено
підтримку
лише
розпізнавання
за
допомогою
PIN-коду, але у
майбутньому
може бути
реалізовано
підтримку
інших
методів.У поточній версії немає стандартних параметрів, які є чинними для ключів вузлів.
Нарешті,
сертифікати
може бути
визначено
із строком
дії. За
допомогою
параметра
-V
можна
вказати
початок і
кінець
строку дії
сертифіката.
Сертифікат,
який буде
надано
поза
вказаним
часовим
проміжком,
не
вважатиметься
чинним.
Типово,
сертифікати
є чинними
від
початку
епохи UNIX
до
далекого
майбутнього.
Для сертифікатів, які буде використано для розпізнавання користувача або вузла, відкритий ключ служби сертифікації (CA) має бути довіреним для sshd(8) або ssh(1). Зверніться до відповідних сторінок підручника, щоб дізнатися більше.
ssh-keygen
може
створювати
ключі на
основі
засобу
ідентифікації
FIDO, після
чого
ключами
можна буде
скористатися
подібно до
інших
типів
ключів,
підтримку
яких
передбачено
в OpenSSH, доки
апаратний
засіб
розпізнавання
з'єднано
при
використання
ключів.
Засоби
розпізнавання
FIDO, загалом,
потребують
від
користувача
явних
уповноважень
дій
торканням
або
притисканням
пальця.
Ключі FIDO
складаються
з двох
частин:
дескриптора
ключа, який
зберігається
у файлі
закритого
ключа на
диску, і
закритого
ключа
пристрою,
який є
унікальним
для
кожного
засобу
розпізнавання
FIDO і який не
можна
експортувати
з
апаратної
частини
засобу
розпізнавання.
Ці частини
поєднуються
обладнанням
у момент
розпізнавання
для
створення
справжнього
ключа, який
буде
використано
для
викликів
розпізнавання.
Підтримуваними
типами
ключів є
ecdsa-sk
і
ed25519-sk
.
Параметри, якими можна скористатися для ключів FIDO, є такими:
application
challenge
=шляхdevice
no-touch-required
resident
user
verify-required
write-attestation
=шляхssh-keygen
може
керувати
списками
відкликання
ключів (Key Revocation Lists
або KRL) у
форматі OpenSSH. У
цих
двійкових
файлах у
компактному
форматі
визначено
ключі або
сертифікати,
які слід
відкликати:
достатньо
одного
біта на
сертифікат,
якщо
сертифікати
відкликано
за
серійним
номером.
KRL може
бути
створено
за
допомогою
прапорця
-k
.
Програма
прочитає
один або
декілька
файлів з
рядка
команди і
створить
новий KRL.
Файли
можуть
містити
або задані
дані KRL (див.
нижче), або
відкриті
ключі у
списку по
одному на
рядок. Щоб
відкликати
звичайні
текстові
відкриті
ключі, слід
вказати
список
їхніх
хеш-сум або
дані у KRL, а
щоб
відкликати
сертифікат,
слід
вказати
серійний
номер або
ідентифікатор
ключа (якщо
серійний
номер є
нульовим
або
серійний
номер не
вказано).
Відкликання ключів за допомогою зазначення KRL надає вам явний контроль над типами записів, які використовують для відкликання ключів. Ним можна скористатися для безпосереднього відкликання ключів за серійним номером або ідентифікатором ключа без потреби у наявності усього початкового сертифіката. Задані дані KRL складаються з рядків, що містяться одну з наведених нижче інструкцій, після якого слід вказати двокрапку і певну специфічну інформацію.
serial
:
серійний_номер[-серійний_номер]ssh-keygen
за
допомогою
параметра
-s
.id
:
ідентифікатор_ключаssh-keygen
слід
вказати
ключ
служби
сертифікації
(CA) за
допомогою
параметра
-s
.key
:
відкритий_ключsha1
:
відкритий_ключsha256
:
відкритий_ключhash
:
відбитокssh-keygen
-l
.
Передбачено
підтримку
лише
відбитків
SHA256, а
підтримку
отриманих
KRL
передбачено
лише у
версіях OpenSSH,
починаючи
з 7.9.KRL можна
оновлювати
за
допомогою
прапорця
-u
, окрім
прапорця
-k
. Якщо
вказано
цей
параметр,
ключі зі
списку у
рядку
команди
буде
об'єднано
із KRL:
програма
додасть до
списку ті
ключі, яких
там ще не
було.
Також
можна, якщо
задано KRL,
перевірити
чи він
відкликає
якийсь
ключ (або
ключі).
Прапорець
-Q
опитує
наявний KRL,
перевіряючи
кожен ключ,
що вказано
в
командному
рядку. Якщо
будь-який
ключ,
вказаний у
командному
рядку, було
відкликано
(або
сталася
помилка),
тоді ssh-keygen
завершить
роботу із
ненульовим
станом.
Нульовий
стан
виходу
буде
повернено,
лише якщо
жоден ключ
не було
відкликано.
При
перевірці
підписів
ssh-keygen
використовує
простий
список
профілів і
ключів для
визначення,
чи
походить
підпис із
уповноваженого
джерела. У
цьому
файлі
«дозволених
підписантів»
використано
формат,
взірцем
для якого є
ФОРМАТ
ФАЙЛІВ
УПОВНОВАЖЕНИХ
КЛЮЧІВ,
який
описано на
сторінці
підручника
sshd(8). У
кожному
рядку
цього
файла
містяться
такі
відокремлені
пробілами
поля:
реєстраційні
записи,
параметри,
тип ключа,
ключ у
кодуванні
base64. Порожні
рядки та
рядки, що
починаються
з символу
‘#
’, буде
проігноровано
— вони
вважатимуться
частиною
коментарів.
Поле
реєстраційних
записів є
списком
взірців
(див.
«ВЗІРЦІ» у
підручнику
з ssh_config(5)), що
складається
із одного
або
декількох
відокремлених
комами
взірців
профілів
КОРИСТУВАЧ@ДОМЕН,
які
приймаються
для
підписування.
При
перевірці
профіль,
який
вказано за
допомогою
параметра
-I
, має
відповідати
взірцю
реєстраційних
даних, щоб
відповідний
ключ
вважався
прийнятним
для
перевірки.
Параметри (якщо вказано) складаються з відокремлених комами записів окремих параметрів. Пробіли використовувати не можна, окрім пробілів у подвійних лапках. Передбачено підтримку таких специфікацій параметрів (зауважте, що ключові слова параметрів можна вказувати без врахування регістру символів):
namespaces
=список-просторів-назвvalid-after
=часова-позначкаvalid-before
=часова-позначкаПри перевірці підписів, створених за допомогою сертифікатів, очікувана назва реєстраційного запису має відповідати одразу взірцю реєстраційних записів у файлі дозволених підписантів і реєстраційним записам, які вбудовано до самого сертифіката.
Приклад коректного файла підписантів:
# На початку рядка можна вказувати коментарі user1@example.com,user2@example.com ssh-rsa AAAAX1... # Служба сертифікації, якій довіряють для усіх реєстраційних записів у домені. *@example.com cert-authority ssh-ed25519 AAAB4... # Ключ, який приймають лише для підписування файлів. user2@example.com namespaces="file" ssh-ed25519 AAA41...
SSH_SK_PROVIDER
ssh-keygen
не
здійснюватиметься
автоматично,
але його
буде
запропоновано
як типовий
файл для
закритого
ключа. ssh(1)
читатиме
дані з
цього
файла під
час спроби
увійти до
системи.
ssh(1), ssh-add(1), ssh-agent(1), moduli(5), sshd(8) The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006.
OpenSSH походить від початкового і вільного випуску ssh 1.2.12, автором якого є Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt і Dug Song усунули багато вад, додали нові можливості та створили OpenSSH. Markus Friedl зробив внесок у підтримку версій протоколу SSH 1.5 і 2.0.
Український переклад цієї сторінки посібника виконано Andrij Mizyk <andmizyk@gmail.com>, Andriy Rysin <arysin@gmail.com> і Yuri Chornoivan <yurchor@ukr.net>
Цей переклад є безкоштовною документацією; будь ласка, ознайомтеся з умовами GNU General Public License Version 3. НЕ НАДАЄТЬСЯ ЖОДНИХ ГАРАНТІЙ.
Якщо ви знайшли помилки у перекладі цієї сторінки підручника, будь ласка, надішліть електронний лист до списку листування перекладачів: trans-uk@lists.fedoraproject.org
$Mdocdate: 10 вересня 2022 року $ | Debian |