Scroll to navigation

SSH(1) General Commands Manual SSH(1)

НАЗВА

ssh — Клієнт віддаленого входу OpenSSH

КОРОТКИЙ ОПИС

ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B інтерфейс_прив'язки] [-b адреса_прив'язки] [-c специфікація_шифрування] [-D [адреса_прив'язки:]порт] [-E файл_журналу] [-e символ_керування] [-F файл_налаштувань] [-I pkcs11] [-i файл_профілю] [-J призначення] [-L адреса] [-l обліковий_запис] [-m специфікація_mac] [-O керівна_команда] [-o параметри] [-p порт] [-Q параметр_запиту] [-R адреса] [-S керівний_шлях] [-W вузол:порт] [-w локальний_тунель[:віддалений_тунель]] призначення [команда [аргумент ...]]

ОПИС

ssh (клієнт SSH) - це програма для входу до системи віддаленої машини для виконання на ній команд. Ця програма має на меті надати безпечний шифрований зв'язок між двома вузлами без довіри за допомогою захищеної мережі. Через цей безпечний канал також можна переправляти з'єднання X11, довільні порти TCP та сокети UNIX-domain.

ssh з'єднує з і входить у вказане destination, яке можна вказати або як [user@]hostname або як URI у формі ssh://[user@]hostname[:port]. Користувач має довести їх особу віддаленій машині за допомогою одного з методів (див. нижче).

Якщо вказано команду command, її буде виконано на віддаленій машині замість оболонки входу. Можна вказати повний рядок команди, як command, або вона може мати додаткові аргументи. Якщо вказано, аргументи буде додано в команду, розділеними пробілами, перед тим, як команду надішлють на сервер для виконання.

Параметри є такими:

Примусити ssh використовувати лише адреси IPv4.

Примусити ssh використовувати лише адреси IPv6.

Вмикає переспрямовування з'єднань від агента розпізнавання, зокрема ssh-agent(1). Це також можна вказати для кожного вузла окремо у файлі налаштувань.

Переспрямування агента треба вмикати обережно. Користувачі з можливістю обходу дозволів файлів на віддаленому вузла (для сокета агента UNIX-domain) можуть отримати доступ до локального агента через перенаправлене з'єднання. Зловмисник не може отримати матеріали ключів від агента, однак вони можуть виконати дії з ключами, що дозволить їм автентифікуватися, як особи, завантажені в агента. Безпечнішою альтернативою може бути використання перехідного (jump) вузла (див. -J).

Вимикає перенаправлення зʼєднання агента розпізнавання.

інтерфейс_прив'язки
Прив'язатися до адреси bind_interface перед спробою зв'язатися з вузлом призначення. Це є корисним лише на системах з більш ніж однією адресою.

адреса_прив'язки
Використовувати bind_address на локальній машині, як виходову адресу з'єднання. Є корисним лише на системах з більш ніж однією адресою.

Запитує стискання всіх даних (включаючи stdin, stdout, stderr та дані для перенаправленого X11, з'єднання TCP та UNIX-domain). Алгоритм компресії той самий, що використовує gzip(1). Стискання бажане на модемних лініях та інших повільних з'єднаннях, але лише призведе до сповільнення на швидких мережах. Типове значення можна встановити окремо для кожного вузла в файлах налаштувань; див. параметр Compression у ssh_config(5).

специфікація_шифрування
Вибирає специфікацію шифру для шифрування сеансу. cipher_spec є списком шифрів, розділених комою, в порядку пріоритету. Див. ключове слово Ciphers в ssh_config(5) щодо подробиць.

[адреса_прив'язки:]порт
Визначає локальне “динамічне” переспрямування портів на рівні програм. Це працює шляхом розміщення сокета для очікування на дані на порту на локальному боці, із необов'язковою прив'язкою до вказаної адреси_прив'язки. Якщо з'єднання буде встановлено на цьому порту, з'єднання буде переспрямовано захищеним каналом, а потім протокол програми буде використано для визначення того, куди слід з'єднуватися з віддаленої машини. У поточній версії передбачено підтримку протоколів SOCKS4 і SOCKS5, а ssh працюватиме як сервер SOCKS. Переспрямовувати на привілейовані порти може лише користувач root. Динамічне переспрямування портів також може бути вказано у файлі налаштувань.

Адреси IPv6 можна вказувати вкладаючи адресу в квадратові дужки. Лише суперкористувач може перенаправляти привілейовані порти. Типово локальний порт прив'язаний відповідно до параметра GatewayPorts. Однак, можна вжити явну bind_address, щоб прив'язати з'єднання до потрібної адреси. bind_address на “localhost” вказує, що порт слухання буде прив'язаний лише для локального використання, а порожня адреса або ‘*’ вказує, що порт буде доступний зі всіх інтерфейсів.

файл_журналу
Додавати журнали зневадження до log_file замість стандартного виводу.

керівний_символ
Встановлює керівний символ для сеансів із pty (типовим символом є ‘~’). Керівний символ буде розпізнано лише на початку рядка. Якщо після керівного символу вказано крапку (‘.’) розірве з'єднання; якщо після нього буде вказано ctrl-Z, з'єднання буде призупинено; а якщо за ним буде вказано ще один такий символ, на введення буде надіслано один керівний символ. Встановлення для керівного символу значення “none” вимикає усі керівні символи і робить сеанс повністю прозорим.

файл_налаштувань
Вказує альтернативний файл налаштувань для окремого користувача. Якщо файл налаштувань задано у командному рядку, загальносистемний файл налаштувань (/etc/ssh/ssh_config) буде проігноровано. Типовим файлом налаштувань окремого користувача є ~/.ssh/config. Якщо встановити значення “none”, програма не читатиме ніяких файлів налаштувань.

Надсилає запит до ssh щодо переходу у фоновий режим перед самим виконанням команди. Це корисно, якщо ssh має надіслати запит щодо паролів, але користувачеві потрібно, щоб це було зроблено у фоновому режимі. Неявним чином встановлює -n. Рекомендованим способом запуску програм X11 на віддаленому вузлі є щось подібне до ssh -f вузол xterm.

Якщо для параметра налаштувань ExitOnForwardFailure встановлено значення “yes”, клієнт, який запущено з -f, очікуватиме на успішне встановлення з'єднання на усіх переспрямуваннях віддалених портів до запуску себе у фоновому режимі. Щоб дізнатися більше, зверніться до опису ForkAfterAuthentication на сторінці підручника ssh_config(5).

Наказує ssh друкувати свою конфігурацію після обчислення блоків Host та Match і потім вийти.

Надає змогу віддаленим вузлам з'єднуватися з локальними перенаправленими портами. Якщо використано на мультиплексованому з'єднанні, цей параметр слід задавати на головному процесі.

pkcs11
Вказати спільну бібліотеку PKCS#11, яку має використовувати ssh для зв'язку з токеном PKCS#11, що надає ключі розпізнавання користувача.

файл_профілю
Вибирає файл, з якого буде прочитано профіль (закритий ключ) для розпізнавання за відкритим ключем. Ви також можете вказати файл відкритого ключа для використання відповідного закритого ключа, який завантажено до ssh-agent(1), якщо файла закритого ключа немає у локальному доступі. Типовими файлами є ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk і ~/.ssh/id_dsa. Також можна вказати файли профілю для окремих вузлів у файлі налаштувань. Можна вказати декілька параметрів -i (і декілька профілів у файлах налаштувань). Якщо не буде вказано сертифікати явним чином за допомогою інструкції CertificateFile, ssh також спробує завантажити дані сертифікатів з файла із назвою, яку можна отримати дописуванням -cert.pub до назв файлів профілів.

призначення
Встановити з'єднання із вузлом призначення шляхом початкового встановлення ssh з'єднання із перехідним вузлом, як це описано у розділі щодо призначення з наступним встановленням звідти переспрямування TCP до остаточного призначення. Можна встановити декілька переходів, відокремивши їхні записи комами. Це скорочена форма задання інструкції налаштовування ProxyJump. Зауважте, що інструкції налаштовування, вказані у рядку команди, загалом, буде застосовано до вузла призначення, а не до вказаних вузлів переходу. Скористайтеся ~/.ssh/config для задання налаштувань для вузлів переходу.

Вмикає розпізнавання на базі GSSAPI та перенаправлення (делегування) реєстраційних записів GSSAPI на сервер.

Вимикає переспрямовування (делегування) реєстраційних записів GSSAPI на сервер.

[адреса_прив'язки:]порт:вузол:порт_вузла
 
[адреса_прив'язки:]порт:віддалений_сокет
 
локальний_сокет:вузол:порт_вузла
 
локальний_сокет:віддалений_сокет
Вказує, що з'єднання із заданим портом TCP або сокетом Unix на локальному (клієнтському) вузлі слід переспрямовувати на заданий вузол і порт або сокет Unix на віддаленому боці з'єднання. Це працює шляхом розміщення сокета для очікування або на TCP- порту на локальному боці, можливо, пов'язаного із вказаною адресою_прив'язки, або на сокеті Unix. Кожного разу, коли встановлюватиметься з'єднання або на порту вузла порт_вузла, або на сокеті Unix віддалений сокет з віддаленої машини.

У файлі налаштувань можна також вказати переспрямування портів. Переспрямовувати привілейовані порти може лише суперкористувач. Адреси IPv6 слід вказувати, взявши запис адреси у квадратні дужки.

Типово, локальний порт прив'язаний відповідно до параметра GatewayPorts. Однак, можна вжити явну bind_address, щоб прив'язати з'єднання до потрібної адреси. bind_address на “localhost” вказує, що порт слухання буде прив'язаний лише для локального використання, а порожня адреса або ‘*’ вказує, що порт буде доступний зі всіх інтерфейсів.

обліковий_запис
Вказує користувача, від імені якого слід здійснити вхід на віддаленій машині. Також можна вказати для окремих вузлів у файлі налаштувань.

Переводить клієнт ssh в “основний” режим для спільного використання з'єднання. Якщо вказати декілька параметрів -M, ssh перейде до “основного” режиму, але і потребою у підтвердженні за допомогою ssh-askpass(1) до виконання будь-яких дій, які змінюють стан ущільнення (наприклад, відкриття нового сеансу). Зверніться до опису ControlMaster на сторінці підручника ssh_config(5), щоб дізнатися більше.

специфікація_mac
Список відокремлених комами алгоритмів MAC (message authentication code), вказаних у порядку пріоритетності. Щоб дізнатися більше, перегляньте документацію до ключового слова MACs у ssh_config(5).

Не виконувати віддаленої команди. Корисно, якщо треба лише переспрямувати порти. Докладніше про це в описі SessionType на сторінці підручника ssh_config(5).

Переспрямовує стандартне джерело вхідних даних (stdin) з /dev/null (тобто, фактично, забороняє читання зі stdin). Слід використовувати, якщо ssh запущено у фоновому режимі. Типовим застосуванням є запуск програм X11 на віддаленій машині. Наприклад, команда ssh -n shadows.cs.hut.fi emacs & запустить emacs на shadows.cs.hut.fi, а з'єднання із X11 буде автоматично переспрямовано на шифрований канал. Саму програму ssh буде переведено у фоновий режим. (Це не спрацює, якщо ssh потрібно надіслати запит щодо пароля; див. також параметр -f.) Зверніться до опису StdinNull на сторінці підручника ssh_config(5), щоб дізнатися більше.

керівна_команда
Керувати основним процесом ущільнення активного з'єднання. Якщо вказано параметр -O, аргумент керівна_команда буде оброблено і передано основному процесу. Коректними командами є такі: “check” (перевірити, чи запущено основний процес), “forward” (надіслати запит щодо переспрямовування без виконання команди), “cancel” (скасувати переспрямовування), “exit” (надіслати основному процесу запит щодо виходу) та “stop” (надіслати основному процесу запит щодо зупинення приймання подальших запитів щодо ущільнення).

параметр
Можна скористатися для отримання параметрів у форматі, який використовує файл налаштувань. Корисно для задання параметрів, для яких немає окремих прапорців командного рядка. Щоб дізнатися більше про параметри з наведеного нижче списку та їхні можливі значення, ознайомтеся зі сторінкою підручника ssh_config(5).

AddKeysToAgent
 
AddressFamily
 
BatchMode
 
BindAddress
 
CanonicalDomains
 
CanonicalizeFallbackLocal
 
CanonicalizeHostname
 
CanonicalizeMaxDots
 
CanonicalizePermittedCNAMEs
 
CASignatureAlgorithms
 
CertificateFile
 
CheckHostIP
 
Ciphers
 
ClearAllForwardings
 
Стискання
 
ConnectionAttempts
 
ConnectTimeout
 
ControlMaster
 
ControlPath
 
ControlPersist
 
DynamicForward
 
EnableEscapeCommandline
 
EscapeChar
 
ExitOnForwardFailure
 
FingerprintHash
 
ForkAfterAuthentication
 
ForwardAgent
 
ForwardX11
 
ForwardX11Timeout
 
ForwardX11Trusted
 
GatewayPorts
 
GlobalKnownHostsFile
 
GSSAPIAuthentication
 
GSSAPIKeyExchange
 
GSSAPIClientIdentity
 
GSSAPIDelegateCredentials
 
GSSAPIKexAlgorithms
 
GSSAPIRenewalForcesRekey
 
GSSAPIServerIdentity
 
GSSAPITrustDns
 
HashKnownHosts
 
Host
 
HostbasedAcceptedAlgorithms
 
HostbasedAuthentication
 
HostKeyAlgorithms
 
HostKeyAlias
 
Hostname
 
IdentitiesOnly
 
IdentityAgent
 
IdentityFile
 
IPQoS
 
KbdInteractiveAuthentication
 
KbdInteractiveDevices
 
KexAlgorithms
 
KnownHostsCommand
 
LocalCommand
 
LocalForward
 
LogLevel
 
MACs
 
Match
 
NoHostAuthenticationForLocalhost
 
NumberOfPasswordPrompts
 
PasswordAuthentication
 
PermitLocalCommand
 
PermitRemoteOpen
 
PKCS11Provider
 
Port
 
PreferredAuthentications
 
ProxyCommand
 
ProxyJump
 
ProxyUseFdpass
 
PubkeyAcceptedAlgorithms
 
PubkeyAuthentication
 
RekeyLimit
 
RemoteCommand
 
RemoteForward
 
RequestTTY
 
RequiredRSASize
 
SendEnv
 
ServerAliveInterval
 
ServerAliveCountMax
 
SessionType
 
SetEnv
 
StdinNull
 
StreamLocalBindMask
 
StreamLocalBindUnlink
 
StrictHostKeyChecking
 
TCPKeepAlive
 
Tunnel
 
TunnelDevice
 
UpdateHostKeys
 
User
 
UserKnownHostsFile
 
VerifyHostKeyDNS
 
VisualHostKey
 
XAuthLocation
 

порт
Порт, на якому слід встановити з'єднання на віддаленому вузлі. Значення для окремих вузлів можна встановити у файлі налаштувань.

параметр_запиту
Надсилає запит щодо підтримки у алгоритмах таких можливостей: cipher (передбачено підтримку симетричних шифрів), cipher-auth (передбачено підтримку симетричних шифрів, у яких передбачено підтримку шифрування із розпізнаванням), help (передбачено підтримку термінів запиту для використання з прапорцем -Q), mac (передбачено код перевірки цілісності повідомлень), kex (алгоритми обміну ключами), kex-gss (алгоритми GSSAPI із обміном ключами), key (типи ключів), key-cert (типи ключів із сертифікацією), key-plain (типи ключів без сертифікації), key-sig (усі типи ключів і алгоритми підписування), protocol-version (передбачено підтримку версій протоколу SSH) та sig (передбачено підтримку алгоритмів підписування). Крім того, можна скористатися як альтернативою відповідного параметра_запиту будь-яким ключовим словом з ssh_config(5) або sshd_config(5), яке приймає список алгоритмів.

Режим без повідомлень. Призводить до придушення більшості повідомлень із попередженнями та діагностичних повідомлень.

[адреса_прив'язки:]порт:вузол:порт_вузла
 
[адреса_прив'язки:]порт:локальний_сокет
 
віддалений_сокет:вузол:порт_вузла
 
віддалений_сокет:локальний_сокет
 
[адреса_прив'язки:]порт
Вказує, що з'єднання із заданим портом TCP або сокетом Unix на віддаленому (серверному) вузлі слід переспрямовувати на локальний бік.

Працює шляхом отримання сокета для очікування даних на порту TCP або на сокеті Unix на віддаленому боці. При встановленні з'єднання із цим портом або сокетом Unix з'єднання буде переспрямовано до захищеного каналу. З'єднання працюватиме з локальної машини або до явного призначення, вказаного за портом вузла порт_вузла, або до локального_сокета, або, якщо призначення не було вказано явним чином, ssh працюватиме як проксі-сервер SOCKS 4/5 і переспрямовуватиме з'єднання до призначень, запити щодо яких надаватиме клієнт віддалених з'єднань SOCKS.

У файлі налаштувань можна також вказати переспрямування портів. Привілейовані порти можна переспрямовувати, увійшовши до системи від імені користувача root на віддаленій машині. Адреси IPv6 слід вказувати, взявши запис адреси у квадратні дужки.

Типово, сокети очікування даних TCP на сервері буде пов'язано лише із петльовим інтерфейсом (loopback). Перевизначити таку поведінку можна заданням адреси_прив'язки. Порожня адреса_прив'язки або адреса ‘*’ вказує, що очікувати дані на віддаленому сокеті слід на усіх інтерфейсах. Визначення віддаленої адреси_прив'язки буде успішним, лише якщо увімкнено параметр сервера GatewayPorts (див. sshd_config(5)).

Якщо аргументом порт є ‘0’, порт очікування даних буде виділено на сервері динамічним чином, а клієнта буде повідомлено про нього вже під час роботи з'єднання. Якщо використано разом із -O forward виділений порт буде виведено до стандартного виведення системи.

керівний_шлях
Визначає розташування керівного сокета для спільного використання з'єднання або рядок “none”, щоб вимкнути спільне використання з'єднання. Зверніться до опису ControlPath і ControlMaster на сторінці підручника ssh_config(5), щоб дізнатися більше.

Може бути використано для надсилання запиту щодо виклику підсистеми у віддаленій операційній системі. Підсистеми спрощують користування SSH як захищеним каналом передавання даних для інших програм (зокрема sftp(1)). Підсистему задають як віддалену команду. Зверніться до опису SessionType на сторінці підручника ssh_config(5), щоб дізнатися більше.

Вимкнути розміщення псевдотермінала.

Примусово розмістити псевдотермінал. Цим можна скористатися для виконання довільних програм на основі screen на віддаленій машині, що може бути дуже корисним, наприклад, при реалізації служб меню. Додавання декількох параметрів -t призводить до примусового розміщення tty, навіть якщо у ssh немає локального tty.

Показати дані щодо версії і завершити роботу.

Режим докладних повідомлень. Наказує ssh виводити діагностичні повідомлення щодо поступу обробки завдань. Корисно для діагностики з'єднання і проблем із налаштуваннями. Додавання декількох параметрів -v підвищує докладність. Максимально докладним є режим із 3 параметрами.

вузол:порт
Надсилає запит щодо переспрямовування стандартного джерела вхідних даних і виведення на клієнті до вузла на порт захищеним каналом. Неявним чином встановлює -N, -T, ExitOnForwardFailure та ClearAllForwardings, хоча ці параметри можна перевизначити у файлі налаштувань або за допомогою параметрів командного рядка -o.

local_tun[:remote_tun]
вимагає перенаправлення через пристрій тунелювання зі вказаними пристроями tun(4) між клієнтом (local_tun) та сервером (remote_tun).

Пристрої треба вказувати через числові ІД або ключове слово “any”, що використає наступний доступний пристрій тунелювання. Якщо remote_tun не вказано, він приймає типове значення “any”. Див. також директиви Tunnel та TunnelDevice в ssh_config(5).

Якщо директиву Tunnel не встановлено, її буде встановлено в типовий режим тунелю, що є “point-to-point”. Якщо потрібен інший режим перенаправлення Tunnel, тоді його треба вказати перед -w.

Вмикає переспрямовування X11. Також можна вказати для окремих вузлів у файлі налаштувань.

Перенаправлення X11 треба вмикати обережно. Користувачі з можливістю обходу дозволу файлів на віддаленому хості (для бази даних авторизації користувача X) зможуть доступитися до локального дисплея X11 через перенаправлене з'єднання. Зловмисник зможе виконувати дії, наприклад стеження за набраними клавішами.

Через це перенаправлення X11 типово підлягає обмеженням розширення X11 SECURITY. Перегляньте параметр ssh -Y та директиву ForwardX11Trusted в ssh_config(5) щодо докладнішої інформації.

(Специфіка Debian: типово, переспрямовування X11 не підлягає обмеженням розширення SECURITY X11, оскільки використання цього режиму призводить до аварійного завершення роботи у багатьох програмах. Встановіть для параметра ForwardX11Trusted значення “no”, щоб відновити поведінку у типовій програмі. Поведінку програми у дистрибутиві може бути змінено у майбутньому, якщо ситуація на боці клієнта виправиться.)

Вимикає переспрямовування X11.

Дозволяє довірене перенаправлення X11. Довірене перенаправлення X11 не контролюється розширенням X11 SECURITY.

(Специфіка Debian: за типових налаштувань цей параметр є еквівалентом -X, оскільки типовим значенням ForwardX11Trusted є “yes”, як це описано вище. Встановіть для параметра ForwardX11Trusted значення “no”, щоб відновити поведінку типової програми. Поведінку програми у дистрибутиві може бути змінено у майбутньому, якщо ситуація на боці клієнта виправиться.)

Надіслати дані журналу за допомогою модуля системи syslog(3). Типово, ці дані буде надіслано до stderr.

ssh може додатково отримати дані налаштувань із файлів налаштувань для окремих користувачів та загальносистемного файла налаштувань. Формат файла і параметри налаштувань описано у ssh_config(5).

РОЗПІЗНАВАННЯ

Клієнт OpenSSH підтримує протокол SSH 2.

Доступні методи розпізнавання: розпізнавання на основі GSSAPI, розпізнавання на основі вузла, розпізнавання з відкритим ключем, інтерактивне розпізнавання за допомогою клавіатури та розпізнавання за допомогою пароля. Методи розпізнавання випробовуються в порядку, зазначеному вище, хоча для змінення типового порядку можна використати PreferredAuthentications.

Розпізнавання на основі вузла працює так: якщо машина, з якої намагається увійти користувач, є у списку /etc/hosts.equiv або /etc/ssh/shosts.equiv на віддаленій машині, користувач не є користувачем root, а назви облікових записів на обох боках з'єднання є однаковими, або якщо файл ~/.rhosts або ~/.shosts існує у домашньому каталозі користувача на віддаленій машині і містить рядок, що містить назву клієнтської машини і назву облікового запису користувача на цій машині, система розгляне запит користувача щодо входу до неї. Крім того, сервер повинетґн мати можливість перевірити ключ вузла клієнта (див. опис /etc/ssh/ssh_known_hosts і ~/.ssh/known_hosts нижче), щоб вхід до системи було дозволено. Цей спосіб розпізнавання закриває дірки у захисті через підміну IP, підміну DNS та підміну маршрутизації. [Зауваження для адміністраторів: /etc/hosts.equiv, ~/.rhosts та протокол rlogin/rsh загалом є спадково незахищеними — їх слід вимкнути, якщо бажаною є підвищена безпека.]

Розпізнавання за відкритим ключем працює так: схему засновано на криптографії з відкритим ключем, що використовує системи шифрування, де шифрування і розшифровування виконуються за допомогою окремих ключів, а визначення ключа розшифровування за ключем шифрування є надзвичайно складним. Ідея полягає у тому, що кожен із користувачів створює пару ключів відкритий-закритий з метою розпізнавання. Серверу відомий відкритий ключ, а закритий ключ є лише у користувача. У ssh реалізовано на автоматичному рівні протокол розпізнавання за відкритим ключем з використанням одного з таких алгоритмів: DSA, ECDSA, Ed25519 або RSA. У розділі ЖУРНАЛ сторінки підручника ssl(8) (у системах, відмінних від OpenBSD, див. http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8#HISTORY) містить коротке обговорення алгоритмів DSA і RSA.

У файлі ~/.ssh/authorized_keys зберігається список відкритих ключів, за допомогою яких можна входити до системи. Коли користувач входить до системи, програма ssh повідомляє серверу, яку пару ключів вона хоче використати для розпізнавання. Клієнт підтверджує, що він має доступ до закритого ключа, а сервер перевіряє те, чи відповідний відкритий ключ уповноважено для отримання доступу обліковим записом.

Сервер може повідомити клієнта про помилки, які перешкоджають успішному використанню відкритого ключа для розпізнавання після завершення спроби розпізнавання з використанням іншого способу. Ці повідомлення може бути переглянуто, якщо встановити для LogLevel значення DEBUG або вище (наприклад, за допомогою прапорця -v).

Користувач створює пару ключів запустивши ssh-keygen(1). Це зберігає закритий ключ в ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (authenticator-hosted ECDSA), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (authenticator-hosted Ed25519), or ~/.ssh/id_rsa (RSA) і зберігає відкритий ключ в ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (authenticator-hosted ECDSA), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (authenticator-hosted Ed25519), or ~/.ssh/id_rsa.pub (RSA) в домашньому каталозі користувача. Користувач має скопіювати ключ в ~/.ssh/authorized_keys в домашній каталог на віддаленій машині. Файл authorized_keys відповідає стандартному файлу ~/.rhosts, і має один ключ на рядок, однак рядки можуть бути дуже довгими. Після цього, користувач може заходити без пароля.

Варіант розпізнавання за відкритим ключем доступний у формі розпізнавання за сертифікатом: замість пари відкритого/закритого ключів, використовують підписані сертифікати. Перевага цього полягає утому, що можна використовувати єдину довірену службу сертифікації замість багатьох відкритих/закритих ключів. Дивіться розділ СЕРТИФІКАТИ у довідці ssh-keygen(1), щоб дізнатися більше.

Найзручнішим шляхом використання розпізнавання за відкритим ключем або сертифікатом може бути використання агента розпізнавання. Див. директиви ssh-agent(1) та (додатково) AddKeysToAgent на сторінці підручника ssh_config(5), щоб дізнатися більше.

Інтерактивне розпізнавання за допомогою клавіатури працює таким чином: сервер надсилає довільний текст "запит" і просить відповісти, можливо декілька разів. Прикладами інтерактивного розпізнавання за допомогою клавіатури є розпізнавання BSD (див. login.conf(5)) та PAM (деякі системи non-OpenBSD).

Нарешті, якщо інші методи розпізнавання зазнають невдачі, ssh питає пароль. Пароль надсилають на віддалену машину для перевірки; однак, оскільки весь зв'язок зашифровано, пароль неможливо побачити прослуховуючи мережу.

ssh автоматично супроводжує і перевіряє базу даних, що містить профілі для усіх вузлів, для яких було використано програму. Ключі вузлів зберігаються у файлі ~/.ssh/known_hosts домашнього каталогу користувача. Крім того, пошук відомих вузлів автоматично виконується у /etc/ssh/ssh_known_hosts. Записи усіх нових вузлів автоматично потрапляють у файл користувача. Якщо профіль вузла колись буде змінено, ssh попередить про це і вимкне розпізнавання за паролем, щоб запобігти нападам зі підміною сервера або підміні сервера або нападам із посередником, якими можна було скористатися для компрометації шифрування. Для керування входом до машин, чиї ключі вузла є невідомими або зміненими, можна скористатися параметром StrictHostKeyChecking.

Якщо профіль користувача було прийнято сервером, сервер або виконає задану команду у неінтерактивному сеансі або, якщо команди не вказано, увійде до системи і надасть користувачеві доступ до командної оболонки у межах інтерактивного сеансу. Увесь обмін даними із віддаленою програмою або оболонкою буде автоматично зашифровано.

Якщо буде отримати запит щодо інтерактивного сеансу, типово, ssh надішле лише запит на псевдотермінал (pty) для інтерактивних сеансів, якщо клієнт такий має. Для перевизначення цієї поведінки можна скористатися прапорцями -T і -t.

Якщо розміщено псевдотермінал, користувач може скористатися керівними символами, які описано нижче.

Якщо псевдотермінал не розміщено, сеанс буде прозорим і ним можна буде скористатися для надійного передавання двійкових даних. У більшості систем встановлення для керівного символу значення “none” також зробить сеанс прозорим, навіть якщо використано tty.

Сеанс завершується, коли команда або оболонка на віддаленій машині виходить та всі з'єднання X11 та TCP закриті.

КЕРІВНІ СИМВОЛИ

Коли запитано псевдотермінал, ssh підтримує декілька функцій через використання символу контролю (escape).

Одинарний символ тильди можна надіслати за допомогою послідовності ~~ або вказавши за тильдою один із символів поза списком, який наведено нижче. За керівним символом, щоб його було оброблено як особливий, завжди має бути символ нового рядка. Керівний символ можна змінити у файлах налаштувань за допомогою інструкції налаштування EscapeChar або за допомогою параметра командного рядка -e.

Підтримувані керівні послідовності (припускаємо, що типовим символом є ‘~’):

Від’єднатися.
Перевести ssh у фоновий режим.
Вивести список переспрямованих з'єднань.
Перевести ssh у фоновий режим після виходу із системи при очікуванні на завершення роботи переспрямованого з'єднання або сеансів X11.
Показати список керівних символів.
Надіслати BREAK на віддалену систему (корисно, лише якщо на однорівневому вузлі передбачено його підтримку).
Відкрити командний рядок. У поточній версії це надає змогу додавати переспрямовування за допомогою параметрів -L, -R і -D (див. вище). Це також надає змогу скасовувати наявні переспрямування портів за допомогою синтаксичної конструкції -KL[адреса_прив'язки:]порт для локальних, -KR[адреса_привʼязки:]порт для віддалених і -KD[адреса_прив'язки:]порт для динамічних переспрямувань портів. Конструкція !команда надає користувачеві змогу виконати локальну команду, якщо увімкнено параметр PermitLocalCommand у ssh_config(5). Доступ до базової довідки можна отримати за допомогою параметра -h.
Надіслати ключі з'єднання повторно (корисно, лише якщо на однорівневому вузлі передбачено підтримку цієї дії).
Зменшити докладність (LogLevel) при записі помилок до stderr.
Збільшити докладність (LogLevel) при записі помилок до stderr.

ПЕРЕСПРЯМОВУВАННЯ TCP

Переспрямування довільних з'єднань TCP захищеним каналом можна налаштувати або з командного рядка, або з файла налаштувань. Одним із можливих застосувань переспрямування TCP є захищене з'єднання із поштовим сервером; іншим є проходження брандмауерів.

У наведеному нижче прикладі ми поглянемо на організацію шифрованого обміну даними для клієнта IRC, навіть якщо на сервері IRC, з яким він встановлює з'єднання, не передбачено безпосередньої підтримки шифрованого обміну даними. Це працює так: користувач встановлює з'єднання із віддаленим вузлом за допомогою ssh, вказуючи порти, які слід використовувати для переспрямовування з'єднання. Після цього можна запустити програму локально, і ssh зашифрує і переспрямує з'єднання на віддалений сервер.

У наведеному нижче прикладі сеанс IRC тунельовано з клієнта на сервер IRC з адресою “server.example.com”, виконано долучення до каналу “#users” із псевдонімом “pinky”, з використанням стандартного порту IRC, 6667:

$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
$ irc -c '#users' pinky IRC/127.0.0.1

Використання параметра -f переводить ssh у фоновий режим, а віддалену команду “sleep 10” вказано, щоб надати певний час (у нашому прикладі, 10 секунд) для запуску програми, яка має використовувати тунель. Якщо протягом вказаного часу не буде встановлено з'єднання, ssh завершить роботу.

ПЕРЕСПРЯМОВУВАННЯ X11

Якщо для змінної ForwardX11 встановлено значення “yes” (див. опис параметрів -X, -x та -Y вище), і користувач користується X11 (встановлено змінну середовища DISPLAY), з'єднання із дисплеєм X11 буде автоматично переспрямовано на віддалений бік у такий спосіб, щоб усі програми X11, які запущено з оболонки (або команди) надсилали дані шифрованим каналом, а з'єднання із справжнім сервером X буде виконано з локальної машини. Не слід встановлювати DISPLAY вручну від імені користувача. Переспрямовування з'єднань X11 можна налаштувати у командному рядку або файлах налаштувань.

Значення DISPLAY, встановлене ssh, вказуватиме на машину сервера, але із номером дисплея, який є більшим за нуль. Так і має бути. Причиною є те, що ssh створює “проксі” -сервер X на машині сервера для переспрямовування з'єднань шифрованим каналом.

ssh також автоматично налаштовує дані Xauthority на машині сервера. Для цього програма створює псевдовипадкову куку уповноваження, зберігає її у Xauthority на сервері і перевіряє, чи переспрямовані з'єднання несуть цю куку, потім заміняє її на справжню куку, коли відкривається з'єднання. Програма ніколи не надсилає справжню куку розпізнавання на машину сервера (і, звичайно ж, ніякі куки не буде надіслано у форматі простого тексту).

Якщо для змінної ForwardAgent встановлено значення “yes” (див. опис параметрів -A і -a вище) і користувач користується агентом розпізнавання, з'єднання із агентом буде автоматично переспрямовано на віддалений бік.

ПЕРЕВІРКА КЛЮЧІВ ВУЗЛА

Під час першого з'єднання із сервером користувачеві буде надано відбиток відкритого ключа сервера (якщо не вимкнено параметр StrictHostKeyChecking). Відбитки можна визначити за допомогою ssh-keygen(1):

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Якщо відбиток вже відомий, його можна зіставити із еталонним і прийняти або відкинути ключ. Якщо доступні лише застарілі відбитки (MD5) для сервера, можна скористатися параметром ssh-keygen(1) -E для зниження версії алгоритму відбитка, яку буде використано для зіставлення.

Через складність порівняння ключів вузлів простим переглядом рядків відбитків передбачено підтримку візуального порівняння ключів за допомогою зображення. Якщо встановити для параметра VisualHostKey значення “yes”, під час кожної спроби увійти на сервер буде показано невеличке зображення на основі графіки ASCII, незалежно від того, є сеанс інтерактивним чи ні. Якщо користувач знає візерунок для відомого сервера, йому буде просто визначити, чи було змінено ключ вузла, оскільки візерунок буде зовсім іншим. Втім, оскільки такі візерунки теж не є однозначними, подібність візерунка до того, який запам'ятав користувач, дає лише високу ймовірність того, що ключ вузла є незмінним, але не є гарантією цього.

Щоб отримати список відбитків разом із їхньою випадковою частиною для усіх відомих вузлів, можна скористатися такою командою:

$ ssh-keygen -lv -f ~/.ssh/known_hosts

Якщо відбиток є невідомим, доступним є альтернативний спосіб перевірки: перевірка відбитків SSH за допомогою DNS. До файла zonefile буде додано додаткові записи ресурсів (RR), SSHFP, а клієнт з'єднання зможе порівняти відбиток із тим, що надає ключ.

У цьому прикладі ми встановлюємо з'єднання клієнта із сервером, “host.example.com”. Спочатку слід додати записи ресурсів SSHFP для host.example.com до zonefile:

$ ssh-keygen -r host.example.com.

Виведені рядки буде додано до zonefile. Щоб перевірити, чи відповідає запитам щодо відбитків зона, віддайте таку команду:

$ dig -t SSHFP host.example.com

Нарешті, клієнт встановлює з'єднання:

$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Щоб дізнатися більше, ознайомтеся із описом параметра VerifyHostKeyDNS на сторінці документації ssh_config(5).

ЗАСНОВАНІ НА SSH ВІРТУАЛЬНІ ПРИВАТНІ МЕРЕЖІ (VPN)

У ssh передбачено підтримку тунелювання Virtual Private Network (VPN) з використанням псевдопристрою мережі tun(4). Таке тунелювання надає змогу об'єднувати дві мережі у безпечний спосіб. Параметр налаштувань sshd_config(5) PermitTunnel керує тим, чи передбачено підтримку цієї можливості на сервері, і визначає рівень підтримки (обмін даними на шарі 2 чи 3).

У наведеному нижче прикладі ми з'єднаємо клієнтську мережу 10.0.50.0/24 із віддаленою мережею 10.0.99.0/24 за допомогою з'єднання точка-точка з 10.1.1.1 до 10.1.1.2, якщо тільки на сервері SSH, запущеному на шлюзі до віддаленої мережі, за адресою 192.168.1.15, це дозволено.

На клієнті:

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

На сервері:

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

Остаточне коригування клієнтського доступу можна виконати за допомогою файла /root/.ssh/authorized_keys (див. нижче) та параметра сервера PermitRootLogin. Вказаний нижче запис дозволятиме з'єднання на пристрої 1 tun(4) від користувача “jane” і з'єднання на пристрої 2 tun від користувача “john”, якщо для PermitRootLogin встановлено значення “forced-commands-only”:

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

Оскільки конфігурація на основі SSH є доволі надмірною, вона краще пасує для тимчасових випадків, зокрема для бездротових VPN. На сталішому рівні, налаштувати VPN можна за допомогою інших інструментів, зокрема ipsecctl(8) та isakmpd(8).

СЕРЕДОВИЩЕ

Зазвичай, ssh встановлює такі змінні середовища:

Змінна DISPLAY вказує на розташування сервера X11. ssh автоматично встановлює для неї значення, яке вказує на значення у формі “назва_вузла:n”, де “назва_вузла” вказує на вузол, на якому запущено оболонку, а ‘n’ є цілим числом ≥ 1. ssh використовує це особливе значення для переспрямування з'єднань X11 захищеним каналом. Зазвичай, у користувача немає потреби встановлювати DISPLAY явним чином, оскільки це призведе до втрати з'єднанням X11 захисту (і потребуватиме від користувача копіювання усіх потрібних кук уповноваження вручну).
Встановлено значення шляху до домашнього каталогу користувача.
Синонім USER; встановіть для сумісності із системами, де використовують цю змінну.
Встановити шлях до поштової скриньки користувача.
Встановити типове значення PATH, як його вказано під час компіляції ssh.
Якщо ssh потрібен пароль, програма читає пароль з поточного термінала, якщо її було запущено з термінала. Якщо із ssh не пов'язано жодного термінала, але встановлено змінні середовища DISPLAY і SSH_ASKPASS, буде виконано програму, яку вказано змінною SSH_ASKPASS, і відкрито вікно X11 для читання пароля. Це, зокрема, корисно при виклику ssh з .xsession або пов'язаного скрипту. (Зауважте, що на деяких машинах, щоб це спрацювало, може виникнути потреба у переспрямовуванні вхідних даних з /dev/null.)
Надає ширший контроль над використанням програми askpass. Якщо для цієї змінної встановлено значення “never”, ssh ніколи не намагатиметься скористатися цією програмою. Якщо встановлено значення “prefer”, ssh надаватиме пріоритет використанню програми askpass над TTY при надсиланні запитів щодо паролів. Нарешті, якщо для змінної встановлено значення “force”, програму askpass буде використано для введення усіх паролів, незалежно від того, чи встановлено значення змінної DISPLAY.
Визначає шлях до сокета UNIX-domain, який використовують для обміну даними з агентом.
Вказує на клієнтську і серверну сторони з'єднання. Значення змінної складається із чотирьох відокремлених пробілами записів: IP-адреси клієнта, номера порту клієнта, IP-адреси сервера та номера порту сервера.
У цій змінній зберігається початковий командний рядок, якщо буде виконано примусову команду. Змінною можна скористатися для видобування початкових аргументів.
Для цією змінної встановлюють значення назви tty (шляху до пристрою), пов'язаного із поточною оболонкою або командою. Якщо у поточному сеансі немає tty, значення цієї змінної встановлено не буде.
Може бути встановлено sshd(8) для зберігання назв призначених інтерфейсів, якщо клієнтом було надіслано запит щодо тунельного переспрямовування.
Може бути встановлено sshd(8). Ця змінна може містити шлях до файла зі списком успішно використаних способів розпізнавання при встановленні сеансу, включно із будь-якими використаними відкритими ключами.
Значення цієї змінної встановлюють для позначення поточного часового поясу, якщо його було встановлено, коли було запущено фонову службу (тобто фонова служба передає значення новим з'єднанням).
Встановлено значення назви облікового запису користувача, який увійшов до системи.

Крім того, ssh читає ~/.ssh/environment і додає рядки у форматі “НАЗВА_ЗМІННОЇ=значення” середовищу, якщо цей файл існує і користувачі можуть змінювати власне середовище. Щоб дізнатися більше, ознайомтеся із описом параметра PermitUserEnvironment на сторінці довідки sshd_config(5).

ФАЙЛИ

~/.rhosts
Цей файл використовують для розпізнавання на основі вузла (див. вище). На деяких машинах цей файл має бути доступним для читання для усіх, якщо домашній каталог користувача зберігається на розділі NFS, оскільки sshd(8) читає його від імені користувача root. Крім того, власником цього файла має бути користувач з'єднання, і він має бути недоступним для запису будь-яким іншим користувачам. Рекомендованими правами доступу для більшості машин є читання-запис для користувача і недоступність для інших.

~/.shosts
Цей файли використовують у той самий спосіб, що і .rhosts, але він уможливлює засноване на назві вузла розпізнавання без дозволу на вхід до системи за допомогою rlogin/rsh.

~/.ssh/
Цей каталог є типовим розташуванням для усіх налаштувань користувача та даних щодо розпізнавання. Немає загальної вимоги тримати весь вміст цього каталогу секретним, але рекомендовані дозволи — читання/запис/виконання для користувача, і недоступне для інших.

~/.ssh/authorized_keys
Показує список публічних ключів (DSA, ECDSA, Ed25519, RSA), що їх можна використовувати для входу користувача. Формат цього файлу описано на сторінці довідки sshd(8). Цей файл не є надсекретним, але рекомендовані дозволи — читання/запис для користувача, та недоступне для інших.

~/.ssh/config
Це користувацький файл конфігурації. Формат файлу і опції конфігурації описано в ssh_config(5). Оскільки тут є можливість зловживання, файл має мати суворі дозволи: читання/запис для користувача і заборонено запис для інших. Він може бути відкритий до запису групою користувача, якщо відповідна група містить лише одного користувача.

~/.ssh/environment
Містить додаткові визначення для змінних середовища; див. СЕРЕДОВИЩЕ вище.

~/.ssh/id_dsa
 
~/.ssh/id_ecdsa
 
~/.ssh/id_ecdsa_sk
 
~/.ssh/id_ed25519
 
~/.ssh/id_ed25519_sk
 
~/.ssh/id_rsa
Містять закриті ключі для розпізнавання. У цих файлах зберігаються конфіденційні дані. Вони мають бути придатним до читання від імені користувача, але недоступні для інших (читання, запис та виконання). ssh просто проігнорує файл закритого ключа, якщо він є доступним для інших користувачів. Можна вказати пароль при створенні ключа. Цей пароль буде використано для шифрування конфіденційної частини цього файл з використанням алгоритму AES-128.

~/.ssh/id_dsa.pub
 
~/.ssh/id_ecdsa.pub
 
~/.ssh/id_ecdsa_sk.pub
 
~/.ssh/id_ed25519.pub
 
~/.ssh/id_ed25519_sk.pub
 
~/.ssh/id_rsa.pub
Містять відкриті ключі для розпізнавання. Ці файли не є конфіденційними і можуть бути (не обов'язково) придатними для читання від імені інших користувачів.

~/.ssh/known_hosts
Містить список ключів вузлів для всіх вузлів, в які зайшов користувач, і що не є ключами вузлів, відомими на системному рівні. Див. sshd(8) для подробиць про формат цього файла.

~/.ssh/rc
Команди в цьому файли виконує ssh коли користувач входить в систему, і одразу перед тим, як запускається оболонка користувача (або команда). Див. сторінку довідки sshd(8) щодо подробиць.

/etc/hosts.equiv
Цей файл призначено для розпізнавання на основі вузла (див. вище). Права на запис до нього повинен мати лише користувач root.

/etc/ssh/shosts.equiv
Цей файли використовують у той самий спосіб, що і hosts.equiv, але він уможливлює засноване на назві вузла розпізнавання без дозволу на вхід до системи за допомогою rlogin/rsh.

/etc/ssh/ssh_config
Загальносистемний файл налаштувань. Формат файла і параметри налаштувань описано у ssh_config(5).

/etc/ssh/ssh_host_key
 
/etc/ssh/ssh_host_dsa_key
 
/etc/ssh/ssh_host_ecdsa_key
 
/etc/ssh/ssh_host_ed25519_key
 
/etc/ssh/ssh_host_rsa_key
У цих файлах містяться закриті частини ключів вузлів. Дані з файлів використовують для заснованого на назві вузла розпізнавання.

/etc/ssh/ssh_known_hosts
Загальносистемний список відомих ключів вузлів. Цей файл має бути приготовано адміністратором системи так, що у ньому містилися відкриті ключі вузлів для усіх машин у організації. Він має бути доступним до читання для усіх. Подальші настанови з форматування цього файла наведено на сторінці підручника sshd(8).

/etc/ssh/sshrc
Команди в цьому файли виконує ssh коли користувач входить в систему, і одразу перед тим, як запускається оболонка користувача (або команда). Див. сторінку довідки sshd(8) щодо подробиць.

СТАН ВИХОДУ

ssh завершує роботу зі станом виходу віддаленої команди або станом виходу 255, якщо сталася помилка.

ДИВ. ТАКОЖ

scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

СТАНДАРТИ

S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, January 2006.

J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, January 2006.

F. Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, January 2006.

J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, January 2006.

M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, January 2006.

B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, January 2006.

M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006.

J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, November 2006.

D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, December 2009.

A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).

АВТОРИ

OpenSSH походить від початкового і вільного випуску ssh 1.2.12, автором якого є Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt і Dug Song усунули багато вад, додали нові можливості та створили OpenSSH. Markus Friedl зробив внесок у підтримку версій протоколу SSH 1.5 і 2.0.

ПЕРЕКЛАД

Український переклад цієї сторінки посібника виконано lxlalexlxl <lxlalexlxl@ukr.net>, Andrij Mizyk <andmizyk@gmail.com>, Andriy Rysin <arysin@gmail.com> і Yuri Chornoivan <yurchor@ukr.net>

Цей переклад є безкоштовною документацією; будь ласка, ознайомтеся з умовами GNU General Public License Version 3. НЕ НАДАЄТЬСЯ ЖОДНИХ ГАРАНТІЙ.

Якщо ви знайшли помилки у перекладі цієї сторінки підручника, будь ласка, надішліть електронний лист до списку листування перекладачів: trans-uk@lists.fedoraproject.org

$Mdocdate: 28 листопада 2022 року $ Debian