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

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

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
Строка 21: Строка 21:
 
И здесь кроется боль­шая про­бле­ма. Вы под­клю­чае­тесь к уда­лен­но­му ком­пь­ю­те­ру толь­ко по­сле руч­но­го вво­да па­ро­ля.
 
И здесь кроется боль­шая про­бле­ма. Вы под­клю­чае­тесь к уда­лен­но­му ком­пь­ю­те­ру толь­ко по­сле руч­но­го вво­да па­ро­ля.
  
−
Боль­шая про­бле­ма
+
==Боль­шая про­бле­ма==
  
 
Пред­по­ло­жим, на локаль­ном ком­пь­ю­те­ре у вас есть за­дание cron, еже­час­но за­пускаю­щее скрипт, ко­то­рый ко­пи­ру­ет с уда­лен­но­го сер­ве­ра па­ру фай­лов. И при ка­ж­дой по­пыт­ке скрип­та свя­зать­ся с уда­лен­ным ком­пь­ю­те­ром у него за­про­сят па­роль. Это ис­клю­ча­ет ис­поль­зо­вание SSH для за­дач, ко­то­рые долж­ны вы­пол­нять­ся без ва­ше­го уча­стия. Или нет?
 
Пред­по­ло­жим, на локаль­ном ком­пь­ю­те­ре у вас есть за­дание cron, еже­час­но за­пускаю­щее скрипт, ко­то­рый ко­пи­ру­ет с уда­лен­но­го сер­ве­ра па­ру фай­лов. И при ка­ж­дой по­пыт­ке скрип­та свя­зать­ся с уда­лен­ным ком­пь­ю­те­ром у него за­про­сят па­роль. Это ис­клю­ча­ет ис­поль­зо­вание SSH для за­дач, ко­то­рые долж­ны вы­пол­нять­ся без ва­ше­го уча­стия. Или нет?
Строка 29: Строка 29:
 
Вдо­ба­вок SSH не слиш­ком хо­ро­шо мас­шта­би­ру­ет­ся. Ес­ли у вас несколь­ко учет­ных за­пи­сей на раз­ных ком­пь­ю­те­рах се­ти, за­помнить уникаль­ные слож­ные па­ро­ли для ка­ж­до­го из них бу­дет невоз­мож­но.
 
Вдо­ба­вок SSH не слиш­ком хо­ро­шо мас­шта­би­ру­ет­ся. Ес­ли у вас несколь­ко учет­ных за­пи­сей на раз­ных ком­пь­ю­те­рах се­ти, за­помнить уникаль­ные слож­ные па­ро­ли для ка­ж­до­го из них бу­дет невоз­мож­но.
  
−
Ключ к ре­шению про­бле­мы
+
==Ключ к ре­шению про­бле­мы==
  
 
Для ре­шения этой про­бле­мы нуж­но из­менить ис­поль­зуе­мый по умол­чанию ме­ханизм ау­тен­ти­фи­ка­ции. В OpenSSH есть раз­лич­ные ме­ханиз­мы ау­тен­ти­фи­ка­ции, и один из них осно­ван на клю­чах, а не на па­ро­лях. К то­му же он са­мый на­деж­ный. По умол­чанию OpenSSH ис­поль­зу­ет клю­чи для ау­тен­ти­фи­ка­ции под­лин­но­сти сер­ве­ра в пер­вый раз при под­клю­чении кли­ен­та к но­во­му уда­лен­но­му ком­пь­ю­те­ру:
 
Для ре­шения этой про­бле­мы нуж­но из­менить ис­поль­зуе­мый по умол­чанию ме­ханизм ау­тен­ти­фи­ка­ции. В OpenSSH есть раз­лич­ные ме­ханиз­мы ау­тен­ти­фи­ка­ции, и один из них осно­ван на клю­чах, а не на па­ро­лях. К то­му же он са­мый на­деж­ный. По умол­чанию OpenSSH ис­поль­зу­ет клю­чи для ау­тен­ти­фи­ка­ции под­лин­но­сти сер­ве­ра в пер­вый раз при под­клю­чении кли­ен­та к но­во­му уда­лен­но­му ком­пь­ю­те­ру:
Строка 49: Строка 49:
 
