LINUX.ORG.RU

Первый выпуск открытого SSH-сервера Teleport

 , , teleport


1

2

Компания Gravitational объявила о доступности нового свободного SSH-пакета Gravitational Teleport (Teleport), предлагающего клиент и сервер SSH, оптимизированные для упрощения работы персонала, обслуживающего кластеры с большим числом узлов. Код проекта написан на языке Go и распространяется под лицензией Apache 2.0. Реализация SSH обратно совместима с OpenSSH и построена с использованием библиотеки Golang SSH.

Teleport пытается автоматизировать работу и повысить безопасность инфраструктур, в которых группам людей требуется доступ к различным серверам в кластере. Вместо применяемой в OpenSSH аутентификации по ключам, чтобы избежать необходимости копирования ключа каждого пользователя на узлы, в Teleport используются централизованные серверы аутентификации, выполняющие функции локального удостоверяющего центра (CA). При успешной аутентификации, для обеспечения входа сервер аутентификации генерирует временный сертификат, заверенный цифровой подписью CA. Достоверность узлов также подтверждается при помощи сертификата, подписанного CA.

Помимо проверки сертификата при каждом входе обязательно применяется двухфакторная аутентификация, требующая подтвердить намерение входа альтернативным путём (поддерживаются Google Apps и клиенты OAuth2). Не допускается прямое обращение к конечным узлам, для доступа требуется подключение через специальный прокси-сервер.

Другие особенности Teleport:

  • помимо традиционного интерфейса командной строки имеется возможность входа через HTTPS с эмуляцией терминала в веб-браузере;
  • поддержка функций аудита и повторения типовых операций — содержимое SSH-сеансов может записываться и при необходимости воспроизводиться на других хостах;
  • режим совместного решения проблем, при котором несколько человек могут совместно использовать один сеанс SSH;
  • автоматическое определение доступных рабочих серверов и контейнеров Docker в кластерах с динамическим присвоением имён хостам;
  • поддержка обратного туннелирования для подключения к кластерам, ограждённым межсетевым экраном;
  • возможность определения меток для наглядного разделения узлов кластера;
  • поддержка блокировки доступа после нескольких неудачных попыток входа;
  • сопоставление пользователей с логинами на конечных узлах осуществляется через специальные списки маппинга;
  • для подсоединения к хосту требуется указать два имени — имя кластера и имя узла в кластере. Teleport ориентирован на управление кластерами, а не отдельными серверами: для каждого пользователя и хоста определяется принадлежность к кластеру;
  • узлы подключаются к кластеру через определение статичестких или генерацию динамических токенов, которые при желании можно отозвать для запрета входа на данный узел;
  • для подсоединения к серверам Teleport внутри кластера можно использовать обычный клиент OpenSSH (требуется копирование ключей);
  • успешно пройден аудит безопасности кода, заказанный в независимой проверяющей компании.

>>> Подробности

★★★★★

Проверено: Falcon-peregrinus ()
Последнее исправление: Falcon-peregrinus (всего исправлений: 5)

Я так понимаю, для средней VPS оно не надо?

DeadEye ★★★★★
()

помимо традиционного интерфейса командной строки имеется возможность входа через HTTPS с эмуляцией терминала в веб-браузере;

Это годно. Интересно, а для обычного OpenSSH есть подобное?

Вообще, насколько мне известно, ни одна альтернатива OpenSSH не прижилась (массово) в итоге.

sT331h0rs3 ★★★★★
()

WOW! Вот это действительно круто! Годно и нужно!

Indexator ★★★
()

а поддерживает ли CA репликацию? А то если он один и упадет, то будет неприятненько-с

arcanis ★★★★
()

поддерживаются Google Apps

Больше зондов... и разных....

anc ★★★★★
()
Ответ на: комментарий от sT331h0rs3

Вообще, насколько мне известно, ни одна альтернатива OpenSSH не прижилась (массово) в итоге.

массово для embedded что то и прижилось.

но openssh хорошо да, правда я не в курсе, удалось ли им отказатся от openssl.

alwayslate ★★
()
Ответ на: комментарий от dr04

Это не альтернатива, оно работает вместе/поверх ssh.

entefeed ☆☆☆
()

И все же киллерфичи какие-то сомнительные. Центральный сервер аутентификации преподносится как основная, но это запросто делается и с обычным ssh через ldap/kerberos. Необходимость прокси-сервера для подключения вообще наркоманией попахивает. Остальное так, перделки и свистелки, половина из которых не нужна, а другая половина реализуется через openssh+костыли. Подозреваю не взлетит, но да пусть будет, может пригодится хоть кому.

двухфакторная аутентификация, требующая подтвердить намерение входа альтернативным путём (Google Apps)

Бгг.

entefeed ☆☆☆
()
Ответ на: комментарий от alwayslate

удалось ли им отказатся от openssl.

давно уже можно собрать без openssl.

val-amart ★★★★★
()

Вместо применяемой в OpenSSH аутентификации по ключам, чтобы избежать необходимости копирования ключа каждого пользователя на узлы, в Teleport используются централизованные серверы аутентификации, выполняющие функции локального удостоверяющего центра (CA). При успешной аутентификации, для обеспечения входа сервер аутентификации генерирует временный сертификат, заверенный цифровой подписью CA. Достоверность узлов также подтверждается при помощи сертификата, подписанного CA.

разработчики не слышали ни про ldap/kerberos, ни про ключи в днc, ни про аутентификацию по сертификатам. все это есть в опенссх

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

разработчики не слышали

Все они слышали, просто этап с плеерами прошел) Пришло время переписывать (+хайп) на го (+хайп)

nerfur ★★★
()
Ответ на: комментарий от nerfur

Все они слышали, просто этап с плеерами прошел) Пришло время переписывать (+хайп) на го (+хайп)


да
клиентам надо все 'искаропки'
и не важно, что это линукс
таких решений со временем будет все больше

kto_tama ★★★★★
()
Последнее исправление: kto_tama (всего исправлений: 1)
Ответ на: комментарий от kto_tama

клиентам надо все 'искаропки'
и не важно, что это линукс
таких решений со временем будет все больше

блаженны верующие, пока что я увидел лишь еще больше копий teleport --role на картинке, а не искаропки

nerfur ★★★
()
Ответ на: комментарий от val-amart

Это откуда в опенссх сертификаты? Был какой то форк одного еврея, который до сих пор лежит где то на хомпаге, а в майнстриме то откуда?

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

с 2011-го. только это не x.509, а свои собственные сертификаты. man ssh-keygen, секция CERTIFICATES. есть еще вот такое для автоматизации менеджмента https://github.com/cloudtools/ssh-cert-authority. это не считая проверки хостовых и пользовательских ключей в днс, например.

val-amart ★★★★★
()

А как же интересно я простым ssh ходил на ~300 хостов 5 лет назад? По-моему большую часть этого ssh умеет из коробки, а остальное прикручивается за день. Единственная причина использования этого софта - чтобы не включая мозг всё из коробки. Но вот как-то как longterm решение выглядит не солидно, так как авторы в предмете совсем не разобрались.

slapin ★★★★★
()
Ответ на: комментарий от val-amart

Но вся инфраструктура сертификатов за пределами ssh заточена на x509.

На предприятии по любому уже есть свой ca x509 сервер для https, для openvpn, для smtps, imaps итд

Где я смарткарты и usb токены возьму с хранением сертификатов ssh?

Так что я против всего этого.

AVL2 ★★★★★
()
Ответ на: комментарий от val-amart

А подскажите, когда я генерирую ключи утилитой ssh-keygen, она использует библиотеку openssl или у неё собственная реализация алгоритмов?

sunny1983 ★★★★★
() автор топика

помимо традиционного интерфейса командной строки имеется возможность входа через HTTPS с эмуляцией терминала в веб-браузере

Вот прям полноценный терминал с псевдографикой и мышевозностью?

Radjah ★★★★★
()
Ответ на: комментарий от AVL2

если есть такая жесткая необходимость именно в x509, на раз-два делается бридж для трансляции одного в другое. у нас именно так и есть.

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

Допустим самый простой 2048-битный RSA. Интересуюсь потому, что сейчас решил глубоко копнуть тему прикладной криптографии, а именно попробовать практически порешать задачи, выполняемые с помощью одного по, через другое по.

sunny1983 ★★★★★
() автор топика
Ответ на: комментарий от val-amart

А почему тогда OpenSSL генерит ключи в форматах DER, NET, PEM, а ssh-keygen создаёт в собственном формате?

sunny1983 ★★★★★
() автор топика
Ответ на: комментарий от val-amart

Автоматизация менеджмента через SSH. Системное администрирование уровня LOR.

anonymous
()
Ответ на: комментарий от val-amart

А можно какие нибудь подсказки, как это делается?

Еще раз, речь не о том, чтобы автоматом на основе x509 генерить свой собственный сертификат для openssh, а о том, как дать возможность пользователю с помощью своего рабочего x509 сертификата логиниться на сервер по ssh. Сертификат-то у пользователя на токене.

AVL2 ★★★★★
()

возможность входа через HTTPS с эмуляцией терминала в веб-браузере

мама, я знаю, мы все сошли с ума (c)

Croco ★★★
()
Ответ на: комментарий от vertexua

Ну очевидно TXT запись в ДНС с отпечатком ключа хоста, чтобы избегать вопросов при первом коннекте, мол, доверяешь или не доверяешь. Часть того, что обеспечивает сертификат.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Не надо никого заставлять ставить PuTTY, даже если нет веб-клиента. Пусть пользуются консольным клиентом в десяточке.

anonymous
()
Ответ на: комментарий от AVL2

Это наверняка и без всякого Телепорта реализовать можно (я имею в виду консоль в браузере), php-скриптом, наверняка что-то подобное существует.
Да, я тут выше задавал вопрос, если openssh использует openssl - то почему не использует ключи в формате pem?

sunny1983 ★★★★★
() автор топика
Ответ на: комментарий от sunny1983

Да, я тут выше задавал вопрос, если openssh использует openssl - то почему не использует ключи в формате pem?

Как это не использует?

→ file .ssh/id_rsa
.ssh/id_rsa: PEM RSA private key

А публичные в одну строчку - чтобы было удобно вставлять в authorized_keys и удалять из known_hosts.

ei-grad ★★★★★
()
Ответ на: комментарий от AVL2

Почему? Если у всех клиентов есть браузер, то можно не заставлять их ставить еще и putty...

Если человек готов использовать браузер для удалённого доступа по ssh, то такого человека нельзя подпускать к серверам на пушечный выстрел.

Croco ★★★
()
Ответ на: комментарий от Croco

Помолчи, старпер. Своё альтернативное видение техологий будешь втирать своим бедным студентам.

anonymous
()
Ответ на: комментарий от sunny1983

Это наверняка и без всякого Телепорта реализовать можно (я имею в виду консоль в браузере), php-скриптом, наверняка что-то подобное существует.

Да, но в таких делах гораздо удобнее развернуть один сервис и получить все необходимое сразу, а не отдельно ставить ссх, вебсервер, пхп и терминал, а потом все это скрещивать с риском получить дыру в безопасности размером со вселенную. Или прореху...

Да, я тут выше задавал вопрос, если openssh использует openssl - то почему не использует ключи в формате pem?

Потому что опенссх, это NIH во все поля. Свои сраные сертификаты вместо openssl, свой сраный формат для обычных ключей. Свой агент аутентификации вместо стандартного брелка и так далее.

Тут нет вопроса. Все что только можно было сделать несовместимо так и сделано.

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

Но не у всехесть десяточка. И наверняка и в ней его надостваить отдельно. А браузер уже есть везде - на планшетах, в телефонах и на компах и везде это одно и тоже - браузер.

AVL2 ★★★★★
()
Ответ на: комментарий от Croco

Это голобальный тренд - пускать таких людей всюду, куда раньше их не пускали.

Просто потому что таких людей много, они легко взаимозаменяемы и недорого берут за свою работу.

Так что если ты собрался ссать против ветра перемен или еще как нибудь воевать с ветряными мельницами, то дело это хоть и сугубо твое, но все равно безнадежно гиблое...

AVL2 ★★★★★
()
Ответ на: комментарий от sunny1983

Да, я тут выше задавал вопрос, если openssh использует openssl - то почему не использует ключи в формате pem?

openssh умеет просто свои контейнеры для ключей.

alwayslate ★★
()
Ответ на: комментарий от ei-grad

→ file .ssh/id_rsa .ssh/id_rsa: PEM RSA private key

Где вы это взяли? Я заглянул в свои ключи: в закрытом ключе никаких данных о формате контейнера нет, просто последовательность символов между строками "-----BEGIN RSA PRIVATE KEY-----" и "-----END RSA PRIVATE KEY-----", открытый ключ более информативный, в нём есть информация о хосте и пользователе.

openssh умеет просто свои контейнеры для ключей.

Я не понял, «умеет свои контейнеры» или «использует только свои контейнеры»?

Все что только можно было сделать несовместимо так и сделано.

Я так понял в прикладной криптографии принципа совместимости вообще нет. Алгоритмы везде одни и те же, но формат контейнера разработчики каждой программы стремятся изобрести свой: у OpenSSH он один, у putty - другой, у OpenSSL - третий. Разработчики систем электронного документооборота с ГОСТовским шифрованием предпочитают использовать проприетарные продукты вроде Крипто-Про, я эту тему решил копнуть на неделе, так вот сотрудники техподдержки этих систем утверждают, что вообще не в курсе что такое OpenSSL.

sunny1983 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.