Журнал LinuxFormat - перейти на главную

LXF155:За­да­вать клю­чи SSH

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(→‎Соз­дание клю­ча)
Строка 52: Строка 52:
  
 
При уста­нов­ке со­единения с по­мо­щью клю­чей ком­пь­ю­те­ры об­ща­ют­ся друг с дру­гом не так, как при ау­тен­ти­фи­ка­ции по па­ро­лю. При под­клю­чении к уда­лен­но­му ком­пь­ю­те­ру ва­ше­го кли­ен­та уда­лен­ный ком­пь­ю­тер соз­да­ет за­прос с по­мо­щью ва­ше­го от­кры­то­го клю­ча. Кли­ент принима­ет за­прос и от­ве­ча­ет на него на осно­ве ва­ше­го за­кры­то­го клю­ча.
 
При уста­нов­ке со­единения с по­мо­щью клю­чей ком­пь­ю­те­ры об­ща­ют­ся друг с дру­гом не так, как при ау­тен­ти­фи­ка­ции по па­ро­лю. При под­клю­чении к уда­лен­но­му ком­пь­ю­те­ру ва­ше­го кли­ен­та уда­лен­ный ком­пь­ю­тер соз­да­ет за­прос с по­мо­щью ва­ше­го от­кры­то­го клю­ча. Кли­ент принима­ет за­прос и от­ве­ча­ет на него на осно­ве ва­ше­го за­кры­то­го клю­ча.
−
 
+
[[Файл: | |thumb|400px|Одно из главных достоинств аутентификации с помощью ключей — то, что парольная фраза ключа SSH не передается через Интернет, в отличие от пароля.]]
 
OpenSSH мо­жет соз­да­вать клю­чи по ал­го­рит­мам RSA (Rivest-Shamir-Adleman) и DSA (Digital Signature Algorithm). Мо­же­те ис­поль­зо­вать лю­бой – на­деж­ны оба. По умол­чанию OpenSSH ис­поль­зу­ет RSA, бо­лее но­вый из двух. Для соз­дания клю­ча вве­ди­те на кли­ен­те сле­дую­щее:
 
OpenSSH мо­жет соз­да­вать клю­чи по ал­го­рит­мам RSA (Rivest-Shamir-Adleman) и DSA (Digital Signature Algorithm). Мо­же­те ис­поль­зо­вать лю­бой – на­деж­ны оба. По умол­чанию OpenSSH ис­поль­зу­ет RSA, бо­лее но­вый из двух. Для соз­дания клю­ча вве­ди­те на кли­ен­те сле­дую­щее:
  

Версия 07:43, 27 июня 2018

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)


Шифрование ключей

OpenSSH: Как лег­ко вой­ти

Hardcore Linux Про­верь­те се­бя на кру­том про­ек­те для про­дви­ну­тых поль­зо­ва­те­лей

За­пуск скрип­тов че­рез SSH-со­еди­не­ние мо­жет иметь свои за­ка­вы­ки. Ма­янк Шар­ма де­мон­ст­ри­ру­ет, как их перехитрить.

LXF154.84.1.png
(thumbnail)
Соз­да­вать клю­чи и управ­лять ими уме­ет еще и Seahorse.

OpenSSH – од­на из немно­гих ве­щей, по­лез­ных всем поль­зо­ва­те­лям, будь то ад­минист­ра­то­ры, раз­ра­бот­чи­ки или до­машние поль­зо­ва­те­ли. Нам при­вы­чен уда­лен­ный вход че­рез OpenSSH на дру­гой ком­пь­ю­тер до­ма, в офи­се или на дру­гом кон­це планеты.

Ра­бо­та с OpenSSH – са­ма про­сто­та. Когда кли­ент в пер­вый раз свя­зы­ва­ет­ся с сер­ве­ром, SSH соз­да­ет ме­ж­ду ними за­щи­щен­ный ка­нал свя­зи, в ко­то­ром весь об­мен дан­ны­ми шиф­ру­ет­ся. За­тем кли­ент спра­ши­ва­ет ваш па­роль и от­прав­ля­ет его на сер­вер. По па­ро­лю сер­вер ау­тен­ти­фи­ци­ру­ет вас и раз­ре­ша­ет вой­ти в сис­те­му на уда­лен­ном ком­пь­ю­те­ре.

И здесь кроется боль­шая про­бле­ма. Вы под­клю­чае­тесь к уда­лен­но­му ком­пь­ю­те­ру толь­ко по­сле руч­но­го вво­да па­ро­ля.

