Есть ли такая вещь, как подписанная пара ключей SSH?

9

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

Итак, я создал свою пару ключей с помощью ssh-keygen и отправил свой открытый ключ для вставки в файл авторизованный_диспетчер удаленного хоста. Тем не менее, это было отклонено IT Security, который сказал, что они сгенерируют пару ключей для меня и отправят мне закрытый ключ. Причина: «Нам нужно, чтобы ключи SSH были подписаны командой ИТ-безопасности. Это необходимо для того, чтобы у нас были определенные преимущества в отслеживании и подотчетности».

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

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

Кто-нибудь, пожалуйста, подскажите мне, если я ошибаюсь, спасибо!

Хорошо, теперь, когда мы определили, что SSH-ключи не могут быть подписаны, мне нужно показать IT Security, как они на самом деле могут отслеживать, кто входил в систему (думаю, должен быть конструктивным, если не начнется сборка с рук). ). На моем собственном сервере я установил для sshd LogLevel значение DEBUG. Так что теперь, когда я вхожу в систему, я вижу следующий фрагмент:

Found matching DSA key: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Кажется, это хэш-значение. Как мне связать это с тем, какой открытый ключ в файле авторизованных_кейках использовался? Я знаю, что есть еще одна строка, которая говорит:

debug1: matching key found: file /home/bofh/.ssh/authorized_keys2, line 1

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

Спасибо!

security ssh feicipet
источник
2
Может быть, они распечатают ключи, подпишут (на бумаге), а затем запишут?
InnaM
Получаемое хеш-значение, скорее всего, является так называемым отпечатком ключа. Я рекомендую проверить руководство openssh о том, как вы можете перечислить эти отпечатки пальцев.
Нильс Басьес
Наиболее вероятная причина, по которой действует эта политика, заключается в том, что они действительно хотят иметь возможность выдавать себя за вас, если это необходимо. Аргумент подписи - только BS, чтобы сделать это невинным. Даже если бы им нужно было подписать пабки, им не нужно было бы создавать их самим.
b0fh

Ответы:

13

За время, которое вы задали, вопрос изменился.

В Openssh5.4 добавлена ​​поддержка именно тех сертификатов, которые вам нужны. Смотрите примечание к выпуску на http://www.openssh.org/txt/release-5.4 (и руководства) для получения дополнительной информации, или если вы действительно хотите быть невменяемым, посмотреть на PROTOCOL.certkeys для окровавленных деталей

Джеймс Полли
источник
Просто видел это через очень долгое время ... кажется законным :) Попробую, спасибо!
feicipet
8

Мое первое впечатление при чтении вашего вопроса состоит в том, что ИТ-специалист перепутал SSH и SSL (он должен быть подписан нами), а также не понимает, как на самом деле работает SSL-подпись.

В любом случае, SSH-ключ никоим образом не может быть подписан (о чем я знаю).

Нильс Басьес
источник
+1 вы не можете подписывать ключи ssh так же, как вы можете подписывать сертификаты PGP или SSL. Я бы попросил у них разъяснений.
Дэвид Пашли
4

Что-то не так в этом запросе.

Если он доставляет подписанные файлы на сервер,
я ожидаю, что это будет сделано как минимум.

  1. Вы создаете пару ключей для себя (называйте это my-key)
    • Когда вы хотите что-то отправить,
    • вы сначала зашифруете его my-key-private
    • затем загрузил на сервер этот зашифрованный файл
    • Кто-то на сервере должен полностью изменить процесс,
    • они используют ваш, my-key-pubчтобы расшифровать файл
    • если вы отправили файл, расшифровка восстановит его
    • иначе они не получат какой-либо пригодный для использования файл
    • фактически вы подписали файл своим закрытым ключом
    • они проверили подпись с вашим открытым ключом
    • они отвечают за подтверждение того, что вы отправили файл

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

Это первые вопросы, которые вы можете задать своим ИТ-специалистам.
Если подотчетность является проблемой для ИТ,

  1. Как они удостоверяются, что вы не разделяете / не теряете данную им пару ключей? а также,
    • Чем эта концепция «пара ключей от ИТ» отличается от пароля, предоставленного вам ИТ.
      Зачем вообще нужны пары ключей в таком случае?
Nik
источник
Вы думаете о PGP / GnuPG для шифрования файлов. В этом случае подпись ключа нормальная. Оригинальный вопрос о ключах SSH. Это имело бы смысл, если бы они запрашивали подписанный / зашифрованный ключ SSH PGP (после проверки и подписания ключей PGP друг друга).
pgs
@pgs, я пытаюсь понять, на что ориентируется ИТ-специалист.
ник
Я почти уверен, что парень из службы безопасности сбит с толку, но, поскольку он работает специалистом по информационной безопасности из компании моего клиента, а не из моего коллеги, мне нужно быть немного более тактичным и конструктивно настаивать, не смеясь над ним и говоря, что у него есть дела перепутал Да, это определенно SSH, а не PGP.
участница
@feicipet, тактичность - вот где мои последние очки помогут тебе.
Ник
@feicipet, ваша цель, наконец, заставить их понять, какой минимум они должны сделать для правильного достижения своих целей.
Ник
2

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

Я видел несколько исправленных версий OpenSSH, которые работают, и коммерческая реализация SSH.com также поддерживает аутентификацию X.509. Таким образом, если ваша организация использует один из них, требование подписать ключи центральным органом имеет смысл.

Тем не менее, нет никаких оснований требовать, чтобы сторонний ключ генерировал закрытый ключ! Если они идут по маршруту X.509, им нужно, чтобы вы сгенерировали пару ключей и запрос на подпись сертификата, так же, как вы делали бы с любым другим сертификатом X.509, используемым для SSL и т. Д.

Стивен Вейсс
источник