Я пытаюсь изучить это, а не просто следовать руководствам, чтобы иметь возможность рекомендовать правильные действия, когда люди спрашивают (а они спрашивают). Вот что у меня получилось.
Сначала сгенерируйте оба ключа с помощью такой команды:
ssh-keygen -b 2048 -t rsa -C comment -f ~/.ssh/id_rsa
Затем вы помещаете публичную часть ключа в файл authorized_keys2.
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2
(а затем chmod на 600 или что-то подобное)
И вы загружаете закрытый ключ на свой компьютер (id_rsa) и вводите его в Putty для считывания и аутентификации.
Правильные ли это шаги по настройке аутентификации с открытым/закрытым ключом для беспарольного входа в SSH?
решение1
Хотя описанные вами шаги будут работать, есть проблема. Вы генерируете пару ключей на целевом (удалённом) компьютере, а затем загружаете файл закрытого ключа в свою локальную систему. Здесь есть последствия для безопасности, которые вы не должны игнорировать:
- Если пульт уже взломан, кто-то мог узнать вашу парольную фразу.
- Если удаленная система будет скомпрометирована в будущем, злоумышленник получит доступ к вашему файлу закрытого ключа (и возможность использовать автономную атаку методом подбора, чтобы попытаться расшифровать его).
Поскольку вы используете пары ключей SSH для (попытки) решения некоторых проблем, присущих аутентификации по паролю, обычно вы хотите сделать это следующим образом:
Сгенерируйте пару ключей на локальной системе. В идеале закрытый ключ (a) никогда не будет храниться в общей файловой системе (например, в домашнем каталоге NFS) и (b) никогда не будет храниться на компьютере, который позволяет удаленный вход в систему.
Опубликуйте открытый ключ везде и всюду. Я храню свой открытый ключ(и) на веб-сайте, чтобы иметь возможность получить их, когда они мне понадобятся. Поместите открытый ключ в соответствующие
authorized_keysфайлы в системах, к которым вы будете подключаться.
Если вы особенно параноидальны, вы можете сохранить свой закрытый ключ на флэш-накопителе и использовать его только для загрузки ключа в работающий ssh-agent. На этом этапе вам больше не нужен сам файл ключа.
решение2
Может быть лучше сгенерировать ключ на клиентской системе(ах). Вы можете получить больший файл authorized_keys, но так проще отключить скомпрометированную систему. Если вы переносите закрытый ключ сервера, вам нужно будет повторно сгенерировать и перенести ключ на все клиентские системы. У каждого клиента должен быть свой собственный ключ.
Putty использует puttygenдля генерации ключа. puttygenтакже предоставит открытый ключ в правильном формате для вставки в клиентскую систему. Лучше всего защитить ключ с помощью парольной фразы, если он используется для доступа к входу. Pageantили ssh-agentможет использоваться для хранения незащищенного ключа в памяти, чтобы не нужно было вводить парольную фразу повторно при каждом подключении.
После того, как вы добавили один ключ и установили защиту, вы можете добавить дополнительные ключи, при этом необходимо сбросить разрешения. Обычно я загружаю открытый ключ из системы с именем, например, example.pubгде example — имя системы, к которой принадлежит ключ.
Многие реализации вернулись к использованию authorized_keysв качестве файла ключа. Этот файл можно использовать для ограничения системы, из которой будет принят ключ, принудительного запуска команды, ограничения доступа и других вещей. manПодробнее см. на странице.
В некоторых случаях может быть полезно иметь несколько ключей на клиентской системе. Это можно сделать для поддержки пакетных процессов, которые работают с ключами, не имеющими пароля.
решение3
Выглядит хорошо. Многие бы поступили наоборот (сгенерировали ключ локально, а затем отправили его .pubна сервер), но любой из вариантов может сработать.