Администратор сервера отправил мне закрытый ключ для использования. Почему?

Я должен получить доступ к серверу, чтобы связать промежуточные и живые серверы компании в наш цикл развертывания. Администратор со своей стороны установил два экземпляра, а затем создал пользователя на сервере для нас в SSH в качестве. Это то, к чему я привык.

Теперь я думаю, что произойдет, я отправлю им свой открытый ключ, который можно будет поместить в папку их авторизованных ключей. Однако вместо этого они прислали мне имя файла, id_rsaкоторое внутри файла содержится -----BEGIN RSA PRIVATE KEY-----по электронной почте. Это нормально?

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

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

ssh security key-authentication administration Тоби
источник

Я бы не назвал это нормальным или нормальным, но поскольку у вас есть закрытый ключ (при условии, что он уже добавил его как авторизованный), вы можете использовать его так же, как любой другой закрытый ключ. Вам не нужен соответствующий открытый ключ, но если вы хотите, вы всегда можете сгенерировать его: askubuntu.com/a/53555/158442

Muru

Перебор -----BEGIN RSA PRIVATE KEY-----по электронной почте - следующая страшная вещь после просмотра имени пользователя '); DROP DATABASE;--в вашей таблице имен пользователей.

Дмитрий Григорьев

@DmitryGrigoryev ничего страшного в том, чтобы видеть '); DROP DATABASE;--в качестве имени пользователя в вашей таблице базы данных - это показывает, что вы корректно

избегаете

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

user207421

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

user253751

Ответы:

116

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

То, что «у вас на уме», как то, что сейчас должно произойти, правильно.

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

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

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

Спасибо! Поскольку электронная почта не является безопасным способом распространения закрытых ключей, не могли бы вы вместо этого поставить мой открытый ключ? Это прилагается.
Поблагодарите их и спросите, не возражают ли они против того, чтобы вы установили собственную пару ключей, поскольку отправленный ими закрытый ключ следует считать скомпрометированным после отправки по электронной почте.

Создайте свою собственную пару ключей, используйте ключ, который они отправили вам, чтобы войти в систему в первый раз, и используйте этот доступ для редактирования authorized_keysфайла, содержащего новый открытый ключ (и удаления открытого ключа, соответствующего скомпрометированному закрытому ключу.)

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

Редактировать в ответ на комментарии от MontyHarder:

Ни один из предложенных мной вариантов действий не включает «исправление ситуации, не сообщая другому администратору, что он сделал неправильно»; Я просто сделал это тонко, не бросая его под автобус.

Тем не менее, я добавлю, что я бы также (вежливо) проследил бы, если бы тонкие подсказки не были подобраны:

Здравствуйте, я видел, что вы не ответили на мой комментарий об электронной почте как о небезопасном канале. Я хочу быть уверен, что это больше не повторится:

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

Лучший,

Тоби

Wildcard
источник

+1 Лучший ответ. И я бы добавил: будьте особенно осторожны, так как этот сисадмин оказался некомпетентным. Лучше прикрыть спину, когда (а не если ) он навсегда испортит сервер.

dr01

Благодарю. Я использовал несколько деликатных фраз и отправил свой открытый ключ. Все выглядит решенным, но я деавторизирую ключ, который он прислал мне сейчас.

Тоби

Дело не в том, что другой админ "может выглядеть как идиот". Это то, что другой админ сделал что-то идиотское. Я могу думать только об одном сценарии, при котором закрытый ключ должен быть разделен между компьютерами, и именно здесь пул серверов доступен с одним и тем же именем (круговое разрешение DNS и т. Д.) И должен представлять один и тот же ключ хоста SSH, чтобы автоматизированные процессы примут, что они это имя. И в этом случае один и тот же человек будет администратором всех серверов и будет обрабатывать переводы без участия сторонней организации.

Монти Хардер

@zwol На моей работе у нас есть философия «без вины», которая понимает, что мы будем совершать ошибки, но придает первостепенное значение не повторять одну и ту же ошибку дважды. Но чтобы не повторить одну и ту же ошибку дважды, вы должны знать, что это ошибка, поэтому я не могу переоценить ответы, предлагающие ОП просто исправить ситуацию, не сказав другому администратору, что он сделал неправильно. Я решил назвать ошибку «идиотской», а не называть имена администраторов именно по той причине, которую вы изложили. (Но я не уверен, что в ваших заключительных скобках сформулировано значимое различие.)

Монти Хардер

@LightnessRacesinOrbit, я подозреваю, что у вас может быть неполное понимание значения слова "дипломатия". Вы пробовали прояснить это в хорошем словаре, таком как третий новый международный словарь Вебстера?

Wildcard

Должен ли я просто игнорировать ключ, который он мне прислал, и попросить их поместить мой открытый ключ в их авторизованную папку?

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

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

Дмитрий Григорьев
источник

И поскольку у ОП нет способа узнать, насколько защищена машина администратора (из истории, предположительно, очень небезопасной), он должен предположить, что закрытый ключ также (или будет) просочился другим людям. Отправка секретного ключа по электронной почте - это просто бонус к бессмысленности Infosec.

dr01

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

Макс Рид

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

Дмитрий Григорьев

@DmitryGrigoryev Он всегда мог добавить еще один ключ в ваш файл author_keys ...

Макс Рид

@MaxRied Я имел в виду /var/log/secureили похожий , я уверен, что космический трюк не обманет этот.

Дмитрий Григорьев

Для меня это выглядит так, как будто администратор сгенерировал для вас пару закрытых / открытых ключей, добавил открытый ключ в авторизованные ключи и отправил вам закрытый ключ. Таким образом, вам нужно использовать этот закрытый ключ только для ваших сш-сессий с сервером. Не нужно создавать пару ключей самостоятельно или отправлять администратору открытый ключ на ваш возможно поврежденный (всегда наихудший случай: P) закрытый ключ.

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

Мой подход заключается в следующем: используйте закрытый ключ для входа в систему один раз, добавьте свой собственный открытый ключ к авторизованным ключам на сервере (заменив оригинальный открытый ключ) и выбросьте этот почтовый закрытый ключ. Затем вы можете поблагодарить администратора за то, что он / она / она предоставил вам закрытый ключ, но вы бы предпочли, чтобы такую информацию / ключи не отправляли по электронной почте (/ вообще).

user204269
источник

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

Касперд

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

mattdm

Замечательно, что вы можете это исправить сами. Лучше сделать это самому, чем ждать, пока администратор установит открытый ключ для новой пары ключей. Отказ от использования секретного закрытого ключа больше ничего не помогает; он просто дает потенциальным перехватчикам дольше использовать его, прежде чем вы сможете войти в него и удалить его authorized_keys(после добавления + тестирования вашего собственного).

Питер Кордес

@mattdm Это ... вполне логично, но пугающе. Человек, который не может сгенерировать пару ключей и отправить мне открытый ключ, вероятно, не сможет добиться большего успеха с секретным ключом, который я ему дам.

Монти Хардер

@mattdm, достаточно справедливо, но, поскольку я был единственным, кто попросил его сделать все это, мне трудно поверить, что он подумал, что я не знаю, как подключиться к ssh. Во всяком случае, шаги, которые он предпринял, были более запутанными, так как я знаю только основной распространенный способ использования открытых ключей. : x

Тоби