НАЗВА

     ssh-copy-id — використання доступних локально ключів для уповноважених входів до віддаленої
     системи

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

     ssh-copy-id [-f] [-n] [-s] [-x] [-i [файл_профілю]] [-p порт] [-o параметр_ssh] [-t
     шлях_призначення] [користувач@]назва_вузла ssh-copy-id -h | -?

ОПИС

     ssh-copy-id є скриптом, який використовує ssh(1) для входу до віддалених машин (ймовірно,
     якщо не налаштовано якогось вигадливого використання декількох профілів, за допомогою пароля
     до облікового запису, тому має бути увімкнено розпізнавання за паролем). Скрипт збирає
     список з одного або декількох відбитків (як це описано нижче) і намагається здійснити вхід
     за допомогою кожного з ключів, щоб перевірити, чи якийсь з них вже встановлено (Звичайною,
     якщо ви не користуєтеся ssh-agent(1), це може призвести до потреби у повторному введенні
     пароля). Потім скрипт збирає список тих відбитків, за якими увійти не вдалося, і,
     використовуючи ssh(1), вмикає вхід за ключами на віддаленому сервері. Типово, скрипт додає
     ключі, дописуючи їх до файла ~/.ssh/authorized_keys віддаленого користувача (створюючи файл,
     і каталог, якщо це потрібно). Скрипт також може виявляти, чи є віддалена система системою
     NetScreen, і користуватися її командою ‘set ssh pka-dsa key ...’.

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

     -i файл_профілю
             Використовувати лише ключі, які містяться у файлі_профілю (а не шукати профілі за
             допомогою ssh-add(1) або default_ID_file).  Якщо назва файла не завершується на
             .pub, цей суфікс буде додано. Якщо назви файла не вказано, буде використано назву
             default_ID_file.

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

     -f      Примусовий режим: не перевіряти, якщо ключі є на віддаленому сервері. Це означає, що
             закритий ключ не потрібен. Звичайно ж, це може призвести до встановлення у
             віддаленій системі декількох копій ключа.

     -n      Виконати тестовий пуск. Замість встановлення ключів до віддаленої системи, просто
             вивести список ключів, які було б встановлено.

     -s      Режим SFTP: зазвичай, відкриті ключі встановлюють виконанням команд на боці
             віддаленої системи. Якщо вказано цей параметр, буде отримано файл
             ~/.ssh/authorized_keys користувача, до файла буде внесено зміни у локальній системі,
             а результати буде вивантажено за допомогою sftp на віддалену систему. Цей параметр
             корисний, якщо на сервері є обмеження щодо команд, якими можна скористатися на
             віддаленому боці.

     -t шлях_призначення
             шлях у системі призначення, куди слід додати ключі (типовим є
             «.ssh/authorized_keys»)

     -p порт, -o параметр_ssh
             Ці два параметри буде просто передано незмінними, разом із їхніми аргументами, щоб
             уможливити встановлення порту або інших параметрів ssh(1), відповідно.

             Замість встановлення цих параметрів у рядку команди, часто краще скористатися
             (окремими для вузла) параметрами у файлі налаштувань ssh(1): ssh_config(5).

     -x      Цей параметр призначено для діагностики самого скрипту ssh-copy-id.  Він встановлює
             прапорець -x командної оболонки, отже, ви зможете бачити команди, які буде виконано.

     -h, -?  Вивести дані щодо користування

     Типовою поведінкою без зазначення -i, буде перевірка того, чи виводить щось ‘ssh-add -L’, і
     якщо щось буде виведено, використати виведені ключі. Зауважте, що результатом цього буде те,
     що назвою файла буде коментар щодо ключа, який було задано ssh-add(1), коли ключ було
     завантажено до вашого ssh-agent(1), а не коментар, що міститься у цьому файлі, і це трохи
     сумно. В інших випадках, якщо ssh-add(1) не надасть ключів, буде використано вміст
     default_ID_file.

     default_ID_file найсвіжіший файл, який відповідає: ~/.ssh/id*.pub, (виключаючи відповідники
     взірцю ~/.ssh/*-cert.pub), отже, якщо ви створите ключ, який не слід використовувати в
     ssh-copy-id, просто скористайтеся touch(1) для файла .pub бажаного ключа, щоб зробити його
     найсвіжішим.

ПРИКЛАДИ

     Якщо ви вже встановили ключі з однієї системи на багатьох віддалених вузлах, а потім,
     скажімо, створили ключ на новій клієнтській машині, буде важкою стежити за тим, у яких
     системах ви вже встановили новий ключ. Одним із вирішень цієї проблеми є завантаження нового
     і старого ключів до вашого ssh-agent(1).  Спочатку завантажте новий ключ без параметра -c,
     потім завантажте до агента один або декілька старих ключів, можливо, скориставшись ssh до
     клієнтської машини, де є цей старий ключ, з параметром -A для уможливлення переспрямування
     агента:

           user@newclient$ ssh-add
           user@newclient$ ssh -A old.client
           user@oldl$ ssh-add -c
           Ні ... запит щодо пароля ...
           user@old$ logoff
           user@newclient$ ssh someserver

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

           user@newclient$ ssh-copy-id -i someserver

     Причиною для використання тут параметра -i є забезпечення того, щоб коментарем до
     встановленого ключа був коментар з файла .pub, а не просто назва файла, який було
     завантажено до вашого агента. Цим також забезпечується те, що буде встановлено лише
     потрібний вам ідентифікатор, а не усі ключі, які є у вашому ssh-agent(1).  Звичайно ж, ви
     можете вказати інший ідентифікатор або скористатися, якщо хочете, даними ssh-agent(1).

     Якщо вже згадали параметр ssh-add(1) -c, вам варто користуватися ним кожного разу при
     переспрямуванні агента, щоб уникнути перехоплення вашого ключа. Втім, набагато кращим
     виходом є використання параметрів ssh(1) ProxyCommand та -W для усування проміжних
     віддалених серверів і безумовного використання безпосереднього розпізнавання між кінцями
     ланцюга зв'язку. Якщо користуватися цими параметрами, проміжні ланки не отримуватимуть
     доступу до вашого ssh-agent(1).  Якщо пошукати в інтернеті ‘ssh proxycommand nc’, ви
     отримаєте достатні матеріали (N.B. сучасним підходом є використання параметра -W, а не
     nc(1)).

ДИВ. ТАКОЖ

     ssh(1), ssh-agent(1), sshd(8)

ПЕРЕКЛАД

     Український переклад цієї сторінки посібника виконано Yuri Chornoivan <yurchor@ukr.net>

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

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