Пользовательское расположение ключа ssh для rhc

Я использую инструмент rhc cli для проектов OpenShift и столкнулся с проблемой по умолчанию rhc SSH-ключ.

При любом действии, связанном с ssh (настройка, создание приложения и т. д.), rhc создает ключ ~/.ssh/id_rsa, если он не существует. Мне не нравится такое поведение, и я бы хотел, чтобы он использовал что-то вроде клавиши ~/.ssh/my_openshift.

Я добавил ssh_key_file='~/.ssh/my_openshift' к ~/.ssh/express.conf, но это не помогает.


Итак, вопрос;

  • как я могу настроить инструмент rhc для использования пользовательского ssh-ключа?

Примечание: я знаю, как добавить дополнительный ключ ssh, но я хотел бы остановить создание/использование rhc ~/.ssh/id_rsa



ОБНОВЛЕНИЕ 1

К сожалению, ответ King-Wizard (удален) не ответил на мой вопрос, потому что:

  1. Ответ не фигурирует - можно или нет заставить rhc игнорировать ~/.ssh/id_rsa при настройке.

  2. На мой взгляд, основная проблема - если мы используем несколько приложений, требующих ключ ssh по умолчанию (id_rsa), это добавит путаницы в управлении ключами ssh.

  3. Временное исправление, которое я нашел, это создание пустого файла id_rsa и блокировка доступа к нему для записи. Так:

    • Nothing can use id_rsa correctly - this is how we will catch apps with unhealthy attempt to use id_rsa. And it is good for me, because I do not use id_rsa key at all.
    • rhc видит, что id_rsa существует, и не пытается создать свой во время rhc setup.
    • rhc не может использовать id_rsa, поэтому использует дополнительные ключи, добавленные с помощью rhc sshkey add somekey_
  4. Мое решение не самое лучшее, потому что оно тоже создает беспорядок, но меньше, чем переключение клавиш командами bash. На мой взгляд, лучшие решения:

    • Check if original rhc supports custom default keys through express.conf
    • Если оригинальный rhc не поддерживает это, исправьте и отправьте патч сообществу =)

person AlexMakII    schedule 07.12.2015    source источник
comment
Хорошо, подведем итоги. Спасибо @King-Wizard за ответ и исправление моего вопроса (так намного лучше)   -  person AlexMakII    schedule 30.12.2015
comment
спасибо @King-Wizard, и вы были правы, все это время я работал через токен.   -  person AlexMakII    schedule 01.01.2016


Ответы (1)


Во-первых, я не могу понять, почему вы не хотите иметь ключ ssh по умолчанию. Но в любом случае, просмотрите мой ответ здесь: https://stackoverflow.com/a/34559668/520567

Ключ SSH используется для ssh. Токен используется для запросов API. Это разные варианты использования. rhc использует исполняемый файл ssh внизу, поэтому использование пользовательского ключа означает отредактировать ~/.ssh/config, чтобы установить ключ по умолчанию в другое место или установить разные ключи для разных хостов. rhc setup с этим плохо справляется. Но как только вы настроите свой ключ, вам больше не придется запускать rhc setup.

Слишком долго все объяснять без конкретных "что" и "почему" вы пытаетесь сделать именно так.

