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

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

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

Но жизнь на мес­те не сто­ит, и коман­да OpenSSH уже нес­коль­ко лет назад пред­ста­вила новые мощ­ные инс­тру­мен­ты SSH, которые дают боль­шую гиб­кость и удобс­тво уда­лен­ного адми­нис­три­рова­ния, осо­бен­но если у сисад­мина в управле­нии мно­го уда­лен­ных сер­веров. Один из таких инс­тру­мен­тов — сер­тифика­ты SSH. Хотя они про­ще обыч­ных сер­тифика­тов x509, почему‑то их про­ник­новение в уда­лен­ное адми­нис­три­рова­ние идет туго. Видимо, ска­зыва­ется инер­ция мыш­ления. А ведь что может быть кра­сивее и удоб­нее: ты выпус­каешь кор­невой сер­тификат CA, который и заг­ружа­ешь на сер­вер. Всё, имея SSH-сер­тификат, удос­товерен­ный этим СА, ты можешь заходить на уда­лен­ный сер­вер. А далее рас­смот­рим нюан­сы, которые могут сде­лать жизнь сисад­мина — не в ущерб безопас­ности — лег­че и при­ятнее.

Итак, соз­дадим наш CA. Для при­мера пусть это будет клю­чевая пара, в которой исполь­зует­ся схе­ма циф­ровой под­писи типа Ed25519. С лег­кой руки аме­рикан­ско­го крип­тогра­фа Брю­са Шнай­ера сре­ди мно­гих крип­тогра­фов утверди­лось стой­кое подоз­рение, что Агентство наци­ональ­ной безопас­ности США (NSA) сде­лало зак­ладку в стан­дарти­зован­ную Национальным инсти­тутом стан­дартов и тех­нологий США (NIST) эллипти­чес­кую кри­вую P-256. Мы не можем знать навер­няка, так ли это. Но этот пред­полага­емый backdoor потен­циаль­но ста­вит безопас­ность ком­муника­ций под угро­зу. И тут очень кста­ти приш­лась раз­работан­ная про­фес­сором Дэни­елом Дж. Берн­штей­ном эллипти­чес­кая кри­вая Curve25519. Она счи­тает­ся безопас­ной. По край­ней мере, ник­то из серь­езных крип­тогра­фов нас­чет этой кри­вой сом­нений не выражал. Вот и будем с ней работать даль­ше.

Ге­нери­руем пару клю­чей для CA по извес­тной стан­дар­тной про­цеду­ре (не леним­ся, уста­нав­лива­ем пароль — здесь и далее):

$ ssh-keygen -C CA -t ed25519 -f ca_key

По­луча­ем два фай­ла: ca_key и ca_key.pub. Они и обра­зуют наш CA. Зак­рытый ключ ca_key пря­чем в надеж­ном мес­те, а откры­тый ключ ca_key.pub помеща­ем на уда­лен­ном сер­вере в /etc/ssh/ca_key.pub и даем сер­веру коман­ду доверять всем клю­чам, под­писан­ным этим CA, добавив в кон­фигура­цион­ный файл сер­вера /etc/ssh/sshd_config такую стро­ку:

TrustedUserCAKeys /etc/ssh/ca_key.pub

А пос­коль­ку ранее мы положи­лись на кри­вую Curve25519, то добав­ляем в файл еще и такие стро­ки:

PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.comCASignatureAlgorithms ssh-ed25519

Не забыва­ем перезаг­рузить SSH-сер­вер пос­ле каж­дого изме­нения кон­фигура­ции (здесь и далее):

$ sudo systemctl restart ssh.service

Да­лее по дав­но отра­ботан­ному шаб­лону генери­руем пару поль­зователь­ских клю­чей для аутен­тифика­ции на сер­вере:

$ ssh-keygen -t ed25519 -f id_ed25519

и под­писыва­ем откры­тый ключ поль­зовате­ля id_ed25519.pub:

$ ssh-keygen -s ca_key -I alex25 -n root id_ed25519.pub

В резуль­тате получа­ем собс­твен­но сер­тификат поль­зовате­ля: id_ed25519-cert.pub.

Оп­ция -I — это иден­тифика­тор клю­ча, он может быть любой циф­ро‑бук­венной стро­кой, но луч­ше ее инди­виду­али­зиро­вать, что­бы понимать, кто, ког­да и куда с таким иден­тифика­тором вхо­дил на сер­вер, так как в логах ID клю­ча всег­да ука­зыва­ется.

Оп­ция -n зада­ет прин­ципала (о них ниже), в дан­ном слу­чае это root. Пред­став­ленная схе­ма сер­тифика­та самая прос­тая, а потому не самая безопас­ная. Она поз­воля­ет вла­дель­цу такого клю­ча вхо­дить ког­да угод­но и отку­да угод­но на любой сер­вер, доверя­ющий дан­ному CA, с пра­вами root без каких‑либо огра­ниче­ний, а это пло­хо.

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

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Я уже участник «Xakep.ru»

Источник