SSH-COPY-ID(1)

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

КОРОТКИЙ ОПИС
ssh-copy-id [-f] [-n] [-s] [-x] [-i [identity_file]] [-p port] [-o ssh_option] [-t target_path] [user@] hostname ssh-copy-id -h | -?

ОПИС
ssh-copy-id is a script that uses ssh(1) to log into a remote machine (presumably using a login password, so password authentication should be enabled, unless you've done some clever use of multiple identities). It assembles a list of one or more fingerprints (as described below) and tries to log in with each key, to see if any of them are already installed (of course, if you are not using ssh-agent(1) this may result in you being repeatedly prompted for pass-phrases). It then assembles a list of those that failed to log in and, using ssh(1), enables logins with those keys on the remote server. By default it adds the keys by appending them to the remote user's ~/.ssh/authorized_keys (creating the file, and directory, if necessary). It is also capable of detecting if the remote system is a NetScreen, and using its ‘set ssh pka-dsa key ...’ command instead.

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

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

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

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

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

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

-t target_path
    the path on the target system where the keys should be added (defaults to ".ssh/authorized_keys")

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

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

-x  This option is for debugging the ssh-copy-id script itself. It sets the shell's -x flag, so that you can see the commands being run.

-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 бажаного ключа, щоб зробити його найсвіжішим.

ПРИКЛАДИ
If you have already installed keys from one system on a lot of remote hosts, and you then create a new key, on a new client machine, say, it can be difficult to keep track of which systems on which you've installed the new key. One way of dealing with this is to load both the new key and old key(s) into your ssh-agent(1). Load the new key first, without the -c option, then load one or more old keys into the agent, possibly by ssh-ing to the client machine that has that old key, using the -A option to allow agent forwarding:

    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

The reason you might want to specify the -i option in this case is to ensure that the comment on the installed key is the one from the .pub file, rather than just the filename that was loaded into your agent. It also ensures that only the id you intended is installed, rather than all the keys that you have in your ssh-agent(1). Of course, you can specify another id, or use the contents of the ssh-agent(1) as you prefer.

Having mentioned ssh-add(1)'s -c option, you might consider using this whenever using agent forwarding to avoid your key being hijacked, but it is much better to instead use ssh(1)'s ProxyCommand and -W option, to bounce through remote servers while always doing direct end-to-end authentication. This way the middle hop(s) don't get access to your ssh-agent(1). A web search for ‘ssh proxycommand nc’ should prove enlightening (NB the modern approach is to use the -W option, rather than 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.