person akostadinov    schedule 01.01.2016
comment
Почему не id_rsa: 1. Если два приложения требуют id_rsa (и это возможно) одновременно - у нас проблемы. Таким образом, мы будем вынуждены использовать один ключ для двух разных приложений (фиктивный пример: OpenShift, Amazon, Github). 2. Мне не нравится идея использовать ключ ssh по умолчанию для сторонних API. IMHO id_rsa можно использовать для интрасети, IOT или чего-то вроде сети серверов с прямой цепью. В качестве примера: это похоже на использование основной электронной почты для хромых сервисов — можно использовать основную электронную почту для linkedin/stackoverflow в качестве личного идентификатора, но не для глупой игры за 2 часа.com. - person AlexMakII; 04.01.2016
comment
Есть еще одна проблема с rhc, и она была основной причиной моего вопроса. Если мы опустим проблему с настройкой rhc (это происходит только один раз), rhc по-прежнему будет ссылаться на id_rsa при других действиях (например, rhc app-create), и если ключ пропущен, rhc создаст его. Итак, я не уверен в этом инструменте и могу быть уверен, что он не будет привязан к id_rsa неправильным образом или в непредсказуемой ситуации. - person AlexMakII; 04.01.2016
comment
@AlexMakII, не могли бы вы показать журнал с таким поведением? Также ваша rhc версия. Если последний rhc создает ключи ssh вне rhc setup, это действительно будет ошибка, о которой стоит сообщить. Спасибо. - person akostadinov; 04.01.2016
comment
что касается вашего использования id_rsa, я считаю, что это совершенно другое. Ваш открытый ключ (id_rsa.pub) не может быть использован для связи с вами, как адрес электронной почты, или для доступа к какому-либо ресурсу, например, с помощью вашего пароля. Он служит только для проверки того, что человек, использующий соответствующий закрытый ключ (id_rsa), находится на другом конце. id_rsa никогда не открывается конечной точке, он только подписывает некоторые проверочные сообщения. Таким образом, вы ничего не получаете, имея несколько ключей, кроме неудобства выбора правильного каждый раз. Я не могу вспомнить, чтобы какой-нибудь специалист по безопасности рекомендовал использование нескольких ключей ssh.. просто сказал - person akostadinov; 04.01.2016
comment
Кстати, во всех трех приведенных выше примерах ключ ssh используется только для фактических соединений ssh, а другая аутентификация используется для вызовов API. В примере с github ключ используется для доступа к репозиториям по протоколу git+ssh. Если вы попытаетесь использовать git поверх https, вы увидите, что ключ ssh вам не поможет. - person akostadinov; 04.01.2016
comment
несколько ключей - да, вы почти правы, но IMO один ключ на ПК - это точка отказа, особенно если его личный ПК привязан к нескольким разным службам. - person AlexMakII; 07.01.2016
comment
Про автосоздание id_rsa при ненастроечных действиях. У меня rhc 1.38.4. Я удалил id_rsa, назвал «rhc app-create someapp python-2.7», и во время создания приложения получил «Ключи SSH не найдены. Мы сгенерируем для вас пару ключей.'. И генерируется id_rsa. Итак, прямо сейчас, пока я не переосмыслю текущую ситуацию - я выбираю пустой id_rsa + chmod 000. Но все равно спасибо, ваши упоминания полезны на моем пути. Ваше здоровье - person AlexMakII; 07.01.2016
comment
@AlexMakII, я смог воспроизвести и зарегистрировал для этого ошибку bugzilla.redhat.com/show_bug .cgi?id=1296994 ; по одному ключу на ПК - это точка отказа, как я уже писал, я не вижу причин для этого. Может быть, вы объясните, какое это имеет значение? - person akostadinov; 08.01.2016
comment
Хотя использование 1 ключа на хост не более безопасно, чем использование общего ключа, использование mult. Ключи обеспечивают преимущества управления рисками — если общий ключ скомпрометирован, злоумышленник получает доступ ко всем системам, а не только к одной системе при использовании нескольких ключей. Как security.stackexchange.com/questions/40050/ указывает, что это снижает риск воздействия атаки даже если это не более безопасно по своей сути, и согласно GitHub это не просто лучшая практика: совместное использование ключей нарушает их TOS developer.github.com/guides/managing-deploy-keys - person Bryan 'BJ' Hoffpauir Jr.; 22.05.2016
comment
@ Bryan'BJ'Hoffpauir, я думаю, вы смешиваете две вещи. Делиться ключами между пользователями глупо, и никто не выступает за это. Совместное использование одного и того же закрытого ключа пользователя на нескольких машинах - не уверен. Если у вас есть два личных ключа, которые разрешают доступ к одним и тем же службам, то потеря любого из них злоумышленнику одинаково плоха - например. вы ничего себе не экономите. Теперь, в зависимости от конкретного использования, это может иметь некоторый смысл. Но наличие 5 ключей на одной машине, одного и того же пользователя для 5 служб практически ничего не дает. Если злоумышленник может захватить один, то он может захватить и все ключи. Я не вижу связанного ответа противоречащим. - person akostadinov; 24.05.2016