Мой хост использует пароли вместо id_rsa для входа по SSH. Но вместо того, чтобы каждый раз вводить пароль, есть ли способ поместить пароль в мой .ssh / config?
Например:
Host gravy_access
Hostname 127.0.0.1
User my_name_is_gravy
Password gravy_password
Так что когда я ssh gravy_access он мгновенно разрешит доступ.
Нет, я не думаю, что ты сможешь это сделать. Но почему бы не создать ключ? Создайте ключ с помощью ssh-keygen (без пароля), скопируйте публичную часть на свой удаленный хост и добавьте ее в ~ / .ssh / authorized_keys.
Имейте в виду, что любой, кто получит ваш закрытый ключ, сможет подключиться к любому хосту, на котором вы добавили открытый ключ в ~ / .ssh / authorized_keys.
Так что всегда держи свой закрытый ключ частный.
Как прокомментировал Иэн ниже, более безопасный было бы создать ключ с паролем, но кэшировать его с помощью ssh-agent. Тип
ssh-add your_key_file
и вас попросят ввести пароль. Затем он будет кэширован, и до тех пор, пока вы не выйдете из системы, он будет использоваться ssh для входа в систему, удаленного выполнения команд или scp.
Вот соответствующая статья о использование SSH между хостами без использования паролей.
Существует 6 основных способов доступа к серверу с помощью ssh, обеспечивающих определенный уровень безопасности:
Может быть интересно следующее:
Файлы идентификации
Чтобы сгенерировать пару файлов идентификации ssh, используйте программу ssh-key-gen для генерации приватного (обычно ~/.ssh/id_rsa) и публичные (обычно ~/.ssh/id_rsa.pub) пара ключей. Поместите открытый ключ в файл режима 0600 с именем ~ / .ssh / authorized_keys в домашней странице пользователя, вошедшего в систему. Если вы не использовали парольную фразу для своего закрытого ключа, теперь вы должны иметь возможность войти в систему без использования пароля. Однако разумнее защитить свой закрытый ключ парольной фразой. Можно избежать повторного ввода этой фразы при каждом подключении, запустив процесс ssh-agent и загрузив в него ключ и необходимую кодовую фразу. Многие люди запускают процесс ssh-agent при запуске своего 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 клиентского хоста для разрешения доступа вместе с проверкой клиентским хостом пользователя, обращающегося к удаленному хосту. Это слабая форма безопасности и, вероятно, не должна использоваться вообще, или, если она используется, должна использоваться только в локальной сети.
Сертификаты
Сертификаты предлагают множество интересных опций, которые, хотя и похожи на расположение ключей идентификации и authorized_keys, меняют порядок, так что элементы управления, которые обычно находятся в файле authorized_keys, встроены в сертификат. Хочу дать кому-нибудь шанс сбежать date на вашем сервере следующие два дня только как пользователь bob из сети x? Сертификаты кажутся действительно хорошим способом сделать это.
Из man ssh-keygen:
ssh-keygen поддерживает подписание ключей для создания сертификатов, которые могут использоваться для аутентификации пользователя или хоста. Сертификаты состоят из открытого ключа, некоторой идентификационной информации, нуля или более имен участников (пользователя или хоста) и дополнительного набора ограничений, которые подписываются ключом центра сертификации (CA). В этом случае клиенты или серверы могут доверять только ключу CA и проверять его подпись на сертификате, а не доверять многим ключам пользователя / хоста. Обратите внимание, что сертификаты OpenSSH - это другой и гораздо более простой формат сертификатов X.509, используемых в ssl (8).
Беспарольная аутентификация - это основной вариант использования для аутентификации с открытым ключом (например, id_rsa). Было бы плохой практикой безопасности помещать ваш пароль в текстовый файл конфигурации (например, вы .ssh/config). Вместо этого вы должны сгенерировать закрытый и открытый ключи, как упоминает @rems Вот и @joe упоминает Вот. Обязательно укажите пустую кодовую фразу для закрытого ключа при его создании с помощью ssh-keygen.
Как говорили другие, создайте себе пару ключей и разверните открытый ключ на удаленном хосте. Однако не поддавайтесь соблазну создавать ключи без парольной фразы. Используйте ssh-agent для безопасного хранения закрытых ключей. Если вы используете PuTTY в Windows, вы можете использовать Конкурс в противном случае есть ssh-агент.
Использование агента по-прежнему требует ввода пароля для разблокировки ключа, но вы можете настроить, как долго ключ будет храниться, прежде чем потребуется его повторная разблокировка. Это намного безопаснее, чем ключ без ключевой фразы.
Если у вас нет другого выбора (потому что у вас нет доступа к конфигурации сервера и потому что аутентификация ключа запрещена каким-то глупым правилом в вашей организации), вы можете использовать sshpass, небольшой инструмент для подделки интерактивного ввода пароля.