Какой-либо умный способ поместить пароль в ключ SSH?
Вы находите официальные патчи здесь: http://www-933.ibm.com/support/fixcentral/
Я рекомендую, чтобы исправление через СРАЗИЛО. Можно найти информацию обо всем этом в Redbook. Это - набор очень хорошей документации, предоставленной IBM.
Нет, я не думаю, что можно сделать это. Но почему, не создавая ключ? Создайте ключ с ssh-keygen (без пароля) и скопируйте общедоступную часть в свой удаленный хост и добавьте его к ~/.ssh/authorized_keys.
Следует иметь в виду, что любой получающий Ваш закрытый ключ сможет к любому хосту, где Вы добавили открытый ключ к ~/.ssh/authorized_keys.
Поэтому всегда сохраняйте свой закрытый ключ частным.
Как Iain прокомментировал ниже, более безопасный должен будет создать ключ с паролем, но кэшировать его с помощью ssh-агента. Ввести
ssh-add your_key_file
и Вас попросят Вашего пароля. Это будет затем кэшироваться, и поскольку долго Вы не выходите из системы, это останется там, чтобы использоваться ssh для логинов или удаленного выполнения команды или scp.
Вот соответствующая статья об использовании SSH между хостами, не используя пароли.
Аутентификация Passwordless является основным вариантом использования для аутентификации С открытым ключом (например, id_rsa). Это была бы плохая практика безопасности для размещения пароля в конфигурационный файл простого текста (такой как Вы .ssh/config). Вместо этого необходимо генерировать и открытый ключ с закрытым ключом как @rems упоминания здесь и упоминания @joe здесь. Обязательно предоставьте пустой пароль закрытому ключу при создании его с ssh-keygen.
Поскольку другие сказали, создают себя пара ключей и развертывают открытый ключ на удаленном хосте. Однако не испытывайте желание создать ключи без пароля. Используйте ssh-агент для удержания закрытых клавиш надежно для Вас. При использовании PuTTY на окнах затем, можно использовать Театрализованное представление иначе существует ssh-агент.
Используя агент все еще требует, чтобы Вы ввели пароль для разблокирования ключа, но можно настроить, сколько времени клавиша будет удерживаться, прежде чем это потребует разблокирования снова. Это намного более безопасно, чем ключ без пароля.
Если у Вас нет никакого другого выбора (потому что у Вас нет доступа к конфигурации сервера и потому что ключевая аутентификация запрещается некоторым глупым правилом в Вашей организации), можно использовать sshpass, мелкий инструмент, фальсифицирующий интерактивный ввод пароля.
Существует 6 основных способов получить доступ к серверу с помощью ssh, которые обеспечивают некоторый уровень безопасности:
- использование (Интерактивной с клавиатурой) комбинации пользователя/пароля
- использование ssh идентификационных данных (или защищенный с паролем или не)
- использование Основанной на хосте аутентификации
- использование ssh сертификаты
- Kerberos
- PAM
Следующее могло бы представлять интерес:
Файлы идентификационных данных
Для генерации ssh определяют, что пара файла использует ssh-key-gen программу для генерации частного (обычно ~/.ssh/id_rsa) и общественность (обычно ~/.ssh/id_rsa.pub) пара ключей. Поместите открытый ключ в 0600 файлов режима, названных ~/.ssh/authorized_keys в доме зарегистрированного пользователя. Если бы Вы не использовали пароль для своего закрытого ключа, то необходимо теперь смочь войти в систему, не используя пароль. Однако более разумно защитить Ваш закрытый ключ с паролем. Можно избежать необходимости перепечатывать эту фразу при каждом соединении путем выполнения процесса ssh-агента и загрузки ключевого и необходимого пароля в это. Многие люди порождают процесс ssh-агента при запуске их X сессий.
Можно сделать что-то вдоль следующих строк при необходимости в ssh-агенте:
eval `ssh-agent -s`
ssh-add [optional ssh private file if not ~/.ssh/id_rsa]
<enter passphrase>
Файл authorized_keys может содержать много различных ключей. Им можно также дать специальные средства управления доступом с помощью управления фразами в начале строки каждого ключа в файле. Например, from="192.168.1.* в начале записи ключа ограничит ключ для использования хостами, соединяющимися от 192.168.1.x адреса.
Основанная на хосте аутентификация
Основанный на хосте аутентифицируемый предоставляет доступ с помощью удаленного имени хоста и имени пользователя, связанного с ним. Это использует ssh ключ хоста клиента для разрешения доступа, вместе с проверкой хоста клиента пользователя, получающего доступ к удаленному хосту. Это - слабая форма безопасности и вероятно не должно использоваться вообще, или если она используется, должен только использоваться на LAN.
Сертификаты
Сертификаты предлагают много интересных опций, которое, в то время как подобный расположению ключей идентификационных данных и authorized_keys, инвертирует расположение так, чтобы средства управления, которые обычно лежат в authorized_keys файле, были встроены в сертификат. Хочу дать кому-то шанс работать date на Вашем сервере в течение следующих двух дней только как пользовательский боб из сети x? Сертификаты, кажется, действительно хороший способ сделать это.
От man ssh-keygen:
то, чтобы подавать знак поддержек ssh-keygen ключей произвести сертификаты, которые могут использоваться для аутентификации хоста или пользователя. Сертификаты состоят из открытого ключа, некоторой информации об идентификационных данных, нуля или большего количества принципала (пользователь или хост) имена и дополнительный набор ограничений, которые подписываются ключом Центра сертификации (CA). Клиенты или серверы могут затем доверять только ключу CA и проверить его подпись на сертификате вместо того, чтобы доверять многим ключам пользователя/хоста. Обратите внимание, что сертификаты OpenSSH являются другим, и намного более простым, форматом к сертификатам X.509, используемым в ssl (8).