SSH_CONFIG(5) | File Formats Manual | SSH_CONFIG(5) |
ssh_config
—
файл
налаштувань
клієнта OpenSSH
ssh(1) отримує дані налаштувань з наступних джерел у такому порядку:
Для
кожного
параметра
буде
використано
перше
отримане
значення.
Файли
налаштувань
містять
розділи,
розділені
специфікаціями
Host
, і цей
розділ
застосовується
лише до
вузлів, які
відповідають
одному із
шаблонів,
наведених
у
специфікації.
Узгоджена
назва
вузла,
зазвичай, є
назвою,
зазначеною
в
командному
рядку
(винятки
див. у
параметрі
CanonicalizeHostname
).
Оскільки для кожного параметра використовується перше отримане значення, більше специфічних для вузла оголошень слід надавати біля початку файлу, а загальні типові значення — в кінці.
Зауважте,
що у
пакунку Debian
для openssh-client
у
/etc/ssh/ssh_config
встановлено
деякі
параметри,
які не є
типовими
для ssh(1):
Include
/etc/ssh/ssh_config.d/*.conf
SendEnv
LANG LC_*HashKnownHosts
yesGSSAPIAuthentication
yesФайли /etc/ssh/ssh_config.d/*.conf буде включено на початку загальносистемного файл налаштувань, тому встановлені там значення параметрів матимуть пріоритет над встановленими у /etc/ssh/ssh_config.
Файл
містить
пари
ключове
слово-аргумент,
по одній у
рядку.
Рядки, що
починаються
з ‘#
’, і
порожні
рядки
інтерпретуються
як
коментарі.
Аргументи
можна
брати у
подвійні
лапки (") для
подання
аргументів,
що містять
пропуски.
Параметри
налаштувань
можна
розділяти
пропусками
або
необов'язковим
пропуском
і рівно
одним
‘=
’;
останній
формат
корисний
для
уникнення
необхідності
вводити
пропуск у
лапки під
час
визначення
параметрів
налаштувань
за
допомогою
параметрів
ssh
, scp
і
sftp
-o
.
Можливі ключові слова та їх значення такі (зверніть увагу, що ключові слова не чутливі до регістру, а аргументи чутливі):
Host
Host
або Match
)
лише для
тих машин,
які
відповідають
одному із
шаблонів,
наведених
після
ключового
слова. Якщо
надано
більше
одного
шаблону, їх
слід
розділити
пропусками.
Одним
‘*
’ як
шаблоном
позначають
типові
глобальні
значення
для всіх
машин.
Машина
зазвичай є
аргументом
hostname,
наведеним
у
командному
рядку (щодо
винятків
див.
ключове
слово
CanonicalizeHostname
).
Елемент
шаблону
можна
заперечувати,
додавши
до нього
знак
оклику (‘!’).
Якщо
збігається
елемент
із
запереченням,
елемент
Host
нехтується,
незалежно
від того,
чи
збігаються
інші
шаблони в
рядку.
Тому
заперечні
збіги
корисні
для
задання
винятків
для
збігів із
підставними
символами.
Див. PATTERNS щодо докладнішої інформації про шаблони.
Match
Host
або Match
),
лише якщо
задоволено
умови,
зазначені
після
ключового
слова Match
.
Умови
відповідності
задаються
за
допомогою
одного або
кількох
критеріїв
або
єдиного
маркера
all
, який
збігається
завжди.
Доступні
ключові
слова
критеріїв:
canonical
, final
,
exec
, host
,
originalhost
, user
і localuser
.
Критерії
all
мають
з’являтися
окремо або
відразу
після canonical
чи final
.
Інші
критерії
можна
комбінувати
довільно.
Усі
критерії,
крім all
,
canonical
і final
,
вимагають
аргументу.
Критерій
можна
скасувати,
додавши
перед ним
знак
оклику (‘!’).
Ключове
слово
canonical
вважається
відповідним,
лише коли
файл
налаштувань
повторно
аналізується
після
канонізації
назви
машини
(див.
параметр
CanonicalizeHostname
). Це
може бути
корисно
для
визначення
умов, які
працюють
лише з
канонічними
назвами
машин.
Ключове
слово final
вимагає
повторного
аналізу
налаштувань
(незалежно
від того,
чи
ввімкнено
CanonicalizeHostname
), і
відповідає
лише під
час цього
останнього
проходу.
Якщо
CanonicalizeHostname
увімкнено,
то canonical
і
final
під
час
одного
проходу
збігаються.
Ключове
слово exec
виконує
вказану
команду в
оболонці
користувача.
Якщо
команда
повертає
нульовий
стан
виходу, то
умова
вважається
правдивою.
Команди,
що
містять
пробіли
слід
брати у
лапки.
Аргументи
для exec
приймають
жетони,
описані у
розділі
ЖЕТОНИ.
Критеріями
інших
ключових
слів
мають
бути
окремими
записами
або
списками,
розділеними
комами, і
можуть
використовувати
символи-замінники
та
заперечення,
описані в
розділі
PATTERNS.
Критерії
для
ключового
слова host
відповідають
назві
цільової
машини
після
будь-якої
заміни
параметрами
Hostname
або
CanonicalizeHostname
.
Ключове
слово
originalhost
збігається
з назвою
машини,
зазначеною
в
командному
рядку.
Ключове
слово user
відповідає
цільовому
імені
користувача
на
віддаленій
машині.
Ключове
слово
localuser
відповідає
імені
локального
користувача,
який
запускає
ssh(1) (це
ключове
слово
може бути
корисним
у
загальносистемних
файлах
ssh_config
).
AddKeysToAgent
yes
, і ключ
завантажено
з файла,
ключ і його
пароль
буде
додано до
агента з
типовим
строком
дії, як за
допомогою
ssh-add(1). Якщо
для цього
параметра
встановлено
значення
ask
, ssh(1)
потребуватиме
підтвердження
за
допомогою
програми
SSH_ASKPASS
перед
додаванням
ключа (див.
ssh-add(1), щоб
дізнатися
більше).
Якщо для
цього
параметра
встановлено
значення
confirm
,
доведеться
підтверджувати
кожне
використання
ключа так,
наче було
вказано
параметр
-c
для
ssh-add(1). Якщо
для цього
параметра
встановлено
значення
no
, ключі
до агента
додано не
буде. Крім
того, для
цього
параметра
можна
вказати
інтервал
часу з
використанням
формату,
який
описано у
розділі
ФОРМАТИ
ЧАСУ
сторінки
підручника
sshd_config(5), для
визначення
строку дії
ключа в
ssh-agent(1), по
завершенню
якого ключ
буде
автоматично
вилучено.
Аргументом
має бути
no
(«ні»,
типове
значення),
yes
(«так»),
confirm
(«підтверджувати»,
до якого
можна
додати
інтервал
часу), ask
(«питати»)
або
інтервал
часу.AddressFamily
any
(типовий),
inet
(вживати
лише IPv4) або
inet6
(вживати
лише IPv6).BatchMode
yes
,
взаємодія
з
користувачем,
як
наприклад,
підказки
паролю, та
запити
щодо
підтвердження
ключа
машини,
буде
вимкнена.
Окрім того,
для
параметра
ServerAliveInterval
типово
буде
встановлено
значення 300
секунд
(специфічне
для Debian). Цей
параметр
корисний в
скриптах
та інших
пакетних
завданнях,
де немає
користувача
для
взаємодії
ssh(1).
Аргументом
має бути
yes
або
no
(типовий).BindAddress
BindInterface
CanonicalDomains
CanonicalizeHostname
, цей
параметр
задає
список
суфіксів
доменів, у
яких слід
шукати
вказаний
вузол
призначення.CanonicalizeFallbackLocal
yes
, буде
зроблено
спробу
виконати
пошук
неточної
назви
вузла за
допомогою
правил
пошуку
засобу
визначення
адрес
системи.
Використання
значення
no
призведе
до того, що
ssh(1)
негайно
завершить
роботу,
якщо
увімкнено
CanonicalizeHostname
і
назву
вузла
призначення
не буде
знайдено у
жодному з
доменів,
які
вказано
параметром
CanonicalDomains
.CanonicalizeHostname
no
,
передбачено
невиконання
будь-яких
перезаписів
назв і
передання
загальносистемному
засобу
визначення
назв
можливостей
виконання
усіх
пошуків
назв
вузлів.
Якщо
встановлено
значення
yes
, для
з'єднань, у
яких не
використовується
ProxyCommand
або
ProxyJump
, ssh(1)
спробує
переводити
у
канонічну
форму
назви
вузла, які
вказано у
командному
рядку за
допомогою
суфіксів
CanonicalDomains
і
правил
CanonicalizePermittedCNAMEs
.
Якщо для
CanonicalizeHostname
встановлено
значення
always
,
переведення
у
канонічну
форму буде
застосовано
також і до
пропущених
через
проксі-сервер
з'єднань.
Якщо
увімкнено
цей
параметр,
файли
налаштувань
буде
оброблено
знову з
використанням
нової
назви
призначення
для
актуалізації
будь-яких
нових
налаштувань
у
відповідних
інструкціях
Host
і Match
.
Значення
none
призведе
до
вимикання
використання
вузла
ProxyJump
.
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
Наприклад, "*.a.example.com:*.b.example.com,*.c.example.com" дозволить встановлення для назв вузлів, які відповідають взірцю "*.a.example.com", переведення у канонічну форму до назв у доменах "*.b.example.com" або "*.c.example.com".
Використання одинарного аргументу "none" призведе до того, що CNAME не розглядатимуться при приведенні до канонічної форми. Це типова поведінка.
CASignatureAlgorithms
ssh-ed25519,ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, sk-ssh-ed25519@openssh.com, sk-ecdsa-sha2-nistp256@openssh.com, rsa-sha2-512,rsa-sha2-256
Якщо вказаний список починається із символу ‘+’, вказані алгоритми буде дописано до типового набору, а не використано замість типового набору. Якщо вказаний список починатиметься із символу ‘-’, вказані алгоритми (разом із відповідними до вказаних шаблонів) буде вилучено з типового набору, а не використано замість типового набору.
ssh(1) не прийматиме сертифікати вузлів, які підписано алгоритмами, яких немає у вказаному списку.
CertificateFile
IdentityFile
, або
прапорця
-i
команди
ssh(1), з
використанням
ssh-agent(1), PKCS11Provider
або SecurityKeyProvider
.
У
аргументах
CertificateFile
можна
використовувати
символ
тильди
для
позначення
домашнього
каталогу
користувача,
жетони,
які
описано у
розділі
ЖЕТОНИ
та змінні
середовища,
як їх
описано у
розділі
ЗМІННІ
СЕРЕДОВИЩА.
У файлах
налаштувань
можна
вказувати
декілька
файлів
сертифікатів;
програми
намагатимуться
скористатися
цими
сертифікатами
послідовно.
Якщо
вказати
декілька
інструкцій
CertificateFile
,
сертифікати
буде
додано до
списку
сертифікатів,
які
використовуватимуться
для
розпізнавання.
CheckHostIP
yes
, ssh(1)
автоматично
шукатиме
IP-адресу
вузла у
файлі
known_hosts. Це
надасть
програмі
змогу
визначити,
чи було
змінено
ключ вузла
через
підміну DNS, і
у процесі
обробки
додати
адреси
вузлів
призначення
у ~/.ssh/known_hosts,
незалежно
від
значення
параметра
StrictHostKeyChecking
.
Якщо для
параметра
встановлено
значення
no
(типове),
пошук не
відбуватиметься.Ciphers
Підтримувані шифрування:
3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com chacha20-poly1305@openssh.com
Типове:
chacha20-poly1305@openssh.com, aes128-ctr,aes192-ctr,aes256-ctr, aes128-gcm@openssh.com,aes256-gcm@openssh.com
Список доступних шифрувань також можна отримати за допомогою команди "ssh -Q cipher".
ClearAllForwardings
yes
або
no
(типове
значення).Compression
yes
або
no
(типовий
варіант).ConnectionAttempts
ConnectTimeout
ControlMaster
yes
, ssh(1)
очікуватиме
на
з'єднання
на
керівному
сокеті,
який
вказано за
допомогою
аргументу
ControlPath
.
Додаткові
сеанси
можна
з'єднати з
цим
сокетом за
допомогою
того
самого
ControlPath
із
встановленим
для ControlMaster
значенням
no
(типове
значення).
У цих
сеансах
буде
зроблено
спробу
повторно
використати
з'єднання
мережі
основного
екземпляра,
а не
ініціювати
нові
з'єднання.
Якщо ж
використати
з'єднання
повторно
не
вдасться
через те,
що
керівного
сокета не
існуватиме,
або через
те, що на
ньому не
можна буде
очікувати
на дані,
резервним
варіантом
буде
звичайне
встановлення
з'єднання.
Встановлення
для цього
параметра
значення
ask
призведе
до того, що
ssh(1)
очікуватиме
на
керівні
з'єднання,
але
потребуватиме
підтвердження
за
допомогою
ssh-askpass(1). Якщо
не
вдасться
відкрити
ControlPath
, ssh(1)
продовжуватиме
роботу
без
з'єднання
із
основним
екземпляром.
Передбачено підтримку переспрямування X11 і ssh-agent(1) для цих ущільнених з'єднань. Втім, переспрямування дисплеїв та агентів буде переспрямуванням тих елементів, які належать до основного з'єднання, тобто не можна переспрямовувати декілька дисплеїв або агентів.
Два
додаткових
параметри
забезпечують
кон'юнктурне
ущільнення:
спочатку
спроба
скористатися
основним
з'єднанням,
але у
резервному
випадку
створення
з'єднання,
якщо його
ще не
існує.
Цими
параметрами
є такі: auto
і autoask
.
Останній
параметр
потребує
підтвердження,
подібно
до
параметра
ask
.
ControlPath
ControlMaster
вище,
або рядок
none
для
вимикання
спільного
використання
з'єднання.
У
аргументах
ControlPath
можна
використовувати
символ
тильди для
позначення
домашнього
каталогу
користувача,
жетони, які
описано у
розділі
ЖЕТОНИ,
та змінні
середовища,
які
описано у
розділі
ЗМІННІ
СЕРЕДОВИЩА.
Рекомендуємо,
щоб
будь-які
значення
ControlPath
, які
використано
для
кон'юнктурного
спільного
користування
з'єднанням,
включали
принаймні
%h, %p і %r (або %C), і
їх було
розташовано
у каталозі,
який є
непридатним
для запису
іншими
користувачами.
Таким
чином
можна
забезпечити
однозначну
ідентифікацію
спільних
з'єднань.ControlPersist
ControlMaster
,
визначає,
що основне
з'єднання
має
лишатися
відкритим
у фоновому
режимі
(очікувати
на
майбутні
з'єднання
клієнтів)
після того,
як
початкове
клієнтське
з'єднання
буде
розірвано.
Якщо
встановлено
значення
no
(типове
значення),
основне
з'єднання
не буде
переведено
у фоновий
режим —
його буде
розірвано,
щойно буде
розірвано
початкове
клієнтське
з'єднання.
Якщо
встановлено
значення
yes
або 0,
основне
з'єднання
лишатиметься
працювати
у фоновому
режимі без
часових
обмежень
(аж доки
його не
буде
знищено
або
розірвано
за
допомогою
механізмів,
подібних
до "ssh -O exit").
Якщо
встановлено
час у
секундах
або час у
будь-якому
форматі,
який
документовано
на
сторінці
підручника
sshd_config(5),
фонове
основне
з'єднання
буде
автоматично
розірвано,
якщо воно
лишатиметься
бездіяльним
(без
клієнтських
з'єднань)
протягом
вказаного
періоду
часу.DynamicForward
Аргументом
має бути
[bind_address:]порт.
IPv6-адреси
можна
вказувати
у
квадратних
дужках.
Типово,
локальний
порт
прив'язаний
відповідно
до
параметра
GatewayPorts
.
Однак,
можна
вжити
явну bind_address,
щоб
прив'язати
з'єднання
до
потрібної
адреси.
bind_address на
localhost
вказує, що
порт
слухання
буде
прив'язаний
лише для
локального
використання,
а порожня
адреса
або ‘*’
вказує, що
порт буде
доступний
зі всіх
інтерфейсів.
У поточній версії передбачено підтримку протоколів SOCKS4 і SOCKS5, а ssh(1) працюватиме як сервер SOCKS. Може бути вказано декілька переспрямувань, а додаткові переспрямування можна вказати у рядку команди. Переспрямування привілейованих портів може виконувати лише суперкористувач.
EnableEscapeCommandline
EscapeChar
для
інтерактивних
сеансів
(типовим є
‘~C
’).
Типово,
командний
рядок
вимкнено.EnableSSHKeysign
yes
у
файлі
загальних
клієнтських
налаштувань
/etc/ssh/ssh_config
вмикає
використання
допоміжної
програми
ssh-keysign(8) під
час
виконання
HostbasedAuthentication
.
Аргументом
має бути
yes
або
no
(типове
значення).
Цей
параметр
слід
розташовувати
у розділі,
який не є
специфічним
для вузла.
Див.
сторінку
підручника
ssh-keysign(8), щоб
дізнатися
більше.EscapeChar
~
’).
Крім того,
керівний
символ
можна
вказати у
рядку
команди.
Аргументом
має бути
одинарний
символ
‘^
’,
після
якого має
бути
вказано
літеру, або
none
, щоб
повністю
вимкнути
керівний
символ (що
зробить
з'єднання
прозорим
для
двійкових
даних).ExitOnForwardFailure
ExitOnForwardFailure
не
стосується
з'єднань,
створених
через
переспрямування
портів, і
не буде,
наприклад,
спричиняти
вихід з
ssh(1), якщо
спроба
з'єднання TCP
до
кінцевого
призначення
переспрямування
завершиться
невдало.
Аргументом
може бути
yes
або
no
(типове
значення).FingerprintHash
md5
і sha256
(типовий
варіант).ForkAfterAuthentication
ssh
щодо
переходу у
фоновий
режим
перед
самим
виконанням
команди. Це
корисно,
якщо ssh
має
надіслати
запит щодо
паролів,
але
користувачеві
потрібно,
щоб це було
зроблено у
фоновому
режимі.
Неявним
чином
встановлює
для
параметра
налаштувань
StdinNull
значення
“yes”.
Рекомендованим
способом
запуску
програм X11
на
віддаленому
вузлі є
щось
подібне до
ssh -f host xterm
, що є
тим самим,
що і ssh host xterm
,
якщо для
параметра
налаштувань
ForkAfterAuthentication
встановлено
значення
“yes”.
Якщо
параметр
для
параметра
налаштувань
ExitOnForwardFailure
встановлено
значення
“yes”, тоді
клієнт,
запущений
з
параметром
налаштувань
ForkAfterAuthentication
,
для якого
встановлено
значення
“yes”, буде
чекати,
доки всі
переспрямування
віддалених
портів
буде
успішно
з'єднано,
перед тим,
як
перейти у
фоновий
режим.
Аргументом
для цього
ключового
слова має
бути yes
(так само,
як в
параметрі
-f
) або
no
(типове
значення).
ForwardAgent
yes
, no
(типове),
явний шлях
до сокета
агента або
назва
змінної
середовища
(що
починається
з ‘$’), у якій
слід
шукати
шлях.
Переспрямування агента треба вмикати обережно Користувачі з можливістю обходу дозволів файлів на віддаленому вузла (для сокета домену UNIX агента) можуть отримати доступ до локального агента через переспрямоване з'єднання. Зловмисники не зможуть отримати матеріали ключів від агента, однак вони можуть виконати дії з ключами, що дозволить їм пройти розпізнавання за допомогою профілів, які завантажено до агента.
ForwardX11
DISPLAY
.
Аргументом
має бути
yes
або
no
(типовий
варіант).
Слід
бути
обережним
із
вмиканням
переспрямовування
X11.
Користувачі
з
можливістю
обходу
дозволу
файлів на
віддаленому
вузлі (для
бази
даних
уповноважень
користувача
X11) зможуть
доступитися
до
локального
дисплея X11
через
переспрямоване
з'єднання.
Зловмисник
зможе
виконувати
дії,
наприклад
стеження
за
натиснутими
клавішами,
якщо
також
увімкнено
параметр
ForwardX11Trusted
.
ForwardX11Timeout
ForwardX11Timeout
в
нуль
вимкне
обмеження
часу
очікування
і
дозволить
переспрямування
X11 на весь
час
з'єднання.
Типовим є
вимкнути
недовірені
переспрямування
X11 після 20
хвилин.ForwardX11Trusted
yes
,
(специфічне
для Debian
типове
значення),
віддалені
клієнти X11
матимуть
повний
доступ до
початкового
дисплея X11.
Якщо
параметр
встановлено
в no
(типове
значення
в
основній
гілці
розробки)
віддалені
X11 клієнти
будуть
розглядатися,
як
недовірені,
і їм буде
заборонено
викрадення
або
фальсифікацію
даних, що
належать
клієнтам X11.
Більше
того,
жетон xauth(1),
використаний
для
сеансу
буде мати
строк дії 20
хвилин.
Віддаленим
клієнтам
буде
відмовлено
в доступі
після
цього
часу.
Щодо повного опису обмежень, які буде накладено на недовірені клієнти, див. специфікацію розширення SECURITY X11.
GatewayPorts
GatewayPorts
можна
використовувати,
щоб ssh
прив'язував
переспрямування
локальних
портів до
шаблонної
адреси,
таким
чином,
дозволяючи
віддаленим
портам
приєднуватися
до
переспрямованих
портів.
Аргументом
має бути
yes
або
no
(типове
значення).GlobalKnownHostsFile
GSSAPIAuthentication
no
(ні).GSSAPIClientIdentity
GSSAPIDelegateCredentials
no
(ні).GSSAPIKeyExchange
GSSAPIRenewalForcesRekey
Буде виконано перевірки з метою забезпечення передавання реєстраційних даних лише при відповідності нових реєстраційних даних старим на вихідному клієнті і наявності старого набору у кеші сервера-отримувача.
Типовим значенням є “no” (ні).
Щоб це
спрацювало,
на
сервері
має бути
увімкнено,
а також
використано
клієнтом,
GSSAPIKeyExchange
.
GSSAPIServerIdentity
GSSAPITrustDns
GSSAPIKexAlgorithms
gss-gex-sha1-, gss-group1-sha1-, gss-group14-sha1-, gss-group14-sha256-, gss-group16-sha512-, gss-nistp256-sha256-, gss-curve25519-sha256-
Типовим набором є “gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-,gss-gex-sha1-,gss-group14-sha1-”. Цей параметр стосується лише з'єднань із використанням GSSAPI.
HashKnownHosts
no
.
Зауважте,
що вже
наявні
назви та
адреси у
відомих
файлах
машин не
буде
конвертовано
автоматично,
але їх
можна
хешувати
вручну за
допомогою
ssh-keygen(1).
Використання
цього
параметра
може
зашкодити
використанню
можливостей,
подібних
до
доповнення
за Tab, які
покладаються
на
можливість
читання
нехешованих
назв
вузлів з
~/.ssh/known_hosts.HostbasedAcceptedAlgorithms
ssh-ed25519-cert-v01@openssh.com, ecdsa-sha2-nistp256-cert-v01@openssh.com, ecdsa-sha2-nistp384-cert-v01@openssh.com, ecdsa-sha2-nistp521-cert-v01@openssh.com, sk-ssh-ed25519-cert-v01@openssh.com, sk-ecdsa-sha2-nistp256-cert-v01@openssh.com, rsa-sha2-512-cert-v01@openssh.com, rsa-sha2-256-cert-v01@openssh.com, ssh-ed25519, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, sk-ssh-ed25519@openssh.com, sk-ecdsa-sha2-nistp256@openssh.com, rsa-sha2-512,rsa-sha2-256
Для
визначення
списку
підтримуваних
алгоритмів
підписування
можна
скористатися
параметром
-Q
команди
ssh(1).
Раніше це
був
параметр
HostbasedKeyTypes.
HostbasedAuthentication
yes
або
no
(типовий
варіант).HostKeyAlgorithms
ssh-ed25519-cert-v01@openssh.com, ecdsa-sha2-nistp256-cert-v01@openssh.com, ecdsa-sha2-nistp384-cert-v01@openssh.com, ecdsa-sha2-nistp521-cert-v01@openssh.com, sk-ssh-ed25519-cert-v01@openssh.com, sk-ecdsa-sha2-nistp256-cert-v01@openssh.com, rsa-sha2-512-cert-v01@openssh.com, rsa-sha2-256-cert-v01@openssh.com, ssh-ed25519, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com, rsa-sha2-512,rsa-sha2-256
Якщо ключі вузла є відомими для вузла призначення, це типове значення буде змінено з метою пріоритетного використання алгоритмів ключів вузла.
Список доступних алгоритмів підписування можна також отримати за допомогою "ssh -Q HostKeyAlgorithms".
HostKeyAlias
Hostname
Hostname
можна
використовувати
жетони, які
описано у
розділі
ЖЕТОНИ.
Також
можна
використовувати
числові
IP-адреси (у
рядку
команди і у
специфікаціях
Hostname
).
Типовою є
назва, яку
задано у
рядку
команди.IdentitiesOnly
ssh_config
або
передано у
рядку
команди
ssh(1)),
навіть
якщо у ssh-agent(1),
PKCS11Provider
або
SecurityKeyProvider
передбачено
більше
профілів.
Аргументом
до цього
ключового
слова має
бути yes
або no
(типове
значення).
Цей
параметр
призначено
для
випадків,
коли ssh-agent
пропонує
багато
різних
профілів.IdentityAgent
Цей
параметр
перевизначає
змінну
середовища
SSH_AUTH_SOCK
. Ним
можна
скористатися
для
вибору
певного
агента.
Встановлення
назви
сокета
none
вимикає
використання
агента
розпізнавання.
Якщо
вказано
рядок "SSH_AUTH_SOCK"
розташування
сокета
буде
прочитано
зі
змінної
середовища
SSH_AUTH_SOCK
. В
інших
випадках,
якщо
вказана
значення
починається
з символу
‘$’, його
буде
оброблено
як змінну
середовища,
яка
містить
розташування
сокета.
У
аргументах
IdentityAgent
можна
використовувати
символ
тильди
для
позначення
домашнього
каталогу
користувача,
жетони,
які
описано у
розділі
ЖЕТОНИ
та змінні
середовища,
як їх
описано у
розділі
ЗМІННІ
СЕРЕДОВИЩА.
IdentityFile
IdentitiesOnly
. Якщо
не було
явним
чином не
встановлено
сертифікати
за
допомогою
CertificateFile
, ssh(1)
спробує
завантажити
дані
сертифіката
з файла із
назвою, яку
буде
утворено
дописуванням
-cert.pub до
шляху до
вказаного
IdentityFile
.
У
аргументах
IdentityFile
можна
використовувати
синтаксичні
конструкції
із
тильдою
для
визначення
домашнього
каталогу
користувача
або
жетони,
які
описано у
розділі
ЖЕТОНИ.
У файлах
налаштувань
можна
вказувати
декілька
файлів
профілів;
програма
послідовно
спробує
скористатися
усіма
профілями
послідовно.
Якщо буде
використано
декілька
інструкцій
IdentityFile
,
профілі
буде
додано до
списку
профілів,
які
пробуватиме
програма
(ця
поведінка
відрізняється
від
поведінки
інших
інструкцій
налаштовування).
IdentityFile
можна
використовувати
у
поєднанні
із IdentitiesOnly
для
вибору,
які
профілі в
агенті
буде
запропоновано
під час
розпізнавання.
IdentityFile
може
бути
також
використано
у
поєднанні
із CertificateFile
з
метою
надання
будь-якого
сертифіката,
який
також
потрібен
для
розпізнавання
за
допомогою
профілю.
IgnoreUnknown
ssh_config
використано
параметри,
які не
розпізнає
ssh(1).
Рекомендуємо
розташовувати
IgnoreUnknown
на
початку
файла
налаштувань,
оскільки
його не
буде
застосовано
до
невідомих
параметрів,
які
трапляться
у файлі
перед ним.Include
Include
можна
скористатися
у блоках
Match
і Host
для
виконання
умовного
включення.IPQoS
af11
, af12
,
af13
, lowdelay
,
af22
, af23
,
af31
, af32
,
af33
, af41
,
af42
, af43
,
cs0
, throughput
,
cs2
, cs3
,
cs4
, cs5
,
cs6
, cs7
,
ef
, le
,
lowdelay
, throughput
,
reliability
,
числове
значення
або none
,
якщо слід
скористатися
типовим
значенням
для
операційної
системи.
Цей
параметр
може
приймати
один або
два
аргументи,
які слід
відокремити
пробілом.
Якщо
вказано
один
аргумент,
його буде
використано
як
пакетний
клас
безумовно.
Якщо
вказано
два
аргументи,
перший
буде
автоматично
вибрано
для
інтерактивних
сеансів, а
другий —
для
неінтерактивних.
Типовим є
значення
lowdelay
для
інтерактивних
сеансів і
throughput
для
неінтерактивних
сеансів.KbdInteractiveAuthentication
yes
(типовий
варіант)
або no
.
Застарілою
альтернативою
цього
параметра
є ChallengeResponseAuthentication
.KbdInteractiveDevices
bsdauth
та
pam
.KexAlgorithms
sntrup761x25519-sha512@openssh.com, curve25519-sha256,curve25519-sha256@libssh.org, ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group16-sha512, diffie-hellman-group18-sha512, diffie-hellman-group14-sha256
Список доступних алгоритмів обміну ключами можна також отримати за допомогою команди "ssh -Q kex".
KnownHostsCommand
UserKnownHostsFile
та
GlobalKnownHostsFile
. Цю
команду
буде
виконано
після
читання
усіх
файлів.
Команда
може
записувати
рядки
ключів
вузла до
стандартного
виведення
у форматі,
який є
тотожним
до формату
звичайних
файлів
(який
описано у
розділі
ПЕРЕВІРКА
КЛЮЧІВ
ВУЗЛА
сторінки
підручника
ssh(1)).
Аргументи
KnownHostsCommand
можуть
використовувати
жетони, які
описано у
розділі
ЖЕТОНИ.
Команду
може бути
викликано
декілька
разів на
з'єднання:
один раз
при
приготуванні
списку
налаштувань
алгоритмів
ключів
вузла,
якими слід
користуватися,
і знову для
отримання
ключа
вузла для
запитаної
назви
вузла, і,
якщо
увімкнено
CheckHostIP
, ще
раз для
отримання
ключа
вузла, який
відповідає
адресі
сервера.
Якщо
виконання
команди
завершується
нештатно
або станом
виходу є
ненульовий,
з'єднання
буде
розірвано.LocalCommand
LocalCommand
можна
використовувати
жетони, які
описано у
розділі
ЖЕТОНИ.
Команда працює синхронно і не має доступу до сеансу ssh(1), який її породив. Цим не можна скористатися для інтерактивних команд.
Цю
інструкцію
буде
проігноровано,
якщо не
було
увімкнено
PermitLocalCommand
.
LocalForward
Адреси IPv6
може бути
вказано
за
допомогою
взяття
адрес у
квадратні
дужки.
Можна
вказати
декілька
переспрямувань,
а
додаткові
переспрямування
можна
вказати у
рядку
команди.
Переспрямування
на
привілейовані
порти
може
вказувати
лише
суперкористувач.
Типово,
локальний
порт буде
прив'язано
відповідно
до
параметра
GatewayPorts
. Втім,
можна
скористатися
явним
bind_address для
прив'язування
з'єднання
до
вказаної
адреси.
Аргумент
bind_address localhost
вказує на
те, що порт
очікування
даних
буде
пов'язано
лише із
локальним
використанням,
а порожня
адреса
або ‘*’
вказує на
те, що порт
має бути
доступним
з усіх
інтерфейсів.
У шляхах
до сокета
домену UNIX
можна
використовувати
жетони,
які
описано у
розділі
ЖЕТОНИ
і змінні
середовища,
які
описано у
розділі
ЗМІННІ
СЕРЕДОВИЩА.
LogLevel
LogVerbose
kex.c:*:1000,*:kex_exchange_identification():*,packet.c:*
вмикає
ведення
докладного
журналу
для рядка 1000
файла kex.c,
усього у
функції
kex_exchange_identification
()
і усього
коду у
файлі
packet.c. Цей
параметр
призначено
для
діагностики.
Типово, не
увімкнено
жодних
перевизначень.
MACs
Записи алгоритмів, які містять "-etm", визначають обчислення MAC після шифрування (encrypt-then-mac). Такі алгоритми вважаються безпечнішими і є рекомендованими до використання.
Типове:
umac-64-etm@openssh.com,umac-128-etm@openssh.com, hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com, hmac-sha1-etm@openssh.com, umac-64@openssh.com,umac-128@openssh.com, hmac-sha2-256,hmac-sha2-512,hmac-sha1
Список доступних алгоритмів MAC можна також отримати за допомогою команди "ssh -Q mac".
NoHostAuthenticationForLocalhost
yes
або no
(типовий
варіант).NumberOfPasswordPrompts
PasswordAuthentication
yes
(типовий
варіант)
або no
.PermitLocalCommand
LocalCommand
або
керівної
послідовності
!
command в
ssh(1).
Аргументом
має бути
yes
або
no
(типовий
варіант).PermitRemoteOpen
RemoteForward
.
Специфікацію
переспрямування
має бути
записано у
одній з
таких форм:
PermitRemoteOpen
вузол:портPermitRemoteOpen
адреса_IPv4:портPermitRemoteOpen
[адреса_IPv6]:портПереспрямування
у списку
слід
відокремлювати
пробілами.
Можна
скористатися
аргументом
any
для
вилучення
усіх
обмежень
і
встановлення
дозволу
на
будь-які
запити
щодо
переспрямовування.
Можна
скористатися
аргументом
none
для
заборони
усіх
запитів
щодо
переспрямовування.
Для
встановлення
дозволу
для усіх
вузлів
або
портів,
відповідно,
можна
скористатися
шаблоном
заміни ‘*’.
В усіх
інших
випадках
для
наданих
назв не
буде
виконано
ніякого
встановлення
відповідності
за
взірцем
та ніяких
пошуків
адреси.
PKCS11Provider
none
,
визначає,
що не слід
користуватися
жодним
(типова
поведінка).
Аргументом
до цього
ключового
слова є
шлях до
бібліотеки
спільного
користування
PKCS#11, якою має
користуватися
ssh(1) для
обміну
даними з
жетоном PKCS#11,
який надає
ключі для
розпізнавання
користувачів.Port
PreferredAuthentications
keyboard-interactive
) над
іншим
способом
(наприклад
password
).
Типове
значення:
gssapi-with-mic,hostbased,publickey, keyboard-interactive,password
ProxyCommand
exec
’
командної
оболонки
користувача
для
уникнення
затримок
процесу
оболонки.
У
аргументах
ProxyCommand
можна
використовувати
жетони,
які
описано у
розділі
ЖЕТОНИ.
Командою
може бути
будь-що.
Команда
має
читати зі
стандартного
джерела
вхідних
даних і
записувати
дані до
стандартного
виведення.
Нарешті,
вона має
встановлювати
з'єднання
із
сервером
sshd(8), який
запущено
на тій
самій
машині,
або
виконувати
десь sshd -i
.
Керування
ключами
вузла
буде
виконано
з
використанням
Hostname
вузла, з
яким
встановлюється
з'єднання
(типовою
назвою є
назва, яку
введено
користувачем
з
клавіатури).
Встановлення
для
команди
значення
none
повністю
вимикає
цей
параметр.
Зауважте,
CheckHostIP
є
недоступним
для
з'єднань
за
допомогою
команди
проксі-сервера.
Ця інструкція корисна у поєднанні із nc(1) і його підтримкою проксі-серверів. Наприклад, вказана нижче конструкція призведе до встановлення з'єднання з використанням проксі-сервера HTTP з адресою 192.0.2.0:
ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
ProxyJump
ProxyJump
,
потім
встановивши
переспрямування
TCP до
остаточного
призначення.
Встановлення
для вузла
значення
none
повністю
вимикає
дію цього
параметра.
Зауважте,
що цей
параметр
конкурує
із
параметром
ProxyCommand
— той,
який буде
вказано
першим,
запобігатиме
використанню
усіх
наступних
екземплярів
цих
параметрів.
Зауважте також, що налаштування для вузла призначення (вказаного або за допомогою командного рядка, або за допомогою файла налаштувань) загалом буде застосовано до вузлів переходу. ~/.ssh/config має бути використано, якщо певні налаштування потрібні для вузлів переходу.
ProxyUseFdpass
ProxyCommand
передасть
з'єднаний
дескриптор
файла
назад ssh(1),
замість
продовження
виконання
та
передавання
даних.
Типовим
значенням
є no
.PubkeyAcceptedAlgorithms
ssh-ed25519-cert-v01@openssh.com, ecdsa-sha2-nistp256-cert-v01@openssh.com, ecdsa-sha2-nistp384-cert-v01@openssh.com, ecdsa-sha2-nistp521-cert-v01@openssh.com, sk-ssh-ed25519-cert-v01@openssh.com, sk-ecdsa-sha2-nistp256-cert-v01@openssh.com, rsa-sha2-512-cert-v01@openssh.com, rsa-sha2-256-cert-v01@openssh.com, ssh-ed25519, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, sk-ssh-ed25519@openssh.com, sk-ecdsa-sha2-nistp256@openssh.com, rsa-sha2-512,rsa-sha2-256
Список доступних алгоритмів підписування можна також отримати за допомогою "ssh -Q PubkeyAcceptedAlgorithms".
PubkeyAuthentication
yes
(так,
типове
значення),
no
(ні),
unbound
(без
прив'язки)
або host-bound
(прив'язка
до вузла).
Останні
два
варіанти
вмикають
розпізнавання
за
відкритим
ключем,
одночасно
вимикаючи
або
вмикаючи
розширення
протоколу
розпізнавання
з
прив'язкою
до вузлів OpenSSH,
яке
потрібне
для
обмеженого
переспрямування
ssh-agent(1).RekeyLimit
RekeyLimit
є default
none
(немає), що
означає, що
повторне
узгодження
ключа
відбуватиметься
після
надсилання
або
отримання
типового
для
шифрування
об'єму
даних, а
обмеження
за часом
для
повторного
обміну
ключами
накладено
не буде.RemoteCommand
RemoteCommand
можна
використовувати
жетони, які
описано у
розділі
ЖЕТОНИ.RemoteForward
PermitRemoteOpen
.
Адреси IPv6 може бути вказано за допомогою взяття адрес у квадратні дужки. Можна вказати декілька переспрямувань, а додаткові переспрямування можна вказати у рядку команди. Переспрямування на привілейовані порти може вказувати лише користувач root на віддаленій машині. У шляхах до сокета домену UNIX можна використовувати жетони, які описано у розділі ЖЕТОНИ і змінні середовища, які описано у розділі ЗМІННІ СЕРЕДОВИЩА.
Якщо аргументом порт є 0, порт очікування даних буде виділено на сервері динамічним чином, а клієнта буде повідомлено про нього вже під час роботи з'єднання.
Якщо
адресу_прив'язки
не
вказано,
типовою
поведінкою
буде
прив'язування
лише до
адрес
петльового
(loopback)
інтерфейсу.
Якщо
значенням
адреси_прив'язки
є ‘*
’
або
порожній
рядок,
переспрямування
очікуватиме
на дані на
усіх
інтерфейсах.
Визначення
віддаленої
адреси_прив'язки
буде
успішним
лише тоді,
коли
увімкнено
параметр
GatewayPorts
сервера
(див. sshd_config(5)).
RequestTTY
no
(ніколи не
надсилати
запит щодо
TTY), yes
(завжди
надсилати
запит щодо
TTY, якщо
стандартним
джерелом
вхідних
даних є TTY),
force
(завжди
надсилати
запит щодо
TTY) або auto
(завжди
надсилати
запит щодо
TTY при
відкритті
сеансу
входу до
системи).
Цей
параметр
віддзеркалює
прапорці
-t
і -T
для ssh(1).RequiredRSASize
1024
бітів.
Зауважте,
що це
обмеження
може бути
лише
збільшено
відносно
типового
значення.RevokedHostKeys
SecurityKeyProvider
Якщо вказане значення починається із символу ‘$’, його буде оброблено як змінну середовища, що містить шлях до бібліотеки.
SendEnv
TERM
буде
надіслано
завжди,
коли буде
надіслано
запит щодо
псевдотермінала,
оскільки
він
потрібен
за
протоколом.
Зверніться
до розділу
щодо AcceptEnv
на
сторінці
підручника
sshd_config(5), щоб
дізнатися
про те, як
налаштувати
сервер.
Змінні
слід
вказувати
за назвою,
яка може
містити
символи-замінники.
Змінні
середовища
слід
відокремлювати
пробілами
або ділити
між
декількома
інструкціями
SendEnv
.
Див. PATTERNS щодо докладнішої інформації про шаблони.
Можна
вилучити
раніше
встановлені
назви
змінних
SendEnv
додаванням
до
взірців
префікса
-.
Типовою
поведінкою
є відмова
у
надсиланні
будь-яких
змінних
середовища.
ServerAliveCountMax
TCPKeepAlive
(нижче).
Повідомлення
підтримання
зв'язку
буде
надіслано
шифрованим
каналом, а
отже, їх не
можна буде
підробити.
Повідомлення
підтримання
зв'язку TCP,
які вмикає
TCPKeepAlive
,
можна
підробити.
Механізм
підтримання
зв'язку із
сервером є
важливим,
якщо
робота
клієнта
або
сервера
залежить
від
інформації
щодо того,
чи є
з'єднання
працездатним.
Типовим
значенням
є 3. Якщо,
наприклад,
для ServerAliveInterval
(див. нижче)
встановлено
значення 15,
а для
ServerAliveCountMax
залишено
типове
значення,
якщо
сервер
перестає
відповідати,
ssh розірве
з'єднання
за
приблизно
45 секунд.
ServerAliveInterval
BatchMode
(специфічно
для Debian).
Альтернативами
для
сумісності
у Debian для
цього
параметра
є ProtocolKeepAlives
та
SetupTimeOut
.SessionType
none
(те саме, що
і параметр
-N
), subsystem
(те саме, що
і параметр
-s
) або
default
(виконання
оболонки
або
команди).SetEnv
SendEnv
, за
винятком
змінної
TERM
,
сервер має
бути
приготовано
для
прийняття
змінної
середовища.StdinNull
ssh
запущено у
фоновому
режимі, має
бути
використано
або цей
параметр,
або
еквівалентний
параметр
-n
.
Аргументом
до цього
ключового
слова має
бути yes
(те саме, що
і параметр
-n
) або
no
(типове
значення).StreamLocalBindMask
Типовим значенням є 0177. Його використання призводить до створення файла сокета домену UNIX, який є придатним до читання і запису лише від імені власника. Зауважте, що підтримку режиму доступу до файлів сокетів домену UNIX передбачено не в усіх операційних системах.
StreamLocalBindUnlink
StreamLocalBindUnlink
не
було
увімкнено,
ssh
не
зможе
переспрямувати
порт до
файла
сокета
домену UNIX.
Цей
параметр
використовують
лише для
переспрямування
портів до
файла
сокета
домену UNIX.
Аргументом
має бути
yes
або
no
(типовий
варіант).
StrictHostKeyChecking
yes
, ssh(1)
ніколи не
додаватиме
ключі
вузла до
файла
~/.ssh/known_hosts і
відмовлятиме
у з'єднанні
із вузлами,
ключі яких
змінено.
Таким
чином
можна
досягти
максимального
захисту
від атак із
проміжною
підміною (MITM).
Втім, це
може
призвести
до зайвих
проблем,
якщо
супровід
файла
/etc/ssh/ssh_known_hosts є
неналежним
або якщо
часто
виникає
потреба у
встановленні
з'єднання
із новими
вузлами.
Використання
цього
параметра
примушуватиме
користувача
до
додавання
нових
вузлів
вручну.
Якщо для
цього
прапорця
встановлено
значення
accept-new
, ssh
автоматично
додаватиме
нові
ключів
вузлів до
файла
known_hosts
користувача,
але не
дозволятиме
встановлення
з'єднань
із
вузлами,
ключі
яких було
змінено.
Якщо для
цього
прапорця
встановлено
значення
no
або
off
, ssh
автоматично
додаватиме
ключі до
файлів
відомих
вузлів
користувача
і
дозволятиме
з'єднання
з вузлами
зі
зміненими
ключами
вузлів з
певними
обмеженнями.
Якщо для
цього
прапорця
встановлено
значення
ask
(типове
значення),
нові
ключів
вузлів
буде
додано до
файлів
відомих
вузлів
користувача
лише
після
підтвердження
з боку
користувача
щодо того,
що ця дія є
бажаною, а ssh
відмовлятиметься
встановлювати
з'єднання
з вузлами,
ключі
яких було
змінено. В
усіх
випадках
буде
виконано
автоматичну
перевірку
ключів
відомих
вузлів.
SyslogFacility
TCPKeepAlive
ServerAliveInterval
.
Втім, це
означає, що
з'єднання
буде
розірвано
при
тимчасовій
непрацездатності
маршруту, і
для декого
це може
бути
неприйнятним.
Типовим
значенням
є yes
(для
надсилання
повідомлень
підтримання
зв'язку TCP), а
клієнт
отримуватиме
повідомлення,
якщо
мережа
або
віддалений
вузол
стануть
непрацездатними.
Це
важливо у
скриптах,
а також
корисно
для
багатьох
користувачів.
Щоб
вимкнути
повідомлення
підтримання
зв'язку TCP,
слід
встановити
значення
no
. Див.
також
ServerAliveInterval
, щоб
дізнатися
більше
про
повідомлення
підтримання
зв'язку на
рівні
протоколів.
Tunnel
yes
, point-to-point
(шар 3), ethernet
(шар 2) або
no
(типовий
варіант).
Якщо
вказати
yes
, буде
надіслано
запит щодо
типового
режиму
тунелювання,
яким є
point-to-point
.TunnelDevice
Аргументом
має бути
локальний_тунель[:віддалений_тунель].
Пристрої
слід
вказувати
у форматі
числових
ідентифікаторів
або
ключового
слова any
,
яке
вказує на
те, що слід
використовувати
наступний
доступний
пристрій
тунелювання.
Якщо
віддалений_тунель
не
вказано,
типовим
значенням
буде any
.
Типовим
значенням
є any:any
.
UpdateHostKeys
UserKnownHostsFile
.
Аргументом
має бути
yes
, no
або ask
. За
допомогою
цього
параметра
можна
наказати
системі
вивчати
альтернативні
ключі
вузлів для
сервера і
підтримувати
штатну
ротацію
ключів
шляхом
надання
серверу
дозволу
надсилати
відкриті
ключі-замінники
до того, як
старі буде
вилучено.
Додаткові
ключі
вузлів
буде
прийнято,
лише якщо
ключ, який
використано
для
розпізнавання
вузла, вже
був
довіреним
або явним
чином
прийнятим
користувачем,
вузол
було
розпізнано
за
допомогою
UserKnownHostsFile
(тобто не
GlobalKnownHostsFile
) і
вузол
було
розпізнано
з
використанням
незашифрованого
ключа, а не
сертифіката.
Типово,
UpdateHostKeys
увімкнено,
якщо
користувачем
не
перевизначено
типовий
параметр
UserKnownHostsFile
і не
увімкнено
VerifyHostKeyDNS
. В
інших
випадках
для UpdateHostKeys
буде
встановлено
значення
no
.
Якщо для
UpdateHostKeys
встановлено
значення
ask
,
програма
проситиме
користувача
підтвердити
внесення
змін до
файла known_hosts.
Підтвердження
у
поточній
версії є
несумісними
з ControlPersist
,
отже, їх
буде
вимкнено,
якщо його
буде
увімкнено.
У поточній версії, підтримку розширення протоколу "hostkeys@openssh.com", яке буде використано для інформування клієнта щодо усіх ключів вузлів сервера, передбачено лише у sshd(8) з OpenSSH 6.8 і новіших версій.
User
UserKnownHostsFile
none
наказує
ssh(1)
ігнорувати
будь-які
специфічні
для
користувача
відомі
файли
вузлів.
Типовими
файлами є
~/.ssh/known_hosts,
~/.ssh/known_hosts2.VerifyHostKeyDNS
yes
,
клієнт
неявним
чином
довірятиме
ключам, які
відповідають
захищеному
відбитку
від DNS.
Незахищені
відбитки
буде
оброблено
так, наче
для
параметра
встановлено
значення
ask
. Якщо
для цього
параметра
встановлено
значення
ask
, буде
показано
дані щодо
відповідності
відбитка,
але
користувачеві
доведеться
підтверджувати
нові ключі
вузлів
відповідно
до
параметра
StrictHostKeyChecking
.
Типовим
значенням
є no
.
Див. також ПЕРЕВІРКА КЛЮЧІВ ВУЗЛА in ssh(1).
VisualHostKey
yes
, окрім
рядка
відбитка
при вході і
для
невідомих
ключів
вузла буде
показано
графічне
представлення
символами
ASCII відбитка
ключа
віддаленого
вузла. Якщо
для цього
прапорця
буде
встановлено
значення
no
(типовий
варіант)
при вході
до системи
не буде
виведено
рядків
відбитка, а
для
невідомих
ключів
вузлів
буде
виведено
лише рядок
відбитка.XAuthLocation
Взірець складається з нуля або більшої кількості символів, які не є пробілами, ‘*’ (символ, який є замінником нуля або більшої кількості довільних символів) або ‘?’ (символу-замінника, який відповідає одному довільному символу). Наприклад, щоб задати набір оголошень для будь-якого вузла у наборі доменів ".co.uk", можна скористатися таким взірцем:
Host *.co.uk
Вказаний нижче взірець відповідає будь-яким вузлом у діапазоні мережі 192.168.0.[0-9]:
Host 192.168.0.?
Список взірців — список відокремлених комами взірців. Взірці у списках взірців можна інвертувати додавши перед ними знак оклику (‘!’). Наприклад, щоб уможливити використання ключів з будь-якого місця в організації, окрім буфера "dialup", можна скористатися таким записом (в authorized_keys):
from="!*.dialup.example.com,*.example.com"
Зауважте, що інвертована відповідність ніколи не дасть сама собою позитивного результату. Наприклад, спроба встановлення відповідності запису "host3" за вказаним нижче списком взірців:
from="!host1,!host2"
Вирішенням є включення запису, який дасть позитивну відповідність, наприклад шаблона:
from="!host1,!host2,*"
У аргументах до деяких ключових слів може бути використано жетони, які буде розгорнуто під час роботи програм:
KnownHostsCommand
: або
ADDRESS
при
пошуку
вузла за
адресою
(лише якщо
увімкнено
CheckHostIP
), HOSTNAME
при пошуку
за назвою
вузла, або
ORDER
при
приготуванні
списку
пріоритетності
алгоритму
ключів
вузлів для
використання
для вузла
призначення.ssh-ed25519
.CertificateFile
,
ControlPath
, IdentityAgent
,
IdentityFile
,
KnownHostsCommand
,
LocalForward
, Match exec
,
RemoteCommand
, RemoteForward
і UserKnownHostsFile
приймають
жетони %%, %C, %d, %h, %i, %k, %L,
%l, %n, %p, %r і %u.
KnownHostsCommand
,
крім того,
приймає
жетони %f, %H, %I, %K і
%t.
Hostname
приймає
жетони %% і %h.
LocalCommand
приймає
усі
жетони.
ProxyCommand
і
ProxyJump
приймають
жетони %%, %h, %n, %p і
%r.
Аргументи
до деяких
ключових
слів може
бути
розгорнуто
під час
виконання
зі змінних
середовища
на боці
клієнта,
взявши їх у
${}
,
наприклад,
${HOME}/.ssh
вказуватиме
на каталог
.ssh у теці
користувача.
Якщо
вказаної
змінної
середовища
не існує,
буде
повернуто
повідомлення
про
помилку, а
значення
цього
ключового
слова буде
проігноровано.
У
ключових
словах
CertificateFile
,
ControlPath
, IdentityAgent
,
IdentityFile
,
KnownHostsCommand
та
UserKnownHostsFile
передбачено
підтримку
змінних
середовища.
У ключових
словах
LocalForward
і
RemoteForward
підтримку
змінних
середовища
передбачено
лише для
шляхів до
сокетів
домену UNIX.
OpenSSH походить від початкового і вільного випуску ssh 12.12, автором якого є Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt and Dug Song усунули багато вад, додали нові можливості та створили OpenSSH. Markus Friedl зробив внесок у підтримку версій протоколу SSH 1.5 і 2.0.
Український переклад цієї сторінки посібника виконано lxlalexlxl <lxlalexlxl@ukr.net>, Yuri Chornoivan <yurchor@ukr.net> і Andriy Rysin <arysin@gmail.com>
Цей переклад є безкоштовною документацією; будь ласка, ознайомтеся з умовами GNU General Public License Version 3. НЕ НАДАЄТЬСЯ ЖОДНИХ ГАРАНТІЙ.
Якщо ви знайшли помилки у перекладі цієї сторінки підручника, будь ласка, надішліть електронний лист до списку листування перекладачів: trans-uk@lists.fedoraproject.org
$Mdocdate: 13 січня 2023 року $ | Debian |