Scroll to navigation

SSH-COPY-ID(1) General Commands Manual SSH-COPY-ID(1)

NAZWA

ssh-copy-idużywa lokalnie dostępnych kluczy do autoryzacji logowania na zdalnym komputerze

SKŁADNIA

ssh-copy-id [-f] [-n] [-s] [-x] [-i [plik-tożsamości]] [-t ścieżka-docelowa] [-F konfiguracja-ssh] [[-o opcja-ssh] ...] [-p port] [użytkownik@]nazwa-stacji ssh-copy-id -h | -?

OPIS

ssh-copy-id jest skryptem korzystającym z ssh(1) do zalogowania się na zdalnym komputerze (prawdopodobnie za pomocą hasła logowania, zatem uwierzytelnianie hasłem powinno być włączone, chyba że sprytnie wykorzysta się różne tożsamości). Tworzy listę jednego lub więcej odcisków palców (jak to opisano poniżej) i próbuje dokonać logowania za pomocą każdego z kluczy, sprawdzając, czy jakiś jest już ainstalowany (oczywiście, jeśli nie korzysta się z ssh-agent(1), może to prowadzić do wielokrotnej konieczności wprowadzania hasła). Następnie tworzy listę z tych, którymi nie udało się zalogować i, za pomocą ssh(1), włącza logowanie za pomocą tych kluczy na zdalnym serwerze. Domyślnie dodaje klucze dołączając je do pliku ~/.ssh/authorized_keys zdalnego użytkownika (tworząc plik i katalog, jeśli to konieczne). Potrafi również wykryć, czy zdalny system to NetScreen i wykorzystać wówczas w zamian polecenie ‘set ssh pka-dsa key ...’.

Dostępne są następujące opcje:

[plik-tożsamości]
Używa jedynie klucza/kluczy z pliku-tożsamości (zamiast szukać tożsamości za pomocą ssh-add(1) lub w domyślnym-pliku-tożsamości). Jeśli nazwa pliku nie kończy się przyrostkiem .pub, jest on dodawany. Jeśli nie poda się nazwy pliku, używany jest w zamian domyślny-plik-tożsamości.

Proszę zauważyć, że w ten sposób można zapewnić się, że skopiowane klucze mają taki komentarz, jaki się preferuje i/lub dodane dodatkowe opcje, poprzez upewnienie się, że dany plik klucza ma je ustawione jako preferowane, przed dokonaniem kopiowania.

Tryb wymuszony: nie sprawdza, czy klucze są obecne na zdalnym serwerze. Oznacza to, że nie jest wymagany klucz prywatny. Oczywiście może to doprowadzić do instalacji więcej niż jednej kopii klucza na zdalnym systemie.
wykonuje przebieg próbny. Zamiast instalować klucz(e) na zdalnym systemie jedynie wypisuje te, które zostałyby zainstalowane.
Tryb SFTP: klucze publiczne są zwykle instalowane poprzez wykonanie poleceń po stronie zdalnej. Przy użyciu tej opcji, plik użytkownika ~/.ssh/authorized_keys zostanie pobrany, zmodyfikowany lokalnie i przesłany za pomocą zftp. Opcja niniejsza jest przydatna, jeśli serwer posiada ograniczenia wobec poleceń, jakie mogą być wykonane po stronie zdalnej.
ścieżka-docelowa
ścieżka na systemie zdalnym, gdzie mają być dodane klucze (domyślnie „.ssh/authorized_keys”).
port
Określa port na zdalnej stacji, z którym nastąpi połączenie.
konfiguracja-ssh, -o opcja-ssh
Opcje te są przekazywane bez żadnej modyfikacji (wraz z argumentami) do ssh/sftp, pozwalając na ustawienie, odpowiednio, alternatywnego pliku konfiguracyjnego lub innych opcji.

Zamiast przekazywać je jako opcje wiersza poleceń, często lepszym rozwiązaniem jest korzystanie z (przypisanych poszczególnym stacjom) ustawień w pliku konfiguracyjnym ssh(1): ssh_config(5).