Содержание

Боль­шая про­бле­ма

Пред­по­ло­жим, на локаль­ном ком­пь­ю­те­ре у вас есть за­дание cron, еже­час­но за­пускаю­щее скрипт, ко­то­рый ко­пи­ру­ет с уда­лен­но­го сер­ве­ра па­ру фай­лов. И при ка­ж­дой по­пыт­ке скрип­та свя­зать­ся с уда­лен­ным ком­пь­ю­те­ром у него за­про­сят па­роль. Это ис­клю­ча­ет ис­поль­зо­вание SSH для за­дач, ко­то­рые долж­ны вы­пол­нять­ся без ва­ше­го уча­стия. Или нет?

Рас­смот­рим эту про­бле­му под­робнее. В со­став OpenSSH вхо­дят несколь­ко ути­лит команд­ной стро­ки, та­ких как scp и sftp: это рас­ши­рения ути­лит cp и ftp, пред­на­зна­чен­ные для ра­бо­ты в за­щи­щен­ных ка­на­лах свя­зи. Ес­ли вы хо­тите ско­пи­ро­вать фай­лы на уда­лен­ный хост или с него, вы поль­зуе­тесь scp, ко­то­рая ав­то­ма­ти­че­­ски уста­но­вит SSH-со­единение с уда­лен­ным хостом. При ка­ж­дом за­пуске ко­ман­да scp уста­нав­ли­ва­ет но­вое со­единение с уда­лен­ным хостом. И ес­ли у вас три ко­ман­ды scp, один и тот же па­роль при­дет­ся вво­дить три­ж­ды. По­это­му вам вряд ли за­хо­че­тся ис­поль­зо­вать scp в сво­их скрип­тах в чис­том ви­де.

Вдо­ба­вок SSH не слиш­ком хо­ро­шо мас­шта­би­ру­ет­ся. Ес­ли у вас несколь­ко учет­ных за­пи­сей на раз­ных ком­пь­ю­те­рах се­ти, за­помнить уникаль­ные слож­ные па­ро­ли для ка­ж­до­го из них бу­дет невоз­мож­но.

Ключ к ре­шению про­бле­мы

Для ре­шения этой про­бле­мы нуж­но из­менить ис­поль­зуе­мый по умол­чанию ме­ханизм ау­тен­ти­фи­ка­ции. В OpenSSH есть раз­лич­ные ме­ханиз­мы ау­тен­ти­фи­ка­ции, и один из них осно­ван на клю­чах, а не на па­ро­лях. К то­му же он са­мый на­деж­ный. По умол­чанию OpenSSH ис­поль­зу­ет клю­чи для ау­тен­ти­фи­ка­ции под­лин­но­сти сер­ве­ра в пер­вый раз при под­клю­чении кли­ен­та к но­во­му уда­лен­но­му ком­пь­ю­те­ру:

$ ssh admin@server2. remote.com Ау­тен­тич­ность хос­та ‘server2.remote.com (server2.remote.com)’ не мо­жет бть ус­та­нов­ле­на.

ECDSA key fingerprint is ca:e8:b2:97:e4:d5:01:65:7e:d2:c4:db:12:3c:51:ce.

Вы уве­ре­ны, что хо­ти­те про­дол­жить со­еди­не­ние (да/нет)?

Когда вы в от­вет на­бе­ре­те «да», кли­ент пре­ду­пре­дит вас, что на­всегда до­бав­ля­ет уда­лен­ный хост в спи­сок из­вест­ных хостов. В дан­ном слу­чае OpenSSH ис­поль­зу­ет клю­чи для пре­дот­вра­щения атак «че­ло­век по­се­ре­дине» [Man in the middle, MITM-ата­ка].

Итак, в до­полнение к ау­тен­ти­фи­ка­ции сер­ве­ром кли­ен­та по па­ро­лю кли­ент то­же ау­тен­ти­фи­ци­ру­ет сер­вер по клю­чу.

У ка­ж­до­го сер­ве­ра OpenSSH есть сек­рет­ный уникаль­ный иден­ти­фи­ка­тор ID, на­зы­вае­мый клю­чом хоста, с по­мо­щью ко­то­ро­го он иден­ти­фи­ци­ру­ет се­бя кли­ен­там. При пер­вом под­клю­чении к уда­лен­но­му хосту от­кры­тая часть клю­ча хоста ко­пи­ру­ет­ся и со­хра­ня­ет­ся в локаль­ной учет­ной за­пи­си. При ка­ж­дом под­клю­чении к это­му хосту кли­ент SSH про­ве­ря­ет его под­лин­ность с по­мо­щью от­кры­то­го клю­ча.

Вы то­же мо­же­те соз­дать на­бор клю­чей для под­твер­ждения сво­ей под­лин­но­сти. OpenSSH восполь­зу­ет­ся этой па­рой клю­чей для про­вер­ки и соз­даст за­щи­щен­ное со­единение с уда­лен­ным сер­ве­ром.

За­кры­тый ключ досту­пен толь­ко вам и ис­поль­зу­ет­ся кли­ен­том OpenSSH для под­твер­ждения ва­шей под­лин­но­сти сер­ве­рам. Так­же есть от­кры­тый ключ, ко­то­рый, в со­от­вет­ст­вии со сво­им на­званием, на­хо­дит­ся в от­кры­том досту­пе. Вы долж­ны раз­мес­тить его на всех сво­их учет­ных за­пи­сях на уда­лен­ных ком­пь­ю­те­рах, к ко­то­рым намерены под­клю­чать­ся по SSH.

Соз­дание клю­ча

При уста­нов­ке со­единения с по­мо­щью клю­чей ком­пь­ю­те­ры об­ща­ют­ся друг с дру­гом не так, как при ау­тен­ти­фи­ка­ции по па­ро­лю. При под­клю­чении к уда­лен­но­му ком­пь­ю­те­ру ва­ше­го кли­ен­та уда­лен­ный ком­пь­ю­тер соз­да­ет за­прос с по­мо­щью ва­ше­го от­кры­то­го клю­ча. Кли­ент принима­ет за­прос и от­ве­ча­ет на него на осно­ве ва­ше­го за­кры­то­го клю­ча. [[Файл: | |thumb|400px|Одно из главных достоинств аутентификации с помощью ключей — то, что парольная фраза ключа SSH не передается через Интернет, в отличие от пароля.]] OpenSSH мо­жет соз­да­вать клю­чи по ал­го­рит­мам RSA (Rivest-Shamir-Adleman) и DSA (Digital Signature Algorithm). Мо­же­те ис­поль­зо­вать лю­бой – на­деж­ны оба. По умол­чанию OpenSSH ис­поль­зу­ет RSA, бо­лее но­вый из двух. Для соз­дания клю­ча вве­ди­те на кли­ен­те сле­дую­щее:

$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/bodhi/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/bodhi/.ssh/id_rsa.

Your public key has been saved in /home/bodhi/.ssh/id_rsa.pub.

The key fingerprint is:

dc:52:36:fc:9e:98:a4:71:ab:7c:66:22:af:f8:96:1f bodhi@bodhi-Aspire-5738

The key’s randomart image is:

Клю­чи луч­ше хранить в ка­та­ло­ге по умол­чанию, ес­ли нет вес­ких при­чин хранить их в дру­гом мес­те. Так­же обя­за­тель­но за­дай­те па­роль­ную фра­зу.

За­тем ssh-keygen соз­даст локаль­ный ка­та­лог SSH (~/.ssh), ес­ли его нет, и со­хранит за­кры­тую и от­кры­тую час­ти клю­ча в двух фай­лах в этом ка­та­ло­ге. По умол­чанию это фай­лы с име­на­ми id_rsa и id_rsa.pub. Файл id_rsa досту­пен для чтения толь­ко ва­ше­му поль­зо­ва­те­лю, а его со­дер­жи­мое до­полнитель­но за­щи­ще­но пу­тем шиф­ро­вания с па­роль­ной фра­зой, за­дан­ной ва­ми при генера­ции клю­ча.


Сле­дую­щий шаг – ско­пи­ро­вать от­кры­тый ключ на уда­лен­ный сер­вер. Ес­ли вы за­хо­ди­те на уда­лен­ный сер­вер server2.remote.com как поль­зо­ва­тель ‘admin’, мо­же­те пе­ре­мес­тить клю­чи од­ной ко­ман­дой:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub admin@server2.remote.com

admin@server2.remote.com’s password:

Те­перь по­про­буй­те зай­ти на ком­пь­ю­тер через посредство ко­ман­ды

ssh ‘admin@server2.remote.com’

и за­гляните в файл ~/.ssh/authorized_keys, что­бы убе­дить­ся, что мы не до­ба­ви­ли лишних клю­чей.

У вас за­про­сят па­роль­ную фра­зу для за­кры­то­го клю­ча. За­тем от­кры­тый ключ ав­то­ма­ти­че­­ски пе­ре­мес­тит­ся в соответ­ствующее ме­сто на уда­лен­ном сер­ве­ре. Ес­ли ад­минист­ра­тор уда­лен­но­го сер­ве­ра не изме­нял на­строй­ки OpenSSH, ваш ключ бу­дет до­бав­лен в файл ~/.ssh/authorized_keys.

Вот и все. Те­перь вы мо­же­те под­клю­чать­ся к уда­лен­но­му ком­пь­ю­те­ру с по­мо­щью клю­ча. При под­клю­чении к уда­лен­но­му ком­пь­ю­те­ру по ssh у вас бу­дет за­пра­ши­вать­ся па­роль­ная фра­за.

С ви­ду разница лишь в том, что вме­сто па­ро­ля уда­лен­но­го поль­зо­ва­те­ля вы ука­зы­вае­те па­роль­ную фра­зу за­кры­то­го клю­ча. Но как мы уже объ­яс­ня­ли, внут­ри уда­лен­ный сер­вер и кли­ент про­ве­ря­ют ва­шу под­лин­ность по клю­чам на осно­ве слож­ных ма­те­ма­ти­че­­ских вы­чис­лений, без пе­ре­да­чи па­ро­ля.

Ук­ре­пим за­щи­ту

Раз уж мы за­ве­ли клю­чи, для пу­щей безо­пас­но­сти сто­ит пол­но­стью от­клю­чить па­роль­ную ау­тен­ти­фи­ка­цию. Для это­го от­крой­те файл на­строй­ки сер­ве­ра (обыч­но /etc/ssh/.sshd_config) и из­мените зна­чение па­ра­мет­ра PasswordAuthentication с ‘yes’ на ‘no’.

Клю­чи ре­ши­ли нам од­ну серь­ез­ную про­бле­му: те­перь с од­ной па­роль­ной фра­зой мож­но под­клю­чать­ся по SSH на несколь­ко уда­лен­ных ком­пь­ю­те­ров, где есть ваш от­кры­тый ключ. Это из­бав­ля­ет вас от необ­хо­ди­мо­сти помнить ку­чу па­ро­лей, но за­пуск скрип­тов по-прежнему бу­дет пре­ры­вать­ся за­про­сом па­роль­ной фра­зы.


В OpenSSH есть ути­ли­та ssh-agent, ко­то­рая хранит ва­ши за­кры­тые клю­чи в па­мя­ти. Вам нуж­но толь­ко за­пустить аген­та и пе­ре­дать ему свои за­кры­тые клю­чи. Ес­ли агент за­пу­щен, кли­ен­ты SSH не бу­дут за­пра­ши­вать у вас клю­че­вые фра­зы, а возь­мут ин­фор­ма­цию у аген­та.

$ ssh-agent $SHELL

Здесь $SHELL – пе­ре­мен­ная ок­ру­жения с ва­шей обо­лоч­кой, ско­рее все­го /bin/bash. При за­пуске аген­та он вы­зы­ва­ет ука­зан­ную обо­лоч­ку как до­черний про­цесс.

Вы ви­ди­те лишь еще од­ну обо­лоч­ку, но у нее те­перь имеется доступ к аген­ту. И лю­бые вво­ди­мые ва­ми ко­ман­ды прой­дут че­рез аген­та, ко­то­рый за­дер­жит их и от­ве­тит всем, ко­му потребуется доступ к за­кры­тым клю­чам OpenSSH.

Пре­ж­де чем пой­ти даль­ше, дадим вам неболь­шой со­вет по за­пуску аген­та. Поскольку име­ет смысл при вхо­де в сис­те­му пер­вым за­пускать аген­та, мож­но из­менить (или соз­дать собственный) файл вхо­да в сис­те­му (~/.bash_profile), что­бы агент ав­то­ма­ти­че­­ски за­пускал­ся при за­груз­ке – тогда вы освободитесь от обязанности де­лать это вруч­ную.

За­пу­щен­но­му аген­ту на­до пе­ре­дать клю­чи. Для это­го вы­зы­ва­ет­ся про­грам­ма ssh-add, ко­то­рая по умол­чанию за­гру­жа­ет клю­чи из ва­ше­го фай­ла иден­ти­фи­ка­ции по умол­чанию; в на­шем слу­чае это ~/.ssh/id_rsa:

$ ssh-add

Enter passphrase for /home/bodhi/.ssh/id_rsa:

Identity added: /home/bodhi/.ssh/id_rsa (/home/bodhi/.ssh/id_rsa)

Те­перь при под­клю­че­нии к уда­лен­но­му ком­пь­ю­те­ру ко­ман­дой

ssh admin@server2.remote.com

вы смо­же­те вой­ти в сис­те­му без вво­да па­роль­ной фра­зы!

scp и sftp то­же смо­гут под­клю­чать­ся к уда­лен­ным хостам, не за­пра­ши­вая у вас па­роль­ной фра­зы. Таким образом, вам те­перь ничто не мешает до­бав­лять в рас­пи­сание и ав­то­ма­ти­че­­ски за­пускать скрип­ты, ра­бо­таю­щие с фай­ла­ми на уда­лен­ном ком­пь­ю­те­ре.

Един­ст­вен­ное неудоб­ст­во в том, что по­сле ка­ж­дой пе­ре­за­груз­ки ком­пь­ю­те­ра нуж­но за­гру­жать свои за­кры­тые клю­чи в агент (ав­то­ма­ти­че­­ски за­пускае­мый .bash_profile). Де­лать это раз в день – пре­крас­ный ком­про­мисс ме­ж­ду удоб­ст­вом и безо­пас­но­стью. По­сколь­ку за­гру­жать их нуж­но толь­ко один раз, те­перь у вас мо­жет быть несколь­ко клю­чей для раз­лич­ных сер­ве­ров или за­дач.

К то­му же в сис­те­мах на ба­зе Gnome, в ко­то­рые вхо­дит Seahorse, агент SSH Seahorse по­мо­га­ет за­гру­зить клю­чи SSH и хранит их в па­мя­ти. Он ра­бо­та­ет так же, как ssh-agent, и кэ­ши­ру­ет клю­чи SSH при пер­вом об­ра­щении к ним.

Это по­хо­же на ко­ман­ду ssh-add. Агент Seahorse за­пра­ши­ва­ет у вас па­роль и по­зво­ля­ет со­хранить па­ро­ли в gnome-keyring. За­тем он от­ве­ча­ет на все по­сле­дую­щие за­про­сы клю­чей SSH.

Пе­ре­на­прав­ление SSH

Од­на из ути­лит SSH, ко­то­рой я поль­зу­юсь час­то – scp. Од­но из ее удобств – то, что она мо­жет ко­пи­ро­вать файл с од­но­го уда­лен­но­го хоста на­пря­мую на дру­гой. Так, со сво­его до­машнего нетбу­ка я мо­гу де­лать ре­зерв­ные ко­пии фай­лов жур­на­лов с од­но­го уда­лен­но­го сер­ве­ра на дру­гой, ко­ман­дой вро­де

$ scp admin@server2.remote.com:/var/log/server.log logkeeper@server3.remote.com:/backup/server.log.$(date+%Y%m%d)

Вме­сто ко­пи­ро­вания фай­ла на локаль­ный ком­пь­ю­тер и за­тем на уда­лен­ный сер­вер, эта ко­ман­да на­пря­мую ско­пи­ру­ет /var/log/server.log с сер­ве­ра server2.remote.com в ка­та­лог с ре­зерв­ны­ми ко­пия­ми на сер­ве­ре server3.remote.com и соз­даст со­от­вет­ст­вую­щие вре­мен­ные от­мет­ки.

Од­на­ко, по­про­бовав за­пустить эту ко­ман­ду, вы по­лу­чите сле­дую­щую ошиб­ку:

Permission denied, please try again.

Permission denied, please try again.

Permission denied (publickey,password).

lost connection

Она возника­ет по­то­му, что scp при за­пуске на локаль­ном ком­пь­ю­те­ре сна­ча­ла свя­зы­ва­ет­ся с server2.remote.com. Но так как мы ко­пи­ру­ем файл на тре­тий хост, scp так­же вы­зы­ва­ет вто­рую ко­ман­ду scp для ко­пи­ро­вания на server3.remote.com. Эта вто­рая ко­ман­да вы­да­ет ошиб­ку. Как и пер­вой, для под­клю­чения к server3.remote.com ей нуж­на па­роль­ная фра­за ва­ше­го за­кры­то­го клю­ча. Но поскольку на сер­ве­ре server3.remote.com нет ак­тив­но­го се­ан­са для за­про­са клю­че­вой фра­зы, она вы­да­ет ошиб­ку, что, в свою оче­редь, при­во­дит к неудач­но­му за­вер­шению и пер­вой ко­ман­ды scp.

Эту про­бле­му мож­но ре­шить, пе­ре­на­пра­вив server3.remote.com на ваш локаль­ный агент SSH на нетбу­ке.

Та­ким об­ра­зом, уда­лен­ный про­цесс scp про­сто свя­зы­ва­ет­ся с локаль­ным аген­том SSH, ау­тен­ти­фи­ци­ру­ет­ся, и безо­пас­ное ко­пи­ро­вание вы­пол­ня­ет­ся успеш­но. Этот про­цесс из­вес­тен как пе­ре­на­прав­ление аген­та.

Что­бы кли­ент SSH мог восполь­зо­вать­ся пе­ре­на­прав­лением аген­та, эту оп­цию нуж­но вклю­чить в фай­ле кон­фи­гу­ра­ции на локаль­ном ком­пь­ю­те­ре кли­ен­та, где за­пу­щен агент ssh. SSH по­лу­ча­ет дан­ные о кон­фи­гу­ра­ции пре­ж­де все­го из па­ра­мет­ров команд­ной стро­ки, за­тем из фай­ла кон­фи­гу­ра­ции поль­зо­ва­те­ля (обыч­но ~/.ssh/config), а за­тем из сис­тем­но­го фай­ла кон­фи­гу­ра­ции (обыч­но /etc/ssh/ssh_config). Что­бы ак­ти­ви­ро­вать пе­ре­на­прав­ление аген­тов, соз­дай­те или от­крой­те локаль­ный файл кон­фи­гу­ра­ции SSH (~/.ssh/config) и до­бавь­те в него сле­дую­щий па­ра­метр:

Host *

ForwardAgent yes

Он га­ран­ти­ру­ет, что под­клю­чение к аген­ту ау­тен­ти­фи­ка­ции бу­дет пе­ре­на­прав­ле­но на все уда­лен­ные хосты.

Когда пе­ре­на­прав­ление аген­тов ак­ти­ви­ро­ва­но, за­про­сы ау­тен­ти­фи­ка­ции SSH не пе­ре­на­прав­ля­ют­ся на­пря­мую локаль­но­му аген­ту SSH.

Вме­сто это­го пер­вый уда­лен­ный сер­вер (в дан­ном слу­чае server2.remote.com) вы­сту­па­ет в ка­че­­ст­ве вто­ро­го ssh-agent. Он принима­ет за­про­сы на ау­тен­ти­фи­ка­цию с третье­го сер­ве­ра и пе­ре­да­ет их по SSH-со­единению локаль­но­му аген­ту для об­ра­бот­ки, за­тем принима­ет ре­зуль­та­ты от локаль­но­го кли­ен­та и пе­ре­да­ет их на тре­тий сер­вер.

При­ятнее все­го то, что по­сле вклю­чения пе­ре­на­прав­ления аген­тов оно бу­дет ра­бо­тать для всех уда­лен­ных хостов, на ко­то­рых есть ваш от­кры­тый ключ. По­это­му фай­лы мож­но бу­дет ко­пи­ро­вать с третье­го сер­ве­ра на чет­вер­тый или пя­тый и т. д.

Когда все это на­строе­но, вам останет­ся лишь зай­ти в локаль­ный кли­ент и до­ба­вить клю­чи (с по­мо­щью ssh-add) уже за­пу­щен­но­му аген­ту ssh. За­тем он за­про­сит у вас па­роль­ные фра­зы для всех за­кры­тых клю­чей. По­сле это­го все опе­ра­ции по SSH на всех уда­лен­ных ком­пь­ю­те­рах, где есть ва­ши от­кры­тые клю­чи, бу­дут про­во­дить­ся без за­про­са па­роль­ной фра­зы.

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF155:%D0%97%D0%B0%C2%AD%D0%B4%D0%B0%C2%AD%D0%B2%D0%B0%D1%82%D1%8C_%D0%BA%D0%BB%D1%8E%C2%AD%D1%87%D0%B8_SSH&oldid=16565»
Персональные инструменты
купить
подписаться
Яндекс.Метрика