Provided by: manpages-uk_4.21.0-2_all 
НАЗВА
ssh_config — файл налаштувань клієнта OpenSSH
ОПИС
ssh(1) отримує дані налаштувань з наступних джерел у такому порядку:
1. параметри командного рядка
2. файл налаштувань користувача (~/.ssh/config)
3. загальносистемний файл налаштувань (/etc/ssh/ssh_config)
Якщо не зазначено іншого, для кожного параметра буде використано перше отримане значення. Файли
налаштувань містять розділи, розділені специфікаціями Host, і цей розділ застосовується лише до вузлів,
які відповідають одному із шаблонів, наведених у специфікації. Узгоджена назва вузла, зазвичай, є назвою,
зазначеною в командному рядку (винятки див. у параметрі CanonicalizeHostname).
Оскільки для кожного параметра використовується перше отримане значення, більше специфічних для вузла
оголошень слід надавати біля початку файлу, а загальні типові значення — в кінці.
Зауважте, що у пакунку Debian для openssh-client у /etc/ssh/ssh_config встановлено деякі параметри, які
не є типовими для ssh(1):
• Include /etc/ssh/ssh_config.d/*.conf
• SendEnv LANG LC_*
• HashKnownHosts yes
• GSSAPIAuthentication 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, localnetwork, host, originalhost, Tag, user і
localuser. Критерії all мають з’являтися окремо або відразу після canonical чи final. Інші
критерії можна комбінувати довільно. Усі критерії, крім all, canonical і final, вимагають
аргументу. Критерій можна скасувати, додавши перед ним знак оклику (‘!’).
Ключове слово canonical вважається відповідним, лише коли файл налаштувань повторно аналізується
після канонізації назви машини (див. параметр CanonicalizeHostname). Це може бути корисно для
визначення умов, які працюють лише з канонічними назвами машин.
Ключове слово final вимагає повторного аналізу налаштувань (незалежно від того, чи ввімкнено
CanonicalizeHostname), і відповідає лише під час цього останнього проходу. Якщо
CanonicalizeHostname увімкнено, то canonical і final під час одного проходу збігаються.
Ключове слово exec виконує вказану команду в оболонці користувача. Якщо команда повертає нульовий
стан виходу, то умова вважається правдивою. Команди, що містять пробіли слід брати у лапки.
Аргументи для exec приймають жетони, описані у розділі “ЖЕТОНИ”.
Для ключового слова localnetwork буде встановлено відповідність адресам активних інтерфейсів
локальної мережі за наданим списком мереж у форматі CIDR. Це може бути корисним для варіювання
задіяних налаштувань пристроїв, які працюють у різних мережах. Зауважте, що адреса у мережі не є
надійним критерієм у багатьох випадках (наприклад, якщо налаштовування мережі відбувається
автоматично за допомогою DHCP), і тому слід бути обережними при використанні її для керування у
середовищах із підвищеним рівнем захисту.
Критеріями інших ключових слів мають бути окремими записами або списками, розділеними комами, і
можуть використовувати символи-замінники та заперечення, описані в розділі “PATTERNS”. Критерії
для ключового слова host відповідають назві цільової машини після будь-якої заміни параметрами
Hostname або CanonicalizeHostname. Ключове слово originalhost збігається з назвою машини,
зазначеною в командному рядку. Ключове слово tagged відповідає назві теґу, яку вказано
попередньою інструкцією Tag або у рядку команди ssh(1) за допомогою прапорця -P. Ключове слово
user відповідає цільовому імені користувача на віддаленій машині. Ключове слово localuser
відповідає імені локального користувача, який запускає ssh(1) (це ключове слово може бути
корисним у загальносистемних файлах ).
AddKeysToAgent
Визначає, чи слід автоматично додавати ключі до запущеного ssh-agent(1). Якщо для цього
параметра встановлено значення 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
Визначає максимальну кількість символів крапки, які буде використано у назві вузла, перш ніж
переведення у канонічну форму буде вимкнено. Типовим значенням є 1, тобто можна використовувати
лише одну крапку (приклад: назва_вузла.піддомен).
CanonicalizePermittedCNAMEs
Вказує правила для визначення того, чи слід вказувати після CNAME назви вузлів у канонічній
формі. Правила складаються з одного або декількох аргументів
список_доменів_джерела:список_доменів_призначення, де сипсок_доменів_джерела є списком взірців
доменів, після яких може бути вказано CNAME у канонічній формі, а список_доменів_призначення є
списком взірців доменів, до яких можливе визначення.
Наприклад, "*.a.example.com:*.b.example.com,*.c.example.com" дозволить встановлення для назв
вузлів, які відповідають взірцю "*.a.example.com", переведення у канонічну форму до назв у
доменах "*.b.example.com" або "*.c.example.com".
Використання одинарного аргументу "none" призведе до того, що CNAME не розглядатимуться при
приведенні до канонічної форми. Це типова поведінка.
CASignatureAlgorithms
Вказує, який алгоритм можна використовувати для підписування сертифікатів службами сертифікації
(CA). Типові значення:
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
Вказує, що усі переспрямування локальних, віддалених та динамічних портів, вказані у файлах
налаштувань або рядку команди, слід вилучити. Цей параметр, в основному, призначено для
використання з командного рядка ssh(1) для вилучення переспрямувань портів, які встановлено у
файлах налаштувань, і автоматично встановлюється scp(1) і sftp(1). Аргументом має бути yes або
no (типове значення).
Compression
Визначає, чи слід використовувати стиснення. Аргументом має бути yes або no (типовий варіант).
ConnectionAttempts
Вказує кількість спробу (по одній за секунду), які слід виконувати до завершення роботи.
Аргументом має бути ціле число. Може бути корисно у скриптах, якщо станеться якась помилка.
Типовим є значення 1.
ConnectTimeout
Встановлює час очікування (у секундах), який буде використано при встановленні з'єднання із
сервером SSH, замість використання типового часу очікування TCP системи. Цей час очікування буде
застосовано і для встановлення з'єднання і для виконання початкового узгодження з'єднання SSH і
обміну ключами.
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
Вказує, що порт TCP на локальній машині буде переспрямовано захищеним каналом, а протокол
програми буде потім використано для визначення, з чим слід встановлювати з'єднання з віддаленої
машини.
Аргументом має бути [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
Визначає, чи має ssh(1) розривати з'єднання, якщо програмі не вдасться налаштувати усі запитані
динамічні, тунельовані, локальні та віддалені переспрямування портів (наприклад, якщо будь-якому
з кінців не вдасться зв'язатися і очікувати на дані на вказаному порту). Зауважте, що
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
Визначає, чи буде автоматично переспрямовано захищеним каналом з'єднання X11 і встановлено
DISPLAY. Аргументом має бути yes або no (типовий варіант).
Слід бути обережним із вмиканням переспрямовування X11. Користувачі з можливістю обходу дозволу
файлів на віддаленому вузлі (для бази даних уповноважень користувача X11) зможуть доступитися до
локального дисплея X11 через переспрямоване з'єднання. Зловмисник зможе виконувати дії, наприклад
стеження за натиснутими клавішами, якщо також увімкнено параметр ForwardX11Trusted.
ForwardX11Timeout
Встановити час очікування для недовірених переспрямувань X11 використовуючи формат, описаний в
розділі “TIME FORMATS” в sshd_config(5). з'єднання X11, отримані ssh(1) після цього часу будуть
відхилені. Встановлення ForwardX11Timeout в нуль вимкне обмеження часу очікування і дозволить
переспрямування X11 на весь час з'єднання. Типовим є вимкнути недовірені переспрямування X11
після 20 хвилин.
ForwardX11Trusted
Якщо для цього параметра встановлено значення yes, (специфічне для Debian типове значення),
віддалені клієнти X11 матимуть повний доступ до початкового дисплея X11.
Якщо параметр встановлено в no (типове значення в основній гілці розробки) віддалені X11 клієнти
будуть розглядатися, як недовірені, і їм буде заборонено викрадення або фальсифікацію даних, що
належать клієнтам X11. Більше того, жетон xauth(1), використаний для сеансу буде мати строк дії
20 хвилин. Віддаленим клієнтам буде відмовлено в доступі після цього часу.
Щодо повного опису обмежень, які буде накладено на недовірені клієнти, див. специфікацію
розширення SECURITY X11.
GatewayPorts
Вказує чи віддаленим машинам дозволено приєднуватися до локальних переспрямованих портів. Типово,
ssh(1) прив'язує переспрямування локальних портів до пристрою зворотного зв'язку (loopback). Це
не дозволяє іншим віддаленим машинам приєднуватися до переспрямованих портів. GatewayPorts можна
використовувати, щоб ssh прив'язував переспрямування локальних портів до шаблонної адреси, таким
чином, дозволяючи віддаленим портам приєднуватися до переспрямованих портів. Аргументом має бути
yes або no (типове значення).
GlobalKnownHostsFile
Вказує один або декілька відокремлених пробілами записів файлів для бази даних загальних ключів
машин. Типовим є /etc/ssh/ssh_known_hosts, /etc/ssh/ssh_known_hosts2.
GSSAPIAuthentication
Визначає, чи дозволено розпізнавання користувачів на основі GSSAPI. Типовим значенням є no (ні).
GSSAPIClientIdentity
Якщо встановлено, задає профіль клієнта GSSAPI, який має використовувати ssh при встановленні
з'єднання із сервером. Типове значення не встановлено, що означає, що буде використано типовий
профіль.
GSSAPIDelegateCredentials
Переспрямувати (делегувати) реєстраційні дані на сервер. Типовим значенням є no (ні).
GSSAPIKeyExchange
Визначає, чи може бути використано обмін ключами на основі GSSAPI. При використанні обміну ключів
GSSAPI на сервері не обов'язково має бути ключ вузла. Типовим є значення “no”.
GSSAPIRenewalForcesRekey
Якщо встановлено значення “yes”, оновлення реєстраційних даних GSSAPI клієнта призведе до
примусового повторного обміну ключам у з'єднанні ssh. Якщо сервер виявиться сумісним із цією
можливістю, оновлені реєстраційні дані буде делеговано сеансу на сервері.
Буде виконано перевірки з метою забезпечення передавання реєстраційних даних лише при
відповідності нових реєстраційних даних старим на вихідному клієнті і наявності старого набору у
кеші сервера-отримувача.
Типовим значенням є “no” (ні).
Щоб це спрацювало, на сервері має бути увімкнено, а також використано клієнтом,
GSSAPIKeyExchange.
GSSAPIServerIdentity
Якщо встановлено, задає профіль сервера GSSAPI, на який має очікувати ssh при встановленні
з'єднання із сервером. Типове значення не встановлено, що означає, що очікуваний профіль сервера
GSSAPI буде визначено із назви вузла сервера.
GSSAPITrustDns
Встановіть значення “yes”, щоб позначити, що DNS є надійним для безпечного перетворення назви
вузла, з яким встановлюється з'єднання, у канонічну форму. Якщо значенням є “no”, назву вузла,
яку введено у командному рядку, буде передано без змін бібліотеці GSSAPI. Типовим значенням є
“no”.
GSSAPIKexAlgorithms
Список алгоритмів обміну ключами, які пропонуються для обміну ключами GSSAPI. Можливі значення:
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
Вказує, що ssh(1) має хешувати назви та адреси машин, коли додаємо їх в ~/.ssh/known_hosts. Ці
хешовані назви можна використовувати звичайним чином в ssh(1) та sshd(8), але вони візуально не
розкривають інформацію ідентифікації, якщо розкрито вміст файлу. Типовим є 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
Визначає, чи слід намагатися скористатися розпізнаванням на основі rhosts із розпізнаванням на
основі відкритого ключа. Аргументом має бути 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
Визначає альтернативу, яку має бути використано замість справжньої назви вузла при пошуку або
збереженні ключа вузла до файлів бази даних ключів вузла і перевірці сертифікатів вузла. Цей
параметр корисний для тунелювання з'єднань SSH та користування декількома запущеними серверами на
одному вузлі.
Hostname
Визначає справжню назву вузла для входу. Можна скористатися для визначення псевдонімів або
скорочень для вузлів. В аргументах Hostname можна використовувати жетони, які описано у розділі
“ЖЕТОНИ”. Також можна використовувати числові IP-адреси (у рядку команди і у специфікаціях
Hostname). Типовою є назва, яку задано у рядку команди.
IdentitiesOnly
Визначає, що ssh(1) має використовувати лише налаштований профіль розпізнавання і файли
сертифікатів (або типові файли, або файли, які явним чином налаштовано у файлах або передано у
рядку команди ssh(1)), навіть якщо у ssh-agent(1), PKCS11Provider або SecurityKeyProvider
передбачено більше профілів. Аргументом до цього ключового слова має бути yes або no (типове
значення). Цей параметр призначено для випадків, коли ssh-agent пропонує багато різних профілів.
IdentityAgent
Вказує сокет Unix-domain, який використовують для обміну даними з агентом розпізнавання.
Цей параметр перевизначає змінну середовища SSH_AUTH_SOCK. Ним можна скористатися для вибору
певного агента. Встановлення назви сокета none вимикає використання агента розпізнавання. Якщо
вказано рядок "SSH_AUTH_SOCK" розташування сокета буде прочитано зі змінної середовища
SSH_AUTH_SOCK. В інших випадках, якщо вказана значення починається з символу ‘$’, його буде
оброблено як змінну середовища, яка містить розташування сокета.
У аргументах IdentityAgent можна використовувати символ тильди для позначення домашнього каталогу
користувача, жетони, які описано у розділі “ЖЕТОНИ” та змінні середовища, як їх описано у розділі
“ЗМІННІ СЕРЕДОВИЩА”.
IdentityFile
Визначає файл, з якого буде прочитано профіль розпізнавання користувача у форматі DSA, ECDSA,
збереженого засобом розпізнавання ECDSA, Ed25519, збереженого засобом розпізнавання Ed25519 або
RSA. Ви також можете вказати файл відкритого ключа, щоб використати відповідний закритий ключ,
який завантажено до ssh-agent(1), якщо файл закритого ключа недоступний локально. Типовими
файлами є ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519,
~/.ssh/id_ed25519_sk і ~/.ssh/id_dsa. Крім того, усі профілі, які представлено агентом
розпізнавання, буде використано для розпізнавання, якщо не встановлено IdentitiesOnly. Якщо не
було явним чином не встановлено сертифікати за допомогою CertificateFile, ssh(1) спробує
завантажити дані сертифіката з файла із назвою, яку буде утворено дописуванням -cert.pub до шляху
до вказаного IdentityFile.
У аргументах IdentityFile можна використовувати синтаксичні конструкції із тильдою для визначення
домашнього каталогу користувача або жетони, які описано у розділі “ЖЕТОНИ”.
У файлах налаштувань можна вказувати декілька файлів профілів; програма послідовно спробує
скористатися усіма профілями послідовно. Якщо буде використано декілька інструкцій IdentityFile,
профілі буде додано до списку профілів, які пробуватиме програма (ця поведінка відрізняється від
поведінки інших інструкцій налаштовування).
IdentityFile можна використовувати у поєднанні із IdentitiesOnly для вибору, які профілі в агенті
буде запропоновано під час розпізнавання. IdentityFile може бути також використано у поєднанні
із CertificateFile з метою надання будь-якого сертифіката, який також потрібен для розпізнавання
за допомогою профілю.
IgnoreUnknown
Визначає список взірців невідомих параметрів, які має бути проігноровано, якщо їх буде виявлено
при обробці налаштувань. Цим можна скористатися для придушення повідомлень про помилки, якщо у
використано параметри, які не розпізнає ssh(1). Рекомендуємо розташовувати IgnoreUnknown на
початку файла налаштувань, оскільки його не буде застосовано до невідомих параметрів, які
трапляться у файлі перед ним.
Include
Включити вказані файли налаштувань. Можна вказати декілька шляхів, а кожен зі шляхів може містити
шаблони glob(7) і, для налаштувань користувача, оболонкоподібні посилання ‘~’ на домашній каталог
користувача. Шаблони буде розгорнуто і оброблено у лексичному порядку. Файли без абсолютних
шляхів мають бути у ~/.ssh, якщо їх включено у файлі налаштувань користувача, або у /etc/ssh,
якщо їх включено із загальносистемного файла налаштувань. Інструкцією Include можна скористатися
у блоках Match і Host для виконання умовного включення.
IPQoS Визначає тип служби IPv4 або клас DSCP для з'єднань. Прийнятними значеннями є 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
Визначає список способів, якими слід користуватися у інтерактивному розпізнаванні за допомогою
клавіатури. Якщо вказано декілька способів, їхні записи слід відокремлювати комами. Типовим є
використання наданого сервером списку. Список способів залежить від можливостей сервера. Для
сервера OpenSSH це може бути нуль або більше записів bsdauth та pam.
KexAlgorithms
Визначає доступні алгоритми KEX (Key Exchange або обміну ключами). Якщо вказано декілька
алгоритмів, їхні записи слід відокремлювати комами. Якщо вказаний список починається з символу
‘+’, вказані алгоритми буде дописано до типового набору, а не використано замість нього. Якщо
вказаний список починатиметься з символу ‘-’, алгоритми (разом із тими, які відповідають вказаним
шаблонам) буде вилучено з типового набору, а не використано замість нього. Якщо вказаний список
починатиметься з символу ‘^’, алгоритми буде дописано на початку типового набору. Типовим
значенням цього параметра є таке:
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
Визначає те, що порт TCP на локальній машині має бути переспрямовано захищеним каналом до
вказаного вузла і порту з віддаленої машини. Перший аргумент визначає засіб очікування на дані,
тим може бути [адреса_прив'язки:]порт або шлях до сокета домену UNIX. Другим аргументом є
призначення. Його можна записати у форматі вузол:порт_вузла або як шлях до сокета домену UNIX,
якщо на віддаленому вузлі передбачено підтримку відповідних сокетів.
Адреси IPv6 може бути вказано за допомогою взяття адрес у квадратні дужки. Можна вказати декілька
переспрямувань, а додаткові переспрямування можна вказати у рядку команди. Переспрямування на
привілейовані порти може вказувати лише суперкористувач. Типово, локальний порт буде прив'язано
відповідно до параметра GatewayPorts. Втім, можна скористатися явним bind_address для
прив'язування з'єднання до вказаної адреси. Аргумент bind_address localhost вказує на те, що порт
очікування даних буде пов'язано лише із локальним використанням, а порожня адреса або ‘*’ вказує
на те, що порт має бути доступним з усіх інтерфейсів. У шляхах до сокета домену UNIX можна
використовувати жетони, які описано у розділі “ЖЕТОНИ” і змінні середовища, які описано у розділі
“ЗМІННІ СЕРЕДОВИЩА”.
LogLevel
Задає рівень докладності, який буде використано при журналюванні повідомлень від ssh(1). Можливі
значення: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 і DEBUG3. Типовим значенням є
INFO. DEBUG і DEBUG1 є еквівалентними. DEBUG2 і DEBUG3 задають вищі рівні докладності виведених
даних.
LogVerbose
Визначити один або декілька перевизначень LogLevel. Перевизначення складається зі списків взірців
для файла-джерела, функції та номера рядка, якими слід обмежити ведення докладного журналу.
Приклад взірці перевизначення:
kex.c:*:1000,*:kex_exchange_identification():*,packet.c:*
вмикає ведення докладного журналу для рядка 1000 файла kex.c, усього у функції
kex_exchange_identification() і усього коду у файлі packet.c. Цей параметр призначено для
діагностики. Типово, не увімкнено жодних перевизначень.
MACs Визначає алгоритми MAC (message authentication code або коду розпізнавання повідомлень) за
порядком пріоритетності. Алгоритм MAC буде використано для захисту цілісності даних. Алгоритми у
списку слід відокремлювати комами. Якщо список починається з символу ‘+’, вказані алгоритми буде
дописано до типового набору, а не використано замість нього. Якщо вказаний список починатиметься
з символу ‘-’, алгоритми (разом із тими, які відповідають вказаним шаблонам) буде вилучено з
типового набору, а не використано замість нього. Якщо вказаний список починатиметься з символу
‘^’, алгоритми буде дописано на початку типового набору.
Записи алгоритмів, які містять "-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
Вимкнути розпізнавання вузла для локального вузла (адрес петльового інтерфейсу (loopback)).
Аргументом до цього ключового слова має бути yes або no (типовий варіант).
NumberOfPasswordPrompts
Визначає кількість спроб введення пароля, перш ніж система припинить спроби. Аргументом цього
ключового слова має бути ціле число. Типовим значенням є 3.
ObscureKeystrokeTiming
Визначає, чи має ssh(1) намагатися приховати часові параметри інтервалів між натисканнями клавіш
від пасивних спостерігачів обміну даними мережею. Якщо увімкнено, для інтерактивних сеансів
ssh(1) надсилатиме дані натискання клавіш з фіксованими інтервалами у декілька десятих
мілісекунди і надсилатиме фіктивні пакети даних натискання клавіш протягом певного часу після
припинення введення. Аргументом цього ключового слова має бути yes, no або специфікатор інтервалу
у формі interval:мілісекунди (наприклад interval:80 для 80 мілісекунд). Типовою є поведінка з
приховуванням натискання клавіш з використанням інтервалу у 20 мс між пакетами. Зауважте, що
зменшення інтервалу приходить до вищої частоти фіктивних пакетів даних натискання клавіш.
PasswordAuthentication
Визначає, чи слід використовувати розпізнавання за паролем. Аргументом цього ключового слова має
бути yes (типовий варіант) або no.
PermitLocalCommand
Дозволити виконання локальних команд за допомогою параметра LocalCommand або керівної
послідовності !command в ssh(1). Аргументом має бути yes або no (типовий варіант).
PermitRemoteOpen
Визначає призначення, до яких дозволено переспрямування віддалених портів TCP, якщо як
проксі-сервер SOCKS використано RemoteForward. Специфікацію переспрямування має бути записано у
одній з таких форм:
PermitRemoteOpen вузол:порт
PermitRemoteOpen адреса_IPv4:порт
PermitRemoteOpen [адреса_IPv6]:порт
Переспрямування у списку слід відокремлювати пробілами. Можна скористатися аргументом any для
вилучення усіх обмежень і встановлення дозволу на будь-які запити щодо переспрямовування. Можна
скористатися аргументом none для заборони усіх запитів щодо переспрямовування. Для встановлення
дозволу для усіх вузлів або портів, відповідно, можна скористатися шаблоном заміни ‘*’. В усіх
інших випадках для наданих назв не буде виконано ніякого встановлення відповідності за взірцем та
ніяких пошуків адреси.
PKCS11Provider
Вказує, яким надавачем PKCS#11 слід скористатися або, якщо вказано none, визначає, що не слід
користуватися жодним (типова поведінка). Аргументом до цього ключового слова є шлях до бібліотеки
спільного користування PKCS#11, якою має користуватися ssh(1) для обміну даними з жетоном
PKCS#11, який надає ключі для розпізнавання користувачів.
Port Визначає номер порту, на якому слід встановити з'єднання із віддаленим вузлом. Типовим значенням
є 22.
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
Визначає один або декілька проміжних проксі-серверів у форматі або [користувач@]вузол[:порт] ,
або у форматі адреси ssh. Можна вказати список із відокремлених комами записів проксі-серверів.
Відвідування записів списку відбуватиметься послідовно. Встановлення цього параметра призведе до
того, що ssh(1) встановлюватиме з'єднання із вузлом призначення, спершу встановивши з'єднання
ssh(1) із вказаним вузлом 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
Визначає максимальний об'єм даних, які може бути передано або отримано до повторного узгодження
ключа сеансу, також можна вказати максимальний час, який може минути до моменту потреби у
повторному узгодженні ключа сеансу. Перший аргумент слід вказувати у байтах із можливим
використанням суфіксів ‘K’, ‘M’ та ‘G’ для кілобайтів, мегабайтів та гігабайтів, відповідно.
Типовими значеннями є ‘1G’ та ‘4G’, залежно від способу шифрування. Необов'язкове друге значення
слід вказувати у секундах. Можна використовувати будь-які одиниці, які документовано у розділі
«ФОРМАТИ ЧАСУ» сторінки підручника з sshd_config(5). Типовим значенням RekeyLimit є default none
(немає), що означає, що повторне узгодження ключа відбуватиметься після надсилання або отримання
типового для шифрування об'єму даних, а обмеження за часом для повторного обміну ключами
накладено не буде.
RemoteCommand
Визначає команду, яку слід виконати на віддаленій машині після успішного з'єднання з сервером.
Рядок команди поширюється до кінця рядка. Його буде виконано за допомогою командної оболонки
користувача. В аргументах RemoteCommand можна використовувати жетони, які описано у розділі
“ЖЕТОНИ”.
RemoteForward
Визначає, що порт TCP на віддаленій машині буде переспрямовано захищеним каналом. Віддалений порт
може бути або переспрямовано на вказаний вузол і порт з локальної машини, або він може працювати
як проксі-сервер SOCKS 4/5, який уможливлює для віддаленого клієнта з'єднання із довільними
призначеннями з локальної машини. Першим аргументом є специфікація очікування на дані. Можливі
значення — [адреса_прив'язки:]порт або, якщо на віддаленому вузлі передбачено підтримку
відповідної можливості, шлях до сокета домену UNIX. Якщо відбувається переспрямування до певного
призначення, другим аргументом має бути вузол:порт_вузла або шлях до сокета домену UNIX. В усіх
інших випадках, якщо не вказано аргументи призначення, віддалене переспрямування буде встановлено
як проксі-сервер SOCKS. При роботі у режимі проксі-сервера SOCKS призначення з'єднання можна
обмежити за допомогою PermitRemoteOpen.
Адреси IPv6 може бути вказано за допомогою взяття адрес у квадратні дужки. Можна вказати декілька
переспрямувань, а додаткові переспрямування можна вказати у рядку команди. Переспрямування на
привілейовані порти може вказувати лише користувач root на віддаленій машині. У шляхах до сокета
домену UNIX можна використовувати жетони, які описано у розділі “ЖЕТОНИ” і змінні середовища, які
описано у розділі “ЗМІННІ СЕРЕДОВИЩА”.
Якщо аргументом порт є 0, порт очікування даних буде виділено на сервері динамічним чином, а
клієнта буде повідомлено про нього вже під час роботи з'єднання.
Якщо адресу_прив'язки не вказано, типовою поведінкою буде прив'язування лише до адрес петльового
(loopback) інтерфейсу. Якщо значенням адреси_прив'язки є ‘*’ або порожній рядок, переспрямування
очікуватиме на дані на усіх інтерфейсах. Визначення віддаленої адреси_прив'язки буде успішним
лише тоді, коли увімкнено параметр GatewayPorts сервера (див. sshd_config(5)).
RequestTTY
Визначає, чи слід надсилати запит щодо псевдо-tty для сеансу. Аргументом може бути одне з таких
значень: no (ніколи не надсилати запит щодо TTY), yes (завжди надсилати запит щодо TTY, якщо
стандартним джерелом вхідних даних є TTY), force (завжди надсилати запит щодо TTY) або auto
(завжди надсилати запит щодо TTY при відкритті сеансу входу до системи). Цей параметр
віддзеркалює прапорці -t і -T для ssh(1).
RequiredRSASize
Визначає мінімальний розмір ключа RSA (у бітах), який прийматиме ssh(1). Ключі розпізнавання
користувачів, які є меншими за це обмеження, буде проігноровано. З'єднання із серверами, які
надаватимуть ключі вузлів, які є меншими за це обмеження, має бути розірвано. Типовим є значення
у 1024 бітів. Зауважте, що це обмеження може бути лише збільшено відносно типового значення.
RevokedHostKeys
Визначає відкликані відкриті ключів вузла. У використанні ключів зі списку у цьому файлі для
розпізнавання за вузлом буде відмовлено. Зауважте, що якщо цього файла не існує або його вміст
непридатний до читання, у розпізнаванні за вузлом буде відмовлено для усіх вузлів. Ключі можна
вказати у форматі текстового файла, по одному ключу на рядок, або у форматі списку відкликання
ключів OpenSSH (KRL), який створено ssh-keygen(1). Щоб дізнатися більше про KRL, ознайомтеся із
розділом «СПИСКИ ВІДКЛИКАННЯ КЛЮЧІВ» на сторінці підручника ssh-keygen(1). В аргументах
RevokedHostKeys можна використовувати синтаксичні конструкції із тильдою, яка позначає домашній
каталог користувача, жетони описано у розділі “ЖЕТОНИ”, а змінні середовища описано у розділі
“ЗМІННІ СЕРЕДОВИЩА”.
SecurityKeyProvider
Задає шлях до бібліотеки, яку буде використано при завантаженні будь-яких ключів FIDO на боці
засобу розпізнавання. Перевизначає типове використання вбудованої підтримки HID USB.
Якщо вказане значення починається із символу ‘$’, його буде оброблено як змінну середовища, що
містить шлях до бібліотеки.
SendEnv
Визначає, які змінні з локального environ(7), має бути надіслано на сервер. На сервері має бути
реалізовано підтримку цього, а сервер має бути налаштовано на прийняття цих змінних середовища.
Зауважте, що змінну середовища TERM буде надіслано завжди, коли буде надіслано запит щодо
псевдотермінала, оскільки він потрібен за протоколом. Зверніться до розділу щодо AcceptEnv на
сторінці підручника sshd_config(5), щоб дізнатися про те, як налаштувати сервер. Змінні слід
вказувати за назвою, яка може містити символи-замінники. Змінні середовища слід відокремлювати
пробілами або ділити між декількома інструкціями SendEnv.
Див. “PATTERNS” щодо докладнішої інформації про шаблони.
Можна вилучити раніше встановлені назви змінних SendEnv додаванням до взірців префікса -.
Типовою поведінкою є відмова у надсиланні будь-яких змінних середовища.
ServerAliveCountMax
Встановлює кількість повідомлень підтримання зв'язку (див. нижче), які може бути надіслано
поспіль без отримання ssh(1) повідомлень-відповідей від сервера. Якщо буде досягнуто порогового
значення під час надсилання повідомлень підтримання зв'язку на сервер, ssh розірве з'єднання із
сервером, перервавши сеанс зв'язку. Важливо зауважити, що використання повідомлень підтримання
зв'язку із сервером значно відрізняється від TCPKeepAlive (нижче). Повідомлення підтримання
зв'язку буде надіслано шифрованим каналом, а отже, їх не можна буде підробити. Повідомлення
підтримання зв'язку TCP, які вмикає TCPKeepAlive, можна підробити. Механізм підтримання зв'язку
із сервером є важливим, якщо робота клієнта або сервера залежить від інформації щодо того, чи є
з'єднання працездатним.
Типовим значенням є 3. Якщо, наприклад, для ServerAliveInterval (див. нижче) встановлено значення
15, а для ServerAliveCountMax залишено типове значення, якщо сервер перестає відповідати, ssh
розірве з'єднання за приблизно 45 секунд.
ServerAliveInterval
Встановлює час очікування у секундах, після якого, якщо не було отримано дані з сервера, ssh(1)
надсилатиме повідомлення шифрованим каналом із запитом щодо відповіді від сервера. Типове
значення 0 вказує на те, що ці повідомлення не буде надіслано на сервер. Іншим варіантом типового
значення є 300, якщо встановлено значення параметра BatchMode (специфічно для Debian).
Альтернативами для сумісності у Debian для цього параметра є ProtocolKeepAlives та SetupTimeOut.
SessionType
Можна скористатися або для надсилання запитів щодо виклику підсистеми на віддаленій системі, або
для запобігання виконанню віддаленої команди взагалі. Другий випадок використання є корисним,
якщо потрібно лише переспрямувати порти. Аргументом цього ключового слова має бути none (те саме,
що і параметр -N), subsystem (те саме, що і параметр -s) або default (виконання оболонки або
команди).
SetEnv Безпосередньо визначити одну або декілька змінних середовища та їхній вміст, який буде надіслано
на сервер. Подібно до SendEnv, за винятком змінної TERM, сервер має бути приготовано для
прийняття змінної середовища.
StdinNull
Переспрямовує стандартне джерело вхідних даних з /dev/null (насправді, запобігає читанню зі
стандартного джерела вхідних даних). Якщо ssh запущено у фоновому режимі, має бути використано
або цей параметр, або еквівалентний параметр -n. Аргументом до цього ключового слова має бути
yes (те саме, що і параметр -n) або no (типове значення).
StreamLocalBindMask
Встановлює вісімкову маску режиму створення файла (umask), яку буде використано при створенні
файла сокета домену UNIX для переспрямовування локальних або віддалених портів. Цей параметр
використовується лише для переспрямовування портів до файла сокета домену UNIX.
Типовим значенням є 0177. Його використання призводить до створення файла сокета домену UNIX,
який є придатним до читання і запису лише від імені власника. Зауважте, що підтримку режиму
доступу до файлів сокетів домену UNIX передбачено не в усіх операційних системах.
StreamLocalBindUnlink
Визначає, чи слід вилучати наявний файл сокета домену UNIX для переспрямування локального або
віддаленого порту перед створенням нового. Якщо файл сокета вже існує, і 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
Надає допоміжний код, який буде використано при записуванні повідомлень від ssh(1) до журналу.
Можливі значення: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6,
LOCAL7. Типовим є значення USER.
TCPKeepAlive
Визначає, чи має система надсилати повідомлення підтримання зв'язку TCP на інший бік з'єднання.
Якщо їх буде надіслано, про розірвання з'єднання або аварійне завершення роботи однієї з машин
буде повідомлено належним чином. Використання цього параметра призводитиме лише до використання
повідомлень підтримання зв'язку TCP (а не до використання підтримання зв'язку на рівні ssh), тому
повідомлення про непрацездатність з'єднання надходитиме дуже довго. Через це, варто також
скористатися параметром ServerAliveInterval. Втім, це означає, що з'єднання буде розірвано при
тимчасовій непрацездатності маршруту, і для декого це може бути неприйнятним.
Типовим значенням є yes (для надсилання повідомлень підтримання зв'язку TCP), а клієнт
отримуватиме повідомлення, якщо мережа або віддалений вузол стануть непрацездатними. Це важливо у
скриптах, а також корисно для багатьох користувачів.
Щоб вимкнути повідомлення підтримання зв'язку TCP, слід встановити значення no. Див. також
ServerAliveInterval, щоб дізнатися більше про повідомлення підтримання зв'язку на рівні
протоколів.
Tag Вказати назву теґу налаштувань, який може бути пізніше використано в інструкції Match для вибору
блоку налаштувань.
Tunnel Надіслати запит щодо переспрямування пристроїв tun(4) між клієнтом і сервером. Аргументом має
бути yes, point-to-point (шар 3), ethernet (шар 2) або no (типовий варіант). Якщо вказати yes,
буде надіслано запит щодо типового режиму тунелювання, яким є point-to-point.
TunnelDevice
Визначає пристрої tun(4), які слід відкрити на (local_tun) клієнта і (remote_tun) сервера.
Аргументом має бути локальний_тунель[:віддалений_тунель] . Пристрої слід вказувати у форматі
числових ідентифікаторів або ключового слова any, яке вказує на те, що слід використовувати
наступний доступний пристрій тунелювання. Якщо віддалений_тунель не вказано, типовим значенням
буде any. Типовим значенням є any:any.
UpdateHostKeys
Визначає, чи має ssh(1) приймати сповіщення щодо додаткових ключів вузла від сервера, які
надіслано після завершення розпізнавання, і додавати їх до 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
Визначає, чи слід перевіряти віддалений ключ за допомогою записів ресурсів DNS і SSHFP. Якщо для
цього параметра встановлено значення yes, клієнт неявним чином довірятиме ключам, які
відповідають захищеному відбитку від DNS. Незахищені відбитки буде оброблено так, наче для
параметра встановлено значення ask. Якщо для цього параметра встановлено значення ask, буде
показано дані щодо відповідності відбитка, але користувачеві доведеться підтверджувати нові ключі
вузлів відповідно до параметра StrictHostKeyChecking. Типовим значенням є no.
Див. також “ПЕРЕВІРКА КЛЮЧІВ ВУЗЛА” in ssh(1).
VisualHostKey
Якщо для цього прапорця встановлено значення yes, окрім рядка відбитка при вході і для невідомих
ключів вузла буде показано графічне представлення символами ASCII відбитка ключа віддаленого
вузла. Якщо для цього прапорця буде встановлено значення no (типовий варіант) при вході до
системи не буде виведено рядків відбитка, а для невідомих ключів вузлів буде виведено лише рядок
відбитка.
XAuthLocation
Задає повний шлях до програми xauth(1). Типовим значенням є /usr/bin/xauth.
ВЗІРЦІ
Взірець складається з нуля або більшої кількості символів, які не є пробілами, ‘*’ (символ, який є
замінником нуля або більшої кількості довільних символів) або ‘?’ (символу-замінника, який відповідає
одному довільному символу). Наприклад, щоб задати набір оголошень для будь-якого вузла у наборі доменів
".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,*"
ЖЕТОНИ
У аргументах до деяких ключових слів може бути використано жетони, які буде розгорнуто під час роботи
програм:
%% Буквально ‘%’.
%C Хеш-сума %l%h%p%r.
%d Домашній каталог локального користувача.
%f Відбиток ключа вузла сервера.
%H Назва і адреса вузла known_hosts, пошук якого відбувається.
%h Назва віддаленого вузла.
%I Рядок, який описує причину виконання KnownHostsCommand: або ADDRESS при пошуку вузла за
адресою (лише якщо увімкнено CheckHostIP), HOSTNAME при пошуку за назвою вузла, або ORDER при
приготуванні списку пріоритетності алгоритму ключів вузлів для використання для вузла
призначення.
%i Ідентифікатор локального користувача.
%K Ключ вузла у кодуванні base64.
%k Альтернатива ключа вузла, якщо вказано; в інших випадках, назва початкового віддаленого
вузла, як задано у рядку команди.
%L Назва локального вузла.
%l Назва локального вузла, включно із назвою домену.
%n Назва початкового віддаленого вузла, як задано у рядку команди.
%p Віддалений порт.
%r Ім'я віддаленого користувача.
%T Призначений локальний інтерфейс мережі tun(4) або tap(4), якщо було надіслано запит щодо
переспрямування тунелю, або "NONE" в інших випадках.
%t Тип ключа вузла сервера, наприклад, ssh-ed25519.
%u Ім'я локального користувача.
CertificateFile, ControlPath, IdentityAgent, IdentityFile, KnownHostsCommand, LocalForward, Match exec,
RemoteCommand, RemoteForward, RevokedHostKeys, і 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.
Зауважте, що деякі з цих інструкцій є командами збирання для виконання з командної оболонки. Оскільки
ssh(1) не виконує фільтрування або екранування символів, які мають особливе призначення в командній
оболонці (наприклад лапок), за те що аргументи, які передано ssh(1) не містять таких символів, а жетони
належним чином взято у лапки, відповідає користувач.
ЗМІННІ СЕРЕДОВИЩА
Аргументи до деяких ключових слів може бути розгорнуто під час виконання зі змінних середовища на боці
клієнта, взявши їх у ${}, наприклад, ${HOME}/.ssh вказуватиме на каталог .ssh у теці користувача. Якщо
вказаної змінної середовища не існує, буде повернуто повідомлення про помилку, а значення цього ключового
слова буде проігноровано.
У ключових словах CertificateFile, ControlPath, IdentityAgent, IdentityFile, KnownHostsCommand та
UserKnownHostsFile передбачено підтримку змінних середовища. У ключових словах LocalForward і
RemoteForward підтримку змінних середовища передбачено лише для шляхів до сокетів домену UNIX.
ФАЙЛИ
~/.ssh/config
Це користувацький файл конфігурації. Формат цього файла описано вище. Цей файл використовує
клієнт SSH. Оскільки потенційна зміна файла є небезпечною, файл слід захистити суворим обмеженням
прав доступу: читання/запис для користувача і заборона запису для інших. Можливий доступ до
запису для групи, але лише якщо у групі є лише один користувач.
/etc/ssh/ssh_config
Загальносистемний файл налаштувань. У цьому файлі записано типові значення для параметрів, які не
визначено у файлі налаштувань користувача, і для тих користувачів, у яких немає файлів
налаштувань. Цей файл має бути доступним на читання для усіх користувачів.
ДИВ. ТАКОЖ
ssh(1)
АВТОРИ
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: https://www.gnu.org/licenses/gpl-3.0.html. НЕ НАДАЄТЬСЯ ЖОДНИХ ГАРАНТІЙ.
Якщо ви знайшли помилки у перекладі цієї сторінки підручника, будь ласка, надішліть електронний лист до
списку листування перекладачів: trans-uk@lists.fedoraproject.org .
Debian 4 жовтня, 2023 SSH_CONFIG(5)