Opcja służy do debugowania skryptu ssh-copy-id. Ustawia opcję -x powłoki, dzięki czemu widać wykonywane polecenia.
, -?
Wypisuje krótką pomoc.

Domyślnym zachowaniem bez opcji -i, jest sprawdzenie, czy ‘ssh-add -L’ daje jakiś wynik i jeśli tak jest, używane są wypisane w ten sposób klucze. Proszę zauważyć, że w ten sposób komentarzem klucza stanie się nazwa pliku podana ssh-add(1), gdy klucz był ładowany do ssh-agent(1), zamiast komentarz umieszczony w tym pliku, co jest nieco niefortunne. W innym przypadku, jeśli ssh-add(1) nie poda żadnych kluczy, zostanie użyta zawartość domyślnego-pliku-tożsamości.

Domyślnym-plikiem-tożsamości jest najnowszy plik, który pasuje do wzorca ~/.ssh/id*.pub (z wyjątkiem pasujących do wzorca ~/.ssh/*-cert.pub), tak więc jeśli utworzy się klucz, który ma nie być wykorzystywany przez ssh-copy-id, wystarczy wykonać polecenie touch(1) na pliku .pub preferowanego klucza, aby oznaczyć go jako najnowszy.

PRZYKŁADY

Jeśli już zainstalowano klucze z jednego systemu na wielu zdalnych stacjach, a następnie utworzono nowy klucz, na nowej stacji klienckiej, utrudnione może być śledzenie, na których systemach zainstalowano nowy klucz. Jednym ze sposobów na radzenie sobie z tą uciążliwością jest załadowanie zarówno nowego klucza jak i starych kluczy do swojego programu ssh-agent(1). Najpierw należy załadować nowy klucz, bez opcji -c, a następnie jeden lub więcej starych kluczy, na przykład za pomocą połączenia ssh ze stacją kliencką ze starym kluczem, korzystając z opcji -A, pozwalającej na przekierowanie agenta:

użytkownik@nowy-klient$ ssh-add
użytkownik@nowy-klient$ ssh -A stary.klient
użytkownik@stary$ ssh-add -c
... zapytanie o frazę kodującą ...
użytkownik@stary$ logoff
użytkownik@nowy-klient$ ssh jakiś-serwer

teraz zatem, jeśli nowy klucz zainstalowano na serwerze, dostęp nie będzie wymagał potwierdzenia, natomiast jeśli włączone byłyby jedynie stare klucze, wyświetli się zapytanie z prośbą o potwierdzenie, co jest wskazówką, że należy się wylogować i uruchomić

użytkownik@nowy-klient$ ssh-copy-id -i jakiś-serwer

Powodem, dla którego można zechcieć podać tu opcję -i jest upewnienie się, że komentarzem w instalowanym kluczu jest ten z pliku .pub, a nie jest to jedynie nazwa pliku załadowanego do agenta. W ten sposób zapewnia się też, że instalowany jest jedynie identyfikator, który był przeznaczony do zainstalowania, a nie wszystkie klucze ze swojego ssh-agent(1). Oczywiście można podać inny identyfikator, albo skorzystać z zawartości ssh-agent(1), jeśli taka jest wola użytkownika.

Jeśli wspomnieliśmy o opcji -c ssh-add(1), można rozważyć użycie jej przy korzystaniu z przekierowania agenta, aby uniknąć przechwycenia klucza, jednak znacznie lepszym wyborem będzie użycie ProxyCommand i opcji -W ssh(1), aby przy przeskakiwaniu pomiędzy zdalnymi serwerami zawsze dokonywać bezpośredniego uwierzytelnienia typu end-to-end. Dzięki temu serwer(y) pośrednie nie uzyskają dostępu do ssh-agent(1) użytkownika. Proszę poszukać w Internecie wyrażenia „ssh proxycommand nc”, aby dowiedzieć się więcej (przy okazji: współcześnie powinno się korzystać z opcji -W, zamiast nc(1)).

ZOBACZ TAKŻE

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

TŁUMACZENIE

Tłumaczenie niniejszej strony podręcznika: Michał Kułach <michal.kulach@gmail.com>

Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej manpages-pl-list@lists.sourceforge.net

June 17, 2010 Nixpkgs