company_banner

Поддержка ssh-ключей пользователя в облаке

    Новость одной строкой: мы реализовали возможность установки облачного сервера с автоматическим добавлением root в authorized_keys указанного при установке публичного ssh-ключа.



    Минимальный метод использования — выбрать ключ при установке/переустановке:

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

    Заметим, по-умолчанию машина ставится без ключа, но есть возможность указать, какой ключ использовать по-умолчанию.

    Если у вас есть несколько ключей, то ими можно управлять. Всего управления — удалить, изменить описание и пометить ключ как «предпочтительный».

    Разумеется, в любой момент «запомненный» ключ можно удалить из списка.

    Простая часть на этом заканчивается. А дальше начинаются нюансы.

    Во-первых, в отличие от многих сервисов мы ключ полностью валидируем. И на этапе JS, и на серверной стороне. Что во-первых спасает от распространённой ошибки — загрузки приватного ключа вместо публичного, а во-вторых гарантирует, что ключ — это ключ.

    Вот так вот выглядит удачно предотвращённое разглашение приватного ssh-ключа — мы его отвергаем ещё на уровне JS, до того, как отправляем на сервер и таким образом не компрометируем его:


    Во-вторых мы записываем ключ установки в свойства виртуальной машины (поле «ключ при установке», рядом с паролем при установке).

    Мы показываем его «хвостик» (описание), но если по нему кликнуть, покажем сам ключ целиком.


    И, главное: мы проверяем, что ключ виртуальной машины пользователю известен. Если машина поставлена с ключом, который пользователь не добавлял в «свои» (такое может быть при передаче сервера с аккаунта на аккаунт) или пользователь ключ удалил, то мы показываем предупреждение.

    Более того, мы откажемся переустанавливать виртуальную машину с неизвестным ключом. Это гарантирует, что владелец машины точно знает, что делает и доверяет владельцу ключа кликнул «добавить» на соответствующей странице.

    Библиотеки для работы с SSH-ключами


    Наш сервер API написан на Haskell, веб-интерфейс на JS (ваш капитан). Ни в Хаскеле, ни в JS мы не нашли готовой библиотеки для валидации ключей. Наши программисты: knsd и rocco66 потратили немного времени и написали своё.


    Для чего нужны ssh-ключи?


    (раздел для не-сисадминов)

    SSH-ключ позволяет заходить на серверы без ввода пароля. Приватный ключ хранится у пользователя на компьютере (под паролем или без), публичный — загружается на сервер. После этого, при подключении к серверу приложение (ssh-клиент) доказывает серверу, что у него есть приватный ключ (сам приватный ключ при этом не передаётся), соответствующий загруженному публичному ключу. Если всё ок, то пользователь оказывается на сервере.

    В бытовом смысле это много удобнее, не говоря уже про автоматизацию удалённого выполнения команд.

    Для Linux/FreeBSD и MacOS X ключ генерируется в консоли командой ssh-keygen (открытый ключ после этого можно скопировать из ~/.ssh/id_rsa.pub). Для Windows в утилите PyTTY его так же можно сгенерировать и использовать: habrahabr.ru/post/39254.

    Практически использование ключа сводится к наличию файла ~/.ssh/id_rsa, после этого достаточно набрать root@habrahabr.ru и вы окажетесь на сервере habrahabr.ru c правами рута. При условии, что ваш публичный ключ лежит на сервере в каталоге /root/.ssh/authorized_keys, разумеется.
    Selectel
    151,00
    ИТ-инфраструктура для бизнеса
    Поделиться публикацией

    Комментарии 11

      –6
      Почему присоединяете к root, а не создаете нового пользователя?
        +8
        … И даём этому пользователю sudo? А sudo c паролем или без? Если без пароля, то в чём «повышенная безопасность»? Если с паролем, то удобство от ключей, мягко говоря, спорное, потому что придётся идти и копипастить пароль как и раньше.

        Никто не мешает на созданной машине добавить пользователя, дать ему нужные права и отключить рута или ограничить его только консолью.
          –4
          Я совсем не в тему повешенной безопасности. Я про удобство.

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

          Вот именно избавиться от этого.
            +9
            Но какого пользователя мы должны создавать? И должны ли мы доставлять sudo в дистрибутивы, где этого пакета нет по умолчанию? И должен ли sudo спрашивать пароль?

            Я предпочитаю либо делать целиком managed сервис, либо не трогать эти вопросы вообще. Полу-решения в этих вопросах хуже, чем полностью отданное на откуп пользователю.
            +2
            Помнится, за подобный ответ меня жестко заминусовали. Потому что я спросил у кого-то: в чем сакральная безопасность четырех букв и пробела. С тех пор у меня нет прав на хабре, кроме коммента раз в 15 минут :-) Так что я стараюсь больше умного ничего не писать. Вдруг не поймут. Тупое писать не хочу. Приходится не писать ничего. :-)
              +1
              Если вы про sudo, то у sudo без пароля при запрещённом логине пользователя есть одна простая польза — подбирать нужно будет ещё и username.

              А в многопользовательской среде sudo даёт понимание, кто что сломал. Не защиту, но кооперативное сотрудничество, разумеется.

              Нормально sudo спасает только при доп.авторизации. Например, у меня на ноутбуке sudo требует отпечаток пальца. При этом для логин в систему нужно вводить пароль (им зашифрован home), а пальчик используется для sudo и разлочивания экрана.

              (и разумеется, отдельный пароль на ssh-ключ).
          +1
          > Наш сервер API написан на Haskell — хотелось бы почитать про ваш опыт. Использовали ли Yesod, так ли плох cabal как кажется, как организован деплой, и т.д.
            +3
            Насколько я знаю, мы никогда не использовали Yesod, в тех случаях, когда был нужен веб-сервер, использовался snap, например в качестве вебсокет-сервера для консолей, исользуется websockets-snap.

            Что вы имеете ввиду? Субъективно cabal, cabal-install, cabal-dev кажутся мне наиболее удобной системой сборки из используемых.

            В данный момент мы собираем пакеты deb/rpm для всех х-ль программ.
            –1
            В Windows Azure такое есть уже давно, но там используется публичный ключ в формате DER, инструкция по его созданию немного кривовата.
              0
              Оффтопик.

              В админ-панели, в разделе «Облачное хранилище», в подразделе «Настройка доступа» пункты «Показать пароль» и «Сгенерировать новый пароль» стоят рядом. Проблема в том, что команда «Сгенерировать новый пароль» выполняется по клику сразу без подтверждения.

              Случайный клик ломает процедуру бэкапов на множестве серверов. Очень досадно. :(

              Куда бы пожаловаться, чтобы добавили подтверждение?
                0
                Лучше всего через тикеты.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое