Provided by: manpages-ro_4.23.1-1_all 
NUME
ssh-copy-id — utilizează chei disponibile la nivel local pentru a autoriza autentificarea intrărilor pe o
mașină la distanță
SINOPSIS
ssh-copy-id [-f] [-n] [-s] [-x] [-i [fișier_identitate]] [-p port] [-o opțiune_ssh] [-t ruta-câtre-țintă]
[utilizatorr@]numegazdă ssh-copy-id -h | -?
DESCRIERE
ssh-copy-id este un script care utilizează ssh(1) pentru a se conecta la o mașină de la distanță
(probabil folosind o parolă de conectare, deci autentificarea prin parolă ar trebui să fie activată, cu
excepția cazului în care ați folosit în mod inteligent mai multe identități). Acesta asamblează o listă
cu una sau mai multe amprente „fingerprints” (așa cum este descris mai jos) și încearcă să se conecteze
cu fiecare cheie, pentru a vedea dacă vreuna dintre ele este deja instalată (desigur, dacă nu folosiți
ssh-agent(1), acest lucru poate avea ca rezultat faptul că vi se va cere în mod repetat fraze de acces).
Apoi, acesta alcătuiește o listă a celor care nu au reușit să se autentifice și, folosind ssh(1), permite
autentificarea cu acele chei pe serverul de la distanță. În mod implicit, adaugă cheile adăugându-le la
~/.ssh/authorized_keys al utilizatorului de la distanță (creând fișierul și directorul, dacă este
necesar). De asemenea, este capabil să detecteze dacă sistemul de la distanță este un NetScreen și să
folosească în schimb comanda ‘set ssh pka-dsa key ...’.
Opțiunile sunt următoarele:
-i fișier-identitate
Utilizează numai cheia (cheile) conținută (conținute) în fișier_identitate (în loc să caute
identități prin ssh-add(1) sau în default_ID_file). Dacă numele fișierului nu se termină cu
.pub, acesta este adăugat. În cazul în care numele de fișier este omis, se utilizează
default_ID_file.
Rețineți că acest lucru poate fi utilizat pentru a vă asigura că cheile copiate au comentariul
preferat și/sau opțiunile suplimentare aplicate, asigurându-vă că fișierul de chei are aceste
opțiuni preferate înainte de a se încerca copierea.
-f Modul forțat: nu verifică dacă cheile sunt prezente pe serverul de la distanță. Aceasta înseamnă
că nu are nevoie de cheia privată. Desigur, acest lucru poate avea ca rezultat instalarea mai
multor copii ale cheii pe sistemul de la distanță.
-n face o probă simulată. În loc să instaleze chei pe sistemul de la distanță, imprimă pur și simplu
cheia (cheile) care ar fi fost instalată (instalate).
-s Modul SFTP: de obicei, cheile publice sunt instalate prin executarea de comenzi pe partea de la
distanță. Cu această opțiune, fișierul ~/.ssh/authorized_keys al utilizatorului va fi descărcat,
modificat local și încărcat cu «sftp». Această opțiune este utilă în cazul în care serverul are
restricții privind comenzile care pot fi utilizate pe partea de la distanță.
-t ruta-câtre-țintă
ruta de pe sistemul țintă unde trebuie adăugate cheile (implicit „.ssh/authorized_keys”)
-p port, -o opțiune_ssh
Aceste două opțiuni sunt pur și simplu trecute neatinse, împreună cu argumentul lor, pentru a
permite definirea portului sau a altor opțiuni ssh(1), respectiv.
În loc să le specificați ca opțiuni de linie de comandă, este adesea mai bine să folosiți
configurații (pentru fiecare gazdă) în fișierul de configurare ssh(1): ssh_config(5).
-x Această opțiune este destinată depanării scriptului ssh-copy-id în sine. Aceasta activează
opțiunea „-x” din shell, astfel încât să puteți vedea comenzile care sunt executate.
-h, -? Afișează un rezumat al utilizării
Comportamentul implicit fără -i, este de a verifica dacă ‘ssh-add -L’ oferă vreo ieșire, iar dacă da, se
utilizează acele chei. Rețineți că acest lucru are ca rezultat faptul că comentariul de pe cheie este
numele de fișier care a fost dat lui ssh-add(1) atunci când cheia a fost încărcată în ssh-agent(1), mai
degrabă decât comentariul conținut în acel fișier, ceea ce este regretabil. În caz contrar, dacă
ssh-add(1) nu furnizează nicio cheie se va utiliza conținutul fișierului default_ID_file.
default_ID_file este cel mai recent fișier care se potrivește: ~/.ssh/id*.pub, (cu excepția celor care
corespund cu ~/.ssh/*-cert.pub), astfel încât, dacă creați o cheie care nu este cea pe care doriți să o
utilizeze ssh-copy-id, trebuie doar să utilizați touch(1) pe fișierul .pub al cheii preferate pentru a o
restabili ca fiind cea mai recentă.
EXEMPLE
Dacă ați instalat deja chei de la un sistem pe o mulțime de gazde la distanță și apoi creați o nouă
cheie, de exemplu, pe un nou calculator client, poate fi dificil să țineți evidența sistemelor pe care
ați instalat noua cheie. O modalitate de a rezolva această problemă este să încărcați atât cheia nouă,
cât și cheile vechi în ssh-agent(1). Încărcați mai întâi noua cheie, fără opțiunea -c, apoi încărcați
una sau mai multe chei vechi în agent, eventual prin ssh-ing la mașina client care are acea cheie veche,
folosind opțiunea -A pentru a permite redirecționarea agentului:
utilizator@client_nou$ ssh-add
utilizator@client_nou$ ssh -A vechi.client
utilizator@vechi$ ssh-add -c
Nu ... solicitare pentru fraza de acces ...
utilizator@vechi$ logoff
utilizator@client_nou$ ssh vreun.server
acum, dacă noua cheie este instalată pe server, vi se va permite să intrați fără invitație, în timp ce
dacă aveți doar vechea cheie (sau vechile chei) activată(e), vi se va cere confirmarea, ceea ce
reprezintă semnalul dvs. pentru a vă reconecta și a rula
utilizator@client_nou$ ssh-copy-id -i vreunserver
Motivul pentru care ați putea dori să specificați opțiunea -i în acest caz este acela de a vă asigura că
comentariul de pe cheia instalată este cel din fișierul .pub, și nu doar numele de fișier care a fost
încărcat în agentul dumneavoastră. De asemenea, se asigură că este instalat doar id-ul pe care l-ați
dorit, și nu toate cheile pe care le aveți în ssh-agent(1). Desigur, puteți specifica un alt id sau
puteți utiliza conținutul fișierului ssh-agent(1), după cum preferați.
După ce am menționat opțiunea -c a lui ssh-add(1), ați putea lua în considerare utilizarea acesteia ori
de câte ori folosiți redirecționarea agentului pentru a evita ca cheia dvs. să fie deturnată, dar este
mult mai bine să folosiți în schimb opțiunea ssh(1) ProxyCommand și -W, pentru a ajunge la serverele de
la distanță în timp ce efectuați întotdeauna autentificarea directă de la un capăt la altul. În acest
fel, saltul sau saltelele intermediare nu au acces la ssh-agent(1). O căutare pe internet pentru ‘ssh
proxycommand nc’ ar trebui să se dovedească lămuritoare; NB: abordarea modernă este de a utiliza opțiunea
-W, mai degrabă decât nc(1).
CONSULTAȚI ȘI
ssh(1), ssh-agent(1), sshd(8)
TRADUCERE
Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu
<remusgabriel.chelu@disroot.org>
Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3:
https://www.gnu.org/licenses/gpl-3.0.html sau o versiune ulterioară cu privire la condiții privind
drepturile de autor. NU se asumă NICIO RESPONSABILITATE.
Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la
translation-team-ro@lists.sourceforge.net .
Debian 17 iunie, 2010 SSH-COPY-ID(1)