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

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

Материал из Linuxformat
Перейти к: навигация, поиск


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

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

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

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

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

Ма­янк Шар­ма – ав­тор книг по ад­ми­ни­ст­ри­ро­ва­нию Elgg и Openfire; он так­же че­ты­ре го­да был ре­дак­то­ром Linux.com.

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.

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

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

(thumbnail)
Одно из главных достоинств аутентификации с помощью ключей — то, что парольная фраза ключа 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-сер­вер ви­ден в Ин­тер­нет, обя­за­тель­но поль­зуй­тесь ау­тен­ти­фи­ка­ци­ей с по­мо­щью клю­чей вме­сто ис­поль­зо­ва­ния па­ро­ля.

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

Про­бле­мы безо­пас­но­сти с аген­та­ми клю­чей

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

Для под­клю­чения кли­ен­тов к SSH-аген­ту Open­SSH пре­достав­ля­ет до­мен­ный со­кет UNIX, доступ­ный толь­ко из локаль­ной фай­ло­вой сис­те­мы. Хо­тя этот со­кет на­деж­но за­щи­щен и доступ к нему есть толь­ко у поль­зо­ва­те­ля, от имени ко­то­ро­го вы­пол­ня­ет­ся про­цесс, ничто не по­ме­шать восполь­зо­вать­ся им от имени root.

Про­стая ко­ман­да

ls -l /tmp/ssh*

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

Ко­ман­дой

export SSH_AUTH_SOCK=<location of socket>

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

По­это­му важ­но от­клю­чать пе­ре­на­прав­ление аген­тов, ес­ли вы им не поль­зуе­тесь. Так­же сто­ит за­хо­дить по SSH под уда­лен­ным поль­зо­ва­те­лем с ог­раничен­ны­ми пра­ва­ми. Про­сто убе­ди­тесь, что уда­лен­ный поль­зо­ва­тель при­над­ле­жит груп­пе wheel, и вы мо­же­те стать поль­зо­ва­те­лем root.

Сле­дую­щий шаг – ско­пи­ро­вать от­кры­тый ключ на уда­лен­ный сер­вер. Ес­ли вы за­хо­ди­те на уда­лен­ный сер­вер 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, что­бы убе­дить­ся, что мы не до­ба­ви­ли лишних клю­чей.

Скорая помощь

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

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

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

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

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

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

Шаг за ша­гом: Соз­да­дим и ус­та­но­вим клю­чи с Seahorse

Соз­да­дим но­вый ключ 1. За­пусти­те Seahorse, вы­бе­ри­те пункт ме­ню File > Create New [Файл > Соз­дать] и вы­бе­ри­те пункт для соз­дания клю­ча SSH. Вве­ди­те опи­сание клю­ча. При же­лании мож­но из­менить тип шиф­ро­вания (RSA или DSA) и дли­ну клю­ча.

2. Ус­та­но­вим ключ

Те­перь на­жми­те на кноп­ку Create and Set Up [Соз­дать и уста­но­вить]. У вас cпроcят па­роль­ную фра­зу. По­сле соз­дания клю­ча будет пред­ло­жено вве­сти имя уда­лен­но­го ком­пь­ю­те­ра и имя поль­зо­ва­те­ля, ко­то­ро­му ско­пи­руется от­кры­тый ключ.

3 Управ­ля­ем клю­ча­ми

Спи­сок всех за­кры­тых клю­чей на­хо­дит­ся на вклад­ке My Personal Keys [Мои лич­ные клю­чи]. Для про­смот­ра ин­фор­ма­ции о клю­че и из­менения клю­че­вой фра­зы щелкните на нем пра­вой кноп­кой мы­ши и вы­бе­ри­те пункт ме­ню Properties [Свой­ст­ва]. Что­бы ско­пи­ро­вать от­кры­тый ключ на дру­гой ком­пь­ю­тер, вы­бе­ри­те Configure Key for Secure Shell [На­строй­ка клю­ча для безо­пас­ной обо­лоч­ки].

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

Ог­ра­ни­че­ние дос­ту­па

Не­за­ви­си­мо от ко­ли­че­­ст­ва ком­пь­ю­те­ров, с ко­то­ры­ми вы ра­бо­тае­те, всегда сто­ит ог­раничить доступ поль­зо­ва­те­ля­ми и хоста­ми, ко­то­рым вы до­ве­ряе­те. На­строй­ки сер­ве­ра OpenSSH мож­но из­менить в фай­ле /etc/ssh/sshd_config.

Для на­ча­ла за­пре­ти­те вход в сис­те­му от имени root. Всегда луч­ше за­хо­дить как обыч­ный поль­зо­ва­тель, ко­то­рый за­тем смо­жет пе­ре­клю­чить­ся на root. Что­бы за­пре­тить вход в сис­те­му под root, от­крой­те кон­фи­гу­ра­ци­он­ный файл, най­ди­те па­ра­метр PermitRootLogin, смените его зна­чение с ‘yes’ на ‘no’ и пе­ре­за­пусти­те сер­вис.

Что­бы еще луч­ше за­щи­тить сис­те­му от несанк­циониро­ван­но­го досту­па, за­дай­те спи­сок поль­зо­ва­те­лей, имею­щих пра­во под­клю­чать­ся по SSH. Ска­жем, вы хо­ти­те ог­раничить этот спи­сок толь­ко поль­зо­ва­те­ля­ми sam и chuck. Тогда до­бавь­те в конец фай­ла sshd_config стро­ку

AllowUsers sam chuck

Для ог­раничения SSH-досту­па за­дан­ны­ми хоста­ми мож­но соз­дать пра­ви­ло для сер­ви­са SSH в фай­лах управ­ления досту­пом к хостам. Спер­ва от­крой­те /etc/hosts.deny и соз­дай­те пра­ви­ло sshd: ALL, за­пре­щаю­щее доступ ко всем хостам.

Те­перь мож­но вы­брать хосты, с ко­то­рых раз­ре­ше­но со­единение: пра­ви­ло sshd: 192.168.1 201.130.177.13 в фай­ле /etc/hosts.allow раз­ре­шит доступ к хостам из се­ти 192.168.1.0/24 и с хоста201.130.177.13.


В 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 и соз­даст со­от­вет­ст­вую­щие вре­мен­ные от­мет­ки.

Скорая помощь

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

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

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 на всех уда­лен­ных ком­пь­ю­те­рах, где есть ва­ши от­кры­тые клю­чи, бу­дут про­во­дить­ся без за­про­са па­роль­ной фра­зы.

Персональные инструменты
купить
подписаться
Яндекс.Метрика