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

Мы передаем файлы на удаленный сервер в нашем приложении, и обязательным методом аутентификации является использование ключей 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

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

Спасибо!

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

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

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

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

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

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

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

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

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

1. Как они удостоверяются, что вы не разделяете / не теряете данную им пару ключей? а также,
   • Чем эта концепция «пара ключей от ИТ» отличается от пароля, предоставленного вам ИТ.
     Зачем вообще нужны пары ключей в таком случае?

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

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

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