Документація українською/ man/ man1/ ssh.1

Назва

ssh - клієнт захищеної оболонки OpenSSH

Стисло

   **ssh** [**-afgknqstvxACNTVX1246**] [**-b** _вихідна_адреса_] [**-c** _специфікація_шифру_]
       [**-D** _порт_]       [**-e** _знак_екранування_]        [**-F** _файл_конфігурації_]
       [**-i** _файл_ідентифікації_]  [**-L** [_вихідна_адреса_**:**]_порт_**:**_хост_**:**_порт_хосту_]
       [**-l** _реєстраційне_ім'я_] [**-m** _автент_ключ_] [**-O** _кер_команда_] [**-o** _опція_]
       [**-p** _порт_] [**-R** [_вихідна_адреса_**:**]_порт_**:**_хост_**:**_порт_хосту_] [**-S** _кер_сокет_]
       [_користувач@_]_хост_ [_команда_]

Опис

ssh (клієнт SSH) є програмою для реєстрації на віддаленій машині і виконанню на ній команд. Її задумано як заміну ?rlogin(1) і ?rsh(1), надаючи можливість захищеної шифрованої комунікації між двома хостами через незахищену мережу. Сполучення X11 і довільні порти TCP/IP також можна перенаправити через захищений канал.

ssh з'єднується і реєструється на вказаному хості. Користувач повинен засвідчити свою ідентичність віддаленій машині, використовуючи одну з декількох метод, в залежності від версії діючого протоколу:

Протокол SSH версії 1

Перша метода автентифікації полягає у використанні файлів rhost або rhost.equiv у поєднанні із RSA-перевіркою хосту. Якщо машина, з якої долучився користувач, згадується у /etc/hosts.equiv або /etc/ssh/shosts.equiv на віддаленій машині, і назви користувача збігаються на обох кінцях, користувачеві дозволяється негайно зареєструватись. Також, якщо в користувацькому домашньому каталозі на віддаленій машині присутні файли ~/.rhosts або ~/.shosts, що містять рядок з назвою клієнтської машини з ім'ям її користувача, цьому користувачеві також дозволено реєструватися. Додатково, за умови, що сервер може перевірити клієнтський хост-ключ (дивіться /etc/ssh/ssh_known_hosts і ~/.ssh/known_hosts у розділі ФАЙЛИ), тільки тоді дозволяється реєстрація. Ця форма автентифікації, закриває дірки в безпеці, пов'язані з підробкою IP, DNS або маршрутизації. (Примітка для адміністраторів: /etc/hosts.equiv, ~/.rhosts і протоколи rlogin/rsh, загалом, небезпечні і необхідно заборонити, якщо прагнете безпеки.)

Друга автентифікаційна метода основується на RSA. Ця схема спирається на шифруванні на основі публічних ключів: існують криптографічні (шифрувальні) системи де шифрування і розшифровування відбувається завдяки двом окремим ключам, при цьому неможливо здобути ключ розшифровування при наявному ключі шифрування. RSA саме і є однією з таких систем. Ідея полягає в тому, що кожний користувач створює власну публічну/приватну пару ключів з метою автентифікації. Сервер знатиме публічний ключ і тільки користувач на клієнті володітиме приватним ключем.

Файл ~/.ssh/authorized_keys містить перелік публічних ключів, яким дозволено реєструватися на сервері. Під час реєстрації користувача, програма ssh вкаже серверу, яку пару ключів вона хоче використати для автентифікації. Сервер перевірить, чи цей ключ дійсний, і якщо так - пошле користувачеві (насправді програмі ssh, яка діє від імені користувача) виклик у формі довільного числа, зашифрованого користувацьким публічним ключем. Виклик може бути розшифровано тільки використовуючи відповідний приватний ключ. Клієнт повинен розшифрувати виклик за допомогою приватного ключа, доказуючи, що він знає приватний ключ (тобто є тим за кого себе видає), але не розкриваючи ключ серверу.

ssh втілює автентифікаційний протокол RSA автоматично. Користувач створює власну пару ключів RSA, запустивши програму ssh-keygen(1). Остання збереже приватний ключ у ~/.ssh/identity, і публічний ключ у ~/.ssh/identity.pub у домашньому каталозі користувача. Користувач потім повинен копіювати identity.pub до ~/.ssh/authorized_keys у його домашньому каталозі на віддаленій машині (файл authorized_keys є відповідником традиційному ~/.rhosts і містить по одному ключ на рядок, навіть якщо рядки дуже довгі від цього). Після цього, користувач може реєструватися без необхідності вводити гасло. RSA-автентифікація набагато безпечніша за rhost.

Найзручнішим способом використання RSA-автентифікації, можливо, є у поєднанні з автентифікаційним агентом. Загляніть до ssh-agent(1) для додаткової інформації.

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

Протокол SSH версії 2

Ті самі автентифікаційні методи доступні й тоді, коли користувач під'єднається, використовуючи протокол версії 2. За умови, що змінна PreferredAuthentications має стандартне значення, клієнт спробує спочатку засвідчитися звичайною, основаною на дозволених хостах, методою; якщо це зазнає невдачі, відбудеться спроба автентифікуватися за допомогою публічного ключа; і, нарешті, якщо перші дві спроби не вдалися, матиме місце інтерактивна автентифікація із введенням даних з клавіатури з перевіркою гасла.

Методa публічного ключа схожa на RSA-автентифікацію, описану в попередньому розділі, і дозволяє використання алгоритмів DSA або RSA. Клієнт застосує приватний ключ ~/.ssh/id_dsa або ~/.ssh/id_rsa для підпису ідентифікатора сеансу і пошле результат серверові. Сервер перевірить, чи відповідний публічний ключ перелічено у ~/.ssh/authorized_keys, і надасть доступ, якщо ключ і підпис дійсні. Ідентифікатор сеансу утворюється зі спільного значення Dіffie-Hellman, відомого тільки клієнту і серверові.

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

Додатково, ssh підтримує по-машинну або "запит-відповідь" автентифікацію.

Протокол 2 забезпечує додаткові механізми для конфіденційності (мережний трафік шифрується за використанням 3DES, Blowfish, CAST128 або Arcfour) і перевірки цілісності (hmac-sha1, hmac-md5). Зверніть увагу, що протоколу 1 бракує хорошого механізму забезпечення цілісності даних.

Вхід у систему і віддалене виконання

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

Якщо надано псевдо-термінал (звичайний сеанс після реєстрації з системою), то користувач може вживати керуючими послідовностями, описаними нижче.

Якщо псевдо-термінал не призначено, сеанс буде прозорим і може застосовуватися для передачі бінарних даних. На більшості систем, надання керівному символу значення "none" зробить сеанс прозорим , навіть якщо використовується термінал.

Сеанс закінчиться, коли команда або оболонка на віддаленій машині завершить роботу і всі сполучення Х11 і TCP/IP обірвано. Статус виходу віддаленої програми повертається як статус виходу ssh.

Керівні послідовності

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

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

Підтримуваними послідовностями (припускаючи стандартну '~') являються:

~. : Здійснить відключення.

~^Z : Пошле ssh у фоновий режим (використайте команду fg щоб вивести сесію на передній план).

~# : Надасть список випереджених сполучень.

~& : Пошле ssh у фоновий режим під час виходу, очікуючи завершення випереджених сполучень або сесій Х11 (тільки для протоколу версії 1).

~? : Виведе список керуючих послідовностей.

~B : Пошле сигнал BREAK віддаленій системі (дійсне тільки для протоколу SSH версії 2, і тільки коли протилежна сторона підтримує це).

~C : Відкриє командний рядок ssh. На сьогодні, це дозволяє випередження портів, використовуючи опії -L і -R (дивіться нижче), також відміну існуючого випередження віддалених портів за допомогою -KR портхосту_.

~R : Запит на додатковий обмін ключами (тільки для протоколу SSH версії 2, і якщо протилежна сторона підтримує це).

Перенаправлення X11 і TCP

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

Значення DISPLAY, встановлене ssh, вказуватиме на машину-сервер, але з номером дисплея більшим за нуль. Це нормально, і відбувається тому, що ssh створює посередницький (проксі) Х-сервер на машині-сервері для пересилання з'єднань через зашифрований канал.

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

Якщо користувач використовує автентифікаційного агента (змінна ForwardAgent встановлено до ``yes_, або використано -A або -a опції, описані нижче), то підключення до агента автоматично перенаправляється протилежній стороні. _

Перенаправлення довільних TCP/IP-з'єднань через захищений канал, можна вказати або на командному рядкові, або у файлі конфігурації. Одне з можливих застосувань перенаправлення TCP/IP - це захищене з'єднання з електронним гаманцем; інше - проходження повз мережний екран (firewall).

Автентифікація сервера

ssh автоматично обслуговує і перевіряє базу даних, що втримує ідентифікацію для всіх машин, з якими колись було сполучення. RSA-ключі машини зберігаються в ~/.ssh/known_hosts. Додатково автоматично перевіряється файл /etc/ssh/ssh_known_hosts щодо відомих хостів. Будь-яку нову машину автоматично додано в користувацький файл. Якщо інформація по ідентифікації машини змінилася, то ssh попередить про це й унеможливить автентифікацію гаслом, щоб уникнути здобуття користувацького гасла "троянським конем". Інше призначення цього механізму полягає в тому, щоб запобігти нападів типу man-іn-the-middle, використовуваних для обходу шифрування. Можна використати параметр StrictHostKeyChecking, щоб заборонити вхід у систему з тих машин, чиї ключі не відомі або змінені.

ssh можна налагодити таким чином, щоб вона перевіряла ідентичність хосту за допомогою ресурсу записів відбитків (SSHFP), що видаються DNS. Для цього необхідно встановити параметр VerifyHostKeyDNS, що керуватиме тим як здійснюються запити DNS. Записи відбитків SSHFP можна відтворити за допомогою ssh-keygen(1).

ssh розпізнає наступні ключі:

-1 : Вимагає використання тільки протоколу версії 1.

-2 : Вимагає використання тільки протоколу версії 2.

-4 : Вимагає використання тільки адрес IPv4.

-6 : Вимагає використання тільки адрес IPv6.

-A : Вмикає перенаправлення з'єднання агента автентифікації. Це можна також вказати на по-машинній основі у файлі конфігурації.

Слід обережно ставитись до вмикання перенаправлення агента. Користувачі з можливістю обійти дозволи на доступ до файлів на віддаленій машині (а саме, до сокету домену Юнікс, що належить агентові), можуть дістатися до локального агента через перенаправлене сполучення. Атакуючий не може отримати дані ключів від агента, однак вони спроможні здійснити операції, пов'язані з ключами, що дозволить їм засвідчитись, використовуючи ідентичності, завантажені агентом.

-a : Вимикає перенаправлення з'єднання агента автентифікації.

-b вихіднаадреса : Використає вихіднуадресу локальної машини, як джерело сполучення. Корисно для систем із кількома адресами.

-C : Вимагає стиснення всіх даних (включаючи stdin, stdout, stderr і дані перенаправлених з'єднань X11 і TCP/IP). Алгоритм ущільнення відповідає тому, що застосовується в gzip(1), а рівень стиснення можна регулювати параметром CompressionLevel для протоколу 1-ї версії. Ущільнення даних є бажаним у випадку модемних ліній і інших повільних засобах сполучення, але сповільнить передачу у швидких мережах. Стандартні значення можна встановити на по-машинній основі у файлі конфігурації; дивіться параметр Compression.

-c специфікаціяшифру_ : Вибір специфікації шифру для зашифровування сесії.

Протокол версії 1 дозволяє специфікацію одного шифру. Підтримуваними значеннями являються "3des", "blowfish" і "des". 3des (потрійний des) складається з послідовності зашифровування-розшифровування-зашифровування з трьома відмінними ключами. Він вважається безпечним. blowfish - це швидкий блоковий шифр; він видається дуже надійним і набагато швидший за 3des. Останній, des, підтримується тільки для оберненої сумісності з первинним протоколом 1, що не підтримує 3des. Використання des не рекомендується, через криптографічну слабкість. Стандартним є 3des.

Для протоколу версії 2, специфікаціюшифру_ може бути визначено як, розділений комою, список шифрів у порядку їхнього пріоритету. Підтримуються "3des-cbc", "aes128-cbc", "aes192-cbc", "aes256-cbc", "aes128-ctr", "aes192-ctr", "aes256-ctr", "arcfour128", "arcfour256", "arcfour", "blowfish-cbc" і "cast128-cbc". Стандартний список складається з

       aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
       arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
       aes192-ctr,aes256-ctr

-D порт : Вказує локальне "динамічне" перенаправлення порту на рівні додатка. Це працює шляхом виділення сокету для прослуховування порту на локальній машині, і як тільки відбулося під'єднання до цього порту, його перенаправлено через захищений канал, і протокол додатку потім вирішує куди з'єднається віддалена машина. На сьогоднішній день підтримуються протоколи SOCKS4 i SOCKS5, і ssh поводитиметься як SOCKS-сервер. Тільки користувач root може перенаправляти привілейовані порти. Динамічне перенаправлення портів можна також вказати у файлі конфігурації.

-e ch|^ch|none : Задає керівний символ для сеансів із псевдо-терміналом (стандартний символ - '~'). Керівний символ розпізнається тільки на початку рядка. Якщо за ним слідує крапка, ('.'), це завершить з'єднання; наступна control-Z призупинить з'єднання і два керівних символи підряд передадуть один керівний символ. Ключ -e з параметром "none" скасовує будь-які керівні символи і робить сеанс прозорим.

-F файлконфігурації : Дозволяє вказати альтернативний файл конфігурації. Якщо конфігураційний файл задано на командному рядкові, системний (/etc/ssh/ssh_config) буде проігноровано. Стандартним конфігураційним файлом користувача, який ssh шукатиме, є ~/.ssh/config ._

-f : Примушує ssh перейти у фоновий режим перед самим виконанням команди. Це корисно, якщо ssh збирається спитати гасло або вирази-гасла, але користувач хоче зробити це у фоновому режимі. Це неявно вмикає -n. Рекомендованим способом запуску програм Х11 на віддаленому комп'ютері є щось на зразок "ssh -f host xterm".

-g : Дозволяє віддаленим машинам звертатися до локальних перенаправлених портів.

-I smardcard-пристрій : Вказує, який smardcard-пристрій використати. Аргументом є пристрій, який ssh використовуватиме для комунікації з карткою smartcard, що зберігає приватний ключ RSA користувача.

-i файлідентифікації : Вказує файл з якого зчитується ідентифікація (приватний ключ) для RSA або DSA автентифікації. Без задання, це ~/.ssh/identity для протоколу версії 1, і ~/.ssh/id_dsa_ для протоколу версії 2. Файли ідентифікації також можна зазначити на по-машинній основі у файлі конфігурації. Можна вказати підряд кілька параметрів -i (і кілька ідентифікаторів у конфігураційному файлі).

-k : Забороняє перенаправлення (представлення) ідентифікаційної інформації GSSAPI серверу.

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

    [_вихідна_адреса_**/**]_порт_**/**_хост_**/**_порт_хосту_

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

-l реєстраційнеім'я_ : Вказує ім'я користувача для реєстрації з віддаленою системою. Це можна також вказати на по-машинній основі у файлі конфігурації.

-M : Встановлює ssh у "чільний" режим для спільного використання з'єднання. Зверніться до опису ControlMaster сторінки ?ssh config(5) для повного опису.

-m mac-ключ : Додатково, для протоколу версії 2 можна вказати, розділений комою, список алгоритмів MAC (код автентифікації повідомлення) у порядку пріоритету. Для додаткової інформації, шукайте по ключовому слову MAC.

-N : Не виконувати віддаленої команди. Корисна тільки для перенаправлення портів (протокол версії 2).

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

-O керкоманда : Керує основним ущільнювальним процесом активного сполучення. За допомогою опції -O, аргумент керкоманда буде інтерпретовано і передано основному процесові. Чинними командами являються "check" (перевіряє, чи активний основний процес) і "exit" (вимога завершення основного процесу).

-o опція : Можна використати для задання опцій у форматі, використовуваному файлом конфігурації. Це корисно для вказівки параметрів, для яких не існує окремої опції командного рядка. Для повного опису параметрів, перелічених нижче, і їхніх можливих значень, дивіться ?ssh config(5).

       AddressFamily
       BatchMode
       BindAddress
       ChallengeResponseAuthentication
       CheckHostIP
       Cipher
       Ciphers
       ClearAllForwardings
       Compression
       CompressionLevel
       ConnectionAttempts
       ConnectTimeout
       ControlMaster
       ControlPath
       DynamicForward
       EscapeChar
       ForwardAgent
       ForwardX11
       ForwardX11Trusted
       GatewayPorts
       GlobalKnownHostsFile
       GSSAPIAuthentication
       GSSAPIDelegateCredentials
       HashKnownHosts
       Host
       HostbasedAuthentication
       HostKeyAlgorithms
       HostKeyAlias
       HostName
       IdentityFile
       IdentitiesOnly
       KbdInteractiveDevices
       LocalForward
       LogLevel
       MACs
       NoHostAuthenticationForLocalhost
       NumberOfPasswordPrompts
       PasswordAuthentication
       Port
       PreferredAuthentications
       Protocol
       ProxyCommand
       PubkeyAuthentication
       RemoteForward
       RhostsRSAAuthentication
       RSAAuthentication
       SendEnv
       ServerAliveInterval
       ServerAliveCountMax
       SmartcardDevice
       StrictHostKeyChecking
       TCPKeepAlive
       UsePrivilegedPort
       User
       UserKnownHostsFile
       VerifyHostKeyDNS
       XAuthLocation

-p порт : Порт сполучення з віддаленим хостом. Це можна вказати окремо для кожної машини у файлі конфігурації.

-q : Тихий режим. Пригнічує всі попереджувальні і діагностичні повідомлення.

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

Перенаправлення портів можна так само вказати у файлі конфігурації. Тільки надкористувач може здійснювати перенаправлення привілейованих портів. Адреси IPv6 позначаються альтернативним синтаксисом:

    [_вихідна_адреса_**/**]_порт_**/**_хост_**/**_порт_хосту_

Без задання, слухаючий сокет на сервері буде прив'язаний до оберненого на себе інтерфейсу. Це можна змінити, якщо вказати вихіднуадресу. Порожнє значення вихідноїадреси, або '*', вказують віддаленому сокетові слухати на всіх інтерфейсах. Вказування віддаленої вихідноїадреси_ матиме успіх тільки якщо на сервері увімкнено опцію GatewayPorts (дивіться ?sshd config(5)).

-S керсокет_ : Вказує шлях до керівного сокету для спільного використання з'єднання. Зверніться до опису ControlPath і ControlMaster у ?ssh config(5).

-s : Можна використати для виклику підсистеми на віддаленому хості. Підсистеми - це риса протоколу SSH2, яка полегшує застосування SSH як захищений засіб передачі для інших додатків (наприклад ?sftp(1)). Підсистема вказується як віддалена команда.

-T : Скасовує надання псевдо-терміналу. .T -t Наполягає на наданні псевдо-терміналу. Це можна використати для виконання різноманітних, пов'язаних з екраном, програм на віддаленому сервері, що може виявитись корисним при втіленні сервісів меню. Багатократні опції -t змушують призначення терміналу, навіть якщо ssh не має локального.

-V : Виведе інформацію про версію програми і завершить роботу.

-v : Багатослівний режим. Спричинить вивід ssh повідомлень відлагодження про власний прогрес. Це корисно для зневадження сполучень, автентифікації і конфігурації. Багатократні опції -v (максимум 3) збільшують докладність повідомлень.

-X : Вмикає перенаправлення X11. Це можна також вказати для окремого хосту у файлі конфігурації.

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

З цієї причини, перенаправлення X11 являється частиною обмежень розширення SECURITY X11. Зверніться до опції -Y та директиви ForwardX11Trusted (дивіться ?ssh config(5)) для додаткової інформації.

-x : Забороняє перенаправлення X11.

-Y : Дозволяє перенаправлення X11 тільки довіреним хостам.

Файли конфігурації

ssh може додатково бути конфігуровано у файлах конфігурації окремих користувачів і системному файлі. Їхній формат і опції конфігурації описано в ?ssh config(5).

Середовище

ssh, як правило, встановить наступні змінні середовища: DISPLAY Змінна DISPLAY вказує на місцезнаходження серверу X11. Воно автоматично встановлюється ssh, вказуючи на значення, що має форму хост:N, де хост вказує на машину з оболонкою, а N - це ціле >= 1. ssh використовує це спеціальне значення для перенаправлення сполучень X11 через захищений канал. Користувач, за звичайних обставин, не повинен явно вказувати DISPLAY, оскільки це призведе до занепаду захищеності сполучення X11 (і вимагатиме ручного копіювання авторизаційних ріп'яшків).

HOME : Шлях до домашнього каталогу користувача.

LOGNAME : Синонім для USER; ім'я користувача (для сумісності з тими системами, що використовують цю змінну).

MAIL : Шлях до поштової скриньки користувача.

PATH : Стандартні шляхи до виконуваних файлів, як було встановлено під час компіляції ssh.

SSH_ASKPASS : Якщо ssh потрібно вираз-гасло, вона прочитає його з поточного терміналу, якщо ssh запущено з терміналу. Якщо ж немає відповідного терміналу, але встановлено DISPLAY і SSH_ASKPASS, вона виконає програму, вказану SSH_ASKPASS щоб відкрити вікно X11 для прочитання виразу-гасла. Це особливо корисно під час виклику ssh з .xsession або подібного скрипту. (Зауважте, що на деяких машинах необхідно перенаправити /dev/null до стандартного вводу, щоб це працювало.)

SSH_AUTH_SOCK : Визначає шлях до сокету домену Юнікс для комунікації з агентом.

SSH_CONNECTION : Визначає клієнтський і серверний бік з'єднання. Ця змінна включає чотири, розділених комою значення: IP-адреса клієнта, номер порту клієнта, IP-адреса серверу і порт серверу.

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

SSH_TTY : Встановлюється до назви терміналу (шляху до пристрою), пов'язаного з поточною командою або оболонкою. Якщо поточний сеанс не має терміналу, ця змінна не встановлюється.

TZ : Змінна часового поясу, якщо часовий пояс було встановлено під час запуску демону (тобто, демон передає це значення новим сполученням).

USER : Ім'я користувача, що зареєструвався.

На додаток, ssh прочитає ~/.ssh/environment і додасть рядки у форматі "ЗМІННА=значення" до середовища, якщо цей файл існує і користувачеві дозволяється змінити середовище. Для додаткової інформації, прочитайте про параметр PermitUserEnvironment у ?sshd config(5).

Файли

~/.ssh/known_hosts : Файл, в який здійснюється запис ключів усіх хостів, до яких підключився користувач, і які не внесені в /etc/ssh/ssh_known_hosts. Дивіться ?sshd(8).

~/.ssh/identity, ~/.ssh/id_dsa, ~/.ssh/id_rsa : Містять автентифікаційні дані користувача (приватний ключ). Ці файли відповідають, перший - RSA протоколу 1, другий - DSA протоколу 2, і третій - RSA протоколу 2. Файли включають чутливу інформацію і повинні містити дозвіл на читання для користувача, але недосяжні для решти (жодного з дозволів на читання/запис/виконання). Зверніть увагу, що ssh ігнорує файл приватних ключів, якщо до нього мають доступ інші, окрім користувача. Існує можливість вказати вираз-гасло під час ґенерації ключа; вираз-гасло використовуватиметься для зашифровування чутливої частини цього файлу, за допомогою 3DES.

~/.ssh/identity.pub, ~/.ssh/id_dsa.pub, ~/.ssh/id_rsa.pub : Містить публічний ключ для автентифікації (в людиночитаємій формі). Зміст файлу ~/.ssh/identity.pub потрібно додати до ~/.ssh/authorized_keys на всіх машинах, на яких користувач бажає зареєструватися, використовуючи RSA-автентифікацію протоколу 1. Зміст ~/.ssh/id_dsa.pub і ~/.ssh/id_rsa.pub - до ~/.ssh/authorized_keys на всіх машинах, що використовують DSA або RSA-автентифікацію протоколу 2-ї версії. Ці файли не містять небезпечної інформації і можуть (не обов'язково) включати дозвіл на читання будь-ким. Ці файли не використовуються автоматично не являються обов'язковими; їх надано тільки для зручності користувача.

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

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

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

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

/etc/ssh/ssh_config : Системний файл конфігурації. Формат і опції описано в ?ssh config(5).

/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key : Ці три файли містять приватні частини хостових ключів і використовуються для (як значення параметрів) RhostsRSAAuthentication і HostbasedAuthentication. Якщо застосовується RhostsRSAAuthentication з протоколом версії 1, ssh необхідно встановити чинний користувацький ID (suid) до root, оскільки ключ хосту може прочитати тільки root. Для протоколу 2, ssh користується ssh-keysign (8) для доступу до ключа хосту для HostbasedAuthentication. Це усуває необхідність встановлення чинного ID (suid) до root, коли використовується це метода автентифікації.

~/.rhosts : Цей файл використовується у автентифікаціях RhostsRSAAuthentication і HostbasedAuthentication для переліку пар хост/користувач, яким дозволено реєструватися з системою. (Зауважте, що цей файл також використовується ?rlogin(1) і ?rsh(1), що робить небезпечним використання цього файлу.) Кожний рядок ~/.rhosts містить назву машини (стандартної форми, тієї, що повертається іменними серверами) і назву користувача цієї машини, розділені пробілом. Деякі машини вимагають загального дозволу на читання цього файлу, якщо домашній каталог користувача розміщено на одному з розділів NFS, оскільки ?sshd(8) читає його як root. Додатково, цей файл повинен належати користувачу і не включати дозволу на запис для решти. Рекомендованим набором дозволів для більшості машин є на читання/запис для користувача і жодного для решти.

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

~/.shosts : Файл, аналогічний .rhosts. Його мета полягає в тому, щоб дозволити автентифікації RhostsRSAAuthentication і HostbasedAuthentication без можливості сполучення за допомогою ?rlogin(1) або ?rsh(1).

/etc/hosts.equiv : Цей файл використовується під час автентифікацій RhostsRSAAuthentication і HostbasedAuthentication. Він містить стандартні назви хостів, по одній на кожний рядок (повний формат описано в сторінці ?sshd(8)). Якщо клієнтська машина знаходиться в цьому файлі, автоматично буде дозволено реєстрацію, за умови, що ім'я користувача збігається на клієнті і сервері. Додатково, вимагається вдала автентифікація ключа машини. Цей файл повинен включати дозвіл на запис root-користувачем.

/etc/ssh/shosts.equiv : Цей файл обробляється точно так само як /etc/hosts.equiv. Він дозволяє реєстрацію за допомогою ssh, але не ?rsh(1) або ?rlogin(1).

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

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

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

Діагностика

Код виходу ssh дорівнює статусу (останньої) віддаленої команди, або 255, якщо мала місце помилка.

Дивіться також

gzip(1), ?rsh(1), ?scp(1), ?sftp(1), ssh-add(1), ?ssh-agent(1), ?ssh-keygen(1), ?telnet(1), ?hosts.equiv(5), ?ssh config(5), ?ssh-keysign(8), ?sshd(8)

  1. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH Protocol Architecture, draft-ietf-secsh-architecture-12.txt, Січень 2002 року. (Цей матеріал постійно змінюється.)

Автори

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.