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

ssh-copy-idutilizează chei disponibile la nivel local pentru a autoriza autentificarea intrărilor pe o mașină la distanță

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 | -?

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:

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.

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ță.
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).
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ță.
ruta-câtre-țintă
ruta de pe sistemul țintă unde trebuie adăugate cheile (implicit „.ssh/authorized_keys”)
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).

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.
, -?
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ă.

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).

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

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 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

$Mdocdate: 17 iunie 2010 $ Linux 6.11.5-arch1-1