Назад | Перейти на главную страницу

Есть ли SSL-эквивалент ssh-агенту?

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

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

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

Еще одна вещь, которой я хочу избежать, - это изменить команды gem и pip для предоставления ключей при установлении http-соединения.

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

РЕДАКТИРОВАТЬ: Я продолжал исследовать это, и я наткнулся на станнель. я считать это может быть то, что я ищу, любые отзывы о stunnel также будут отличными!

Немного специфичен для высокопроизводительных вычислений и инфраструктуры безопасности сети (API-интерфейсы общедоступны и доступны). MyProxy позволяет пользователям получать учетные данные прокси RFC 3820. В основном вы получите сертификат прокси (недолговечный) после того, как учетные данные исходного сертификата будут проверены MyProxy. curl должен работа с сертификатами RFC 3820. Также доступен SSH, который может использовать GSI. Видеть MyProxy - диспетчер учетных данных X.509.

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

То же самое может быть верно и с использованием SSH (пусть сеансы задерживаются надолго) - это можно сделать с помощью пароля, который требуется один раз в начале сеанса SSH, или, если это нормально, вы можете использовать асимметричные ключи без пароля; вам нужно будет внести изменения в конфигурацию или настроить DNS, чтобы имена работали правильно, если вы используете SSH, поскольку вам нужно будет задействовать локальный порт пересылки с вашим клиентом, чтобы достичь удаленного сервера.

(Вы не говорите, какую платформу вы используете.)

В OSX с этим справится связка ключей. Хотя это не совсем то же самое, что ssh-agent, вы можете настроить его, чтобы разрешить доступ к закрытому ключу определенным приложениям (с запросом или без, в зависимости от выбранных вами настроек).

В Linux вы можете использовать Брелок Гнома, который преследует аналогичные цели. Я не уверен, предлагает ли он ту же степень детализации, что и связка ключей OSX, с точки зрения предоставления разных прав для каждого приложения, но вы также можете разблокировать его при входе в систему.

В итоге я выбрал совершенно другой подход. Я установил сервер вне брандмауэра, используя Nginx с SSL и BasicAuth. Это очень хорошо работает.