За­кры­тый ключ досту­пен толь­ко вам и ис­поль­зу­ет­ся кли­ен­том OpenSSH для под­твер­ждения ва­шей под­лин­но­сти сер­ве­рам. Так­же есть от­кры­тый ключ, ко­то­рый, в со­от­вет­ст­вии со сво­им на­званием, на­хо­дит­ся в от­кры­том досту­пе. Вы долж­ны раз­мес­тить его на всех сво­их учет­ных за­пи­сях на уда­лен­ных ком­пь­ю­те­рах, к ко­то­рым намерены под­клю­чать­ся по SSH.
 
За­кры­тый ключ досту­пен толь­ко вам и ис­поль­зу­ет­ся кли­ен­том OpenSSH для под­твер­ждения ва­шей под­лин­но­сти сер­ве­рам. Так­же есть от­кры­тый ключ, ко­то­рый, в со­от­вет­ст­вии со сво­им на­званием, на­хо­дит­ся в от­кры­том досту­пе. Вы долж­ны раз­мес­тить его на всех сво­их учет­ных за­пи­сях на уда­лен­ных ком­пь­ю­те­рах, к ко­то­рым намерены под­клю­чать­ся по SSH.
  
−
Соз­дание клю­ча
+
==Соз­дание клю­ча==
  
 
При уста­нов­ке со­единения с по­мо­щью клю­чей ком­пь­ю­те­ры об­ща­ют­ся друг с дру­гом не так, как при ау­тен­ти­фи­ка­ции по па­ро­лю. При под­клю­чении к уда­лен­но­му ком­пь­ю­те­ру ва­ше­го кли­ен­та уда­лен­ный ком­пь­ю­тер соз­да­ет за­прос с по­мо­щью ва­ше­го от­кры­то­го клю­ча. Кли­ент принима­ет за­прос и от­ве­ча­ет на него на осно­ве ва­ше­го за­кры­то­го клю­ча.
 
При уста­нов­ке со­единения с по­мо­щью клю­чей ком­пь­ю­те­ры об­ща­ют­ся друг с дру­гом не так, как при ау­тен­ти­фи­ка­ции по па­ро­лю. При под­клю­чении к уда­лен­но­му ком­пь­ю­те­ру ва­ше­го кли­ен­та уда­лен­ный ком­пь­ю­тер соз­да­ет за­прос с по­мо­щью ва­ше­го от­кры­то­го клю­ча. Кли­ент принима­ет за­прос и от­ве­ча­ет на него на осно­ве ва­ше­го за­кры­то­го клю­ча.
Строка 76: Строка 76:
  
 
Клю­чи луч­ше хранить в ка­та­ло­ге по умол­чанию, ес­ли нет вес­ких при­чин хранить их в дру­гом мес­те. Так­же обя­за­тель­но за­дай­те па­роль­ную фра­зу.
 
Клю­чи луч­ше хранить в ка­та­ло­ге по умол­чанию, ес­ли нет вес­ких при­чин хранить их в дру­гом мес­те. Так­же обя­за­тель­но за­дай­те па­роль­ную фра­зу.
 +
{{Врезка|right|Заголовок= Скорая помощь|Ширина=15%|Содержание= Ес­ли ваш SSH-сер­вер ви­ден в Ин­тер­нет, обя­за­тель­но поль­зуй­тесь ау­тен­ти­фи­ка­ци­ей с по­мо­щью клю­чей вме­сто ис­поль­зо­ва­ния па­ро­ля.}}
  
 
За­тем ssh-keygen соз­даст локаль­ный ка­та­лог SSH (~/.ssh), ес­ли его нет, и со­хранит за­кры­тую и от­кры­тую час­ти клю­ча в двух фай­лах в этом ка­та­ло­ге. По умол­чанию это фай­лы с име­на­ми id_rsa и id_rsa.pub. Файл id_rsa досту­пен для чтения толь­ко ва­ше­му поль­зо­ва­те­лю, а его со­дер­жи­мое до­полнитель­но за­щи­ще­но пу­тем шиф­ро­вания с па­роль­ной фра­зой, за­дан­ной ва­ми при генера­ции клю­ча.
 
За­тем ssh-keygen соз­даст локаль­ный ка­та­лог SSH (~/.ssh), ес­ли его нет, и со­хранит за­кры­тую и от­кры­тую час­ти клю­ча в двух фай­лах в этом ка­та­ло­ге. По умол­чанию это фай­лы с име­на­ми id_rsa и id_rsa.pub. Файл id_rsa досту­пен для чтения толь­ко ва­ше­му поль­зо­ва­те­лю, а его со­дер­жи­мое до­полнитель­но за­щи­ще­но пу­тем шиф­ро­вания с па­роль­ной фра­зой, за­дан­ной ва­ми при генера­ции клю­ча.
 +
 +
{{Врезка|left|Заголовок= Про­бле­мы безо­пас­но­сти с аген­та­ми клю­чей|Ширина=98%|Содержание=Ес­ли вы хо­ти­те управ­лять несколь­ки­ми ком­пь­ю­те­ра­ми и вы­пол­нять на них ка­кие-то опе­ра­ции, не тре­бую­щие уча­стия поль­зо­ва­те­ля, очень удоб­ны аген­ты клю­чей 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’, мо­же­те пе­ре­мес­тить клю­чи од­ной ко­ман­дой:
 
Сле­дую­щий шаг – ско­пи­ро­вать от­кры­тый ключ на уда­лен­ный сер­вер. Ес­ли вы за­хо­ди­те на уда­лен­ный сер­вер server2.remote.com как поль­зо­ва­тель ‘admin’, мо­же­те пе­ре­мес­тить клю­чи од­ной ко­ман­дой:
Строка 90: Строка 109:
  
 
и за­гляните в файл ~/.ssh/authorized_keys, что­бы убе­дить­ся, что мы не до­ба­ви­ли лишних клю­чей.
 
и за­гляните в файл ~/.ssh/authorized_keys, что­бы убе­дить­ся, что мы не до­ба­ви­ли лишних клю­чей.
−
 
+
{{Врезка|left|Заголовок= Скорая помощь|Ширина=15%|Содержание=Со­ве­ту­ем за­да­вать па­роль­ную фра­зу дли­ной не ме­нее 15 сим­во­лов, с про­бе­ла­ми и спец­сим­во­ла­ми. Же­ла­тель­но, что­бы она не бы­ла грам­ма­ти­че­ским пред­ло­же­ни­ем. }}
 
У вас за­про­сят па­роль­ную фра­зу для за­кры­то­го клю­ча. За­тем от­кры­тый ключ ав­то­ма­ти­че­­ски пе­ре­мес­тит­ся в соответ­ствующее ме­сто на уда­лен­ном сер­ве­ре. Ес­ли ад­минист­ра­тор уда­лен­но­го сер­ве­ра не изме­нял на­строй­ки OpenSSH, ваш ключ бу­дет до­бав­лен в файл ~/.ssh/authorized_keys.
 
У вас за­про­сят па­роль­ную фра­зу для за­кры­то­го клю­ча. За­тем от­кры­тый ключ ав­то­ма­ти­че­­ски пе­ре­мес­тит­ся в соответ­ствующее ме­сто на уда­лен­ном сер­ве­ре. Ес­ли ад­минист­ра­тор уда­лен­но­го сер­ве­ра не изме­нял на­строй­ки OpenSSH, ваш ключ бу­дет до­бав­лен в файл ~/.ssh/authorized_keys.
  
Строка 97: Строка 116:
 
С ви­ду разница лишь в том, что вме­сто па­ро­ля уда­лен­но­го поль­зо­ва­те­ля вы ука­зы­вае­те па­роль­ную фра­зу за­кры­то­го клю­ча. Но как мы уже объ­яс­ня­ли, внут­ри уда­лен­ный сер­вер и кли­ент про­ве­ря­ют ва­шу под­лин­ность по клю­чам на осно­ве слож­ных ма­те­ма­ти­че­­ских вы­чис­лений, без пе­ре­да­чи па­ро­ля.
 
С ви­ду разница лишь в том, что вме­сто па­ро­ля уда­лен­но­го поль­зо­ва­те­ля вы ука­зы­вае­те па­роль­ную фра­зу за­кры­то­го клю­ча. Но как мы уже объ­яс­ня­ли, внут­ри уда­лен­ный сер­вер и кли­ент про­ве­ря­ют ва­шу под­лин­ность по клю­чам на осно­ве слож­ных ма­те­ма­ти­че­­ских вы­чис­лений, без пе­ре­да­чи па­ро­ля.
  
−
Ук­ре­пим за­щи­ту
+
==Ук­ре­пим за­щи­ту==
  
 
Раз уж мы за­ве­ли клю­чи, для пу­щей безо­пас­но­сти сто­ит пол­но­стью от­клю­чить па­роль­ную ау­тен­ти­фи­ка­цию. Для это­го от­крой­те файл на­строй­ки сер­ве­ра (обыч­но /etc/ssh/.sshd_config) и из­мените зна­чение па­ра­мет­ра PasswordAuthentication с ‘yes’ на ‘no’.
 
Раз уж мы за­ве­ли клю­чи, для пу­щей безо­пас­но­сти сто­ит пол­но­стью от­клю­чить па­роль­ную ау­тен­ти­фи­ка­цию. Для это­го от­крой­те файл на­строй­ки сер­ве­ра (обыч­но /etc/ssh/.sshd_config) и из­мените зна­чение па­ра­мет­ра PasswordAuthentication с ‘yes’ на ‘no’.
 +
{{Врезка|left|Заголовок= Шаг за ша­гом: Соз­да­дим и ус­та­но­вим клю­чи с Seahorse|Ширина=98%|Содержание= Соз­да­дим но­вый ключ
 +
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 на несколь­ко уда­лен­ных ком­пь­ю­те­ров, где есть ваш от­кры­тый ключ. Это из­бав­ля­ет вас от необ­хо­ди­мо­сти помнить ку­чу па­ро­лей, но за­пуск скрип­тов по-прежнему бу­дет пре­ры­вать­ся за­про­сом па­роль­ной фра­зы.
 
Клю­чи ре­ши­ли нам од­ну серь­ез­ную про­бле­му: те­перь с од­ной па­роль­ной фра­зой мож­но под­клю­чать­ся по SSH на несколь­ко уда­лен­ных ком­пь­ю­те­ров, где есть ваш от­кры­тый ключ. Это из­бав­ля­ет вас от необ­хо­ди­мо­сти помнить ку­чу па­ро­лей, но за­пуск скрип­тов по-прежнему бу­дет пре­ры­вать­ся за­про­сом па­роль­ной фра­зы.
 +
{{Врезка|left|Заголовок= Ог­ра­ни­че­ние дос­ту­па|Ширина=98%|Содержание= Не­за­ви­си­мо от ко­ли­че­­ст­ва ком­пь­ю­те­ров, с ко­то­ры­ми вы ра­бо­тае­те, всегда сто­ит ог­раничить доступ поль­зо­ва­те­ля­ми и хоста­ми, ко­то­рым вы до­ве­ряе­те. На­строй­ки сер­ве­ра 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 не бу­дут за­пра­ши­вать у вас клю­че­вые фра­зы, а возь­мут ин­фор­ма­цию у аген­та.
 
В OpenSSH есть ути­ли­та ssh-agent, ко­то­рая хранит ва­ши за­кры­тые клю­чи в па­мя­ти. Вам нуж­но толь­ко за­пустить аген­та и пе­ре­дать ему свои за­кры­тые клю­чи. Ес­ли агент за­пу­щен, кли­ен­ты SSH не бу­дут за­пра­ши­вать у вас клю­че­вые фра­зы, а возь­мут ин­фор­ма­цию у аген­та.
Строка 135: Строка 180:
 
Это по­хо­же на ко­ман­ду ssh-add. Агент Seahorse за­пра­ши­ва­ет у вас па­роль и по­зво­ля­ет со­хранить па­ро­ли в gnome-keyring. За­тем он от­ве­ча­ет на все по­сле­дую­щие за­про­сы клю­чей SSH.
 
Это по­хо­же на ко­ман­ду ssh-add. Агент Seahorse за­пра­ши­ва­ет у вас па­роль и по­зво­ля­ет со­хранить па­ро­ли в gnome-keyring. За­тем он от­ве­ча­ет на все по­сле­дую­щие за­про­сы клю­чей SSH.
  
−
Пе­ре­на­прав­ление SSH
+
==Пе­ре­на­прав­ление SSH==
  
 
Од­на из ути­лит SSH, ко­то­рой я поль­зу­юсь час­то – scp. Од­но из ее удобств – то, что она мо­жет ко­пи­ро­вать файл с од­но­го уда­лен­но­го хоста на­пря­мую на дру­гой. Так, со сво­его до­машнего нетбу­ка я мо­гу де­лать ре­зерв­ные ко­пии фай­лов жур­на­лов с од­но­го уда­лен­но­го сер­ве­ра на дру­гой, ко­ман­дой вро­де
 
Од­на из ути­лит SSH, ко­то­рой я поль­зу­юсь час­то – scp. Од­но из ее удобств – то, что она мо­жет ко­пи­ро­вать файл с од­но­го уда­лен­но­го хоста на­пря­мую на дру­гой. Так, со сво­его до­машнего нетбу­ка я мо­гу де­лать ре­зерв­ные ко­пии фай­лов жур­на­лов с од­но­го уда­лен­но­го сер­ве­ра на дру­гой, ко­ман­дой вро­де
Строка 142: Строка 187:
  
 
Вме­сто ко­пи­ро­вания фай­ла на локаль­ный ком­пь­ю­тер и за­тем на уда­лен­ный сер­вер, эта ко­ман­да на­пря­мую ско­пи­ру­ет /var/log/server.log с сер­ве­ра server2.remote.com в ка­та­лог с ре­зерв­ны­ми ко­пия­ми на сер­ве­ре server3.remote.com и соз­даст со­от­вет­ст­вую­щие вре­мен­ные от­мет­ки.
 
Вме­сто ко­пи­ро­вания фай­ла на локаль­ный ком­пь­ю­тер и за­тем на уда­лен­ный сер­вер, эта ко­ман­да на­пря­мую ско­пи­ру­ет /var/log/server.log с сер­ве­ра server2.remote.com в ка­та­лог с ре­зерв­ны­ми ко­пия­ми на сер­ве­ре server3.remote.com и соз­даст со­от­вет­ст­вую­щие вре­мен­ные от­мет­ки.
−
 
+
{{Врезка|right|Заголовок=Скорая помощь |Ширина=20%|Содержание=Ес­ли вы ко­пи­руе­те клю­чи вруч­ную, по­за­боть­тесь, что­бы уда­лен­ный ка­та­лог SSH и со­от­вет­ст­вую­щие фай­лы бы­ди дос­туп­ны на за­пись толь­ко из ва­шей учет­ной за­пи­си.}}
 
Од­на­ко, по­про­бовав за­пустить эту ко­ман­ду, вы по­лу­чите сле­дую­щую ошиб­ку:
 
Од­на­ко, по­про­бовав за­пустить эту ко­ман­ду, вы по­лу­чите сле­дую­щую ошиб­ку:
  

Версия 12:09, 26 июня 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.

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

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

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

247931.png

Источник — «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=16476»
Персональные инструменты
купить
подписаться
Яндекс.Метрика