Я пытался следовать этому руководству: Этот учебник, но застряли в момент входа в систему через открытые ключи (без запроса пароля). Я новичок в командной строке unix.
Мой сценарий: я запускаю php-скрипт (ssh2) и запускаю команду ниже после успешного подключения через ssh.
ssh -f -L 3307:127.0.0.1:3306 someuser@remote.server.com sleep 60 >> logfile
Ниже я не могу понять ту часть урока. Я пробовал делать ssh-keygen и хранить публичные / приватные ключи в моих файлах /home/someuser/.ssh/authorized_keys и authorized_keys.pub. Но безрезультатно :(, Спасибо за любую помощь.
Как избежать запроса пароля: Обычно после выполнения команды, подобной приведенной выше, вы получите запрос на ввод пароля для проверки входа пользователя на удаленный компьютер. Опять же, это плохо для автоматизации, поскольку никогда не рекомендуется использовать приложение, взаимодействующее с приглашением командной строки (или хранящее пароли в виде простого текста). В этом случае на помощь снова приходит шифрование с открытым ключом. SSH не запрашивает пароль, если публичный сертификат удаленного пользователя хранится в файле ~ / .ssh / authorized_keys учетной записи удаленного пользователя, в которую выполняется вход. Мы просто добавляем в этот файл наш открытый ключ, и запросы пароля больше не являются проблемой.
Удивленный ssh-copy-id не упоминается - это упрощает.
ssh-copy-id username@remotehost.com
Нет, файла ~ / .ssh / authorized_keys.pub нет, и не помещайте свой закрытый ключ в authorized_keys! Ваш закрытый ключ должен быть только в сгенерированном файле и больше нигде не размещен (возможно, только резервная копия).
Что вам нужно сделать, это сначала на вашем локальном хосте, с которого вы запустите команду ssh, создайте ключ с помощью ssh-keygen, с паролем или без него, по вашему желанию, но имейте в виду, что любой, кто получит этот закрытый ключ без пароля также сможет войти в систему. Так что держи это частный.
Затем на удаленном хосте, на который вы хотите войти с помощью этого ключа, введите в ~ / .ssh / authorized_keys публичную часть сгенерированного ключа id_dsa.pub (или полученное имя).
Это сработает. Имейте в виду, что, поскольку ssh обеспечивает безопасность, права доступа к файлам ОЧЕНЬ важны. Прочтите раздел «ФАЙЛЫ» в
man ssh
Я знаю, что Вы имеете ввиду. Я думаю, что инструкции на openssh.org ясны как грязь. Простая версия выглядит так:
Начните с пользователя на клиентском компьютере, который будет подключаться к remote.server.com по ssh. Запустите там ssh-keygen. Когда он попросит вас ввести кодовую фразу, просто нажмите Enter.
Скопируйте файл .ssh / id_rsa.pub (или id_dsa.pub, в зависимости от вашего типа шифрования) на remote.server.com, затем добавьте содержимое этого файла в ~ someuser / .ssh / authorized_keys. Вы также можете отредактировать этот файл, а затем вставить содержимое id_rsa.pub в конец authorized_keys.
Проверьте это, отправив sshing с клиентской машины (как пользователя, от имени которого вы запускали ssh_keygen) на someuser@remote.server.com. Он не должен запрашивать пароль. Если это так, то может быть проблема с разрешениями (разрешения должны быть 600 как для ~ someuser / .ssh, так и для ~ someuser / .ssh / authorized_keys) или что-то еще, что будет обнаружено журналами на remote.server.com . Вы также можете запустить ssh-сервер на remote.server.com в режиме отладки (sshd -d), чтобы увидеть, что он делает.
Поскольку вы не используете парольную фразу для этого ключа, убедитесь, что вы не передаете этот открытый ключ кому-либо еще. Если после этой первоначальной настройки вы получите ошибки об отпечатке ключа хоста или об атаке "человек посередине", ОТКАЗАТЬСЯ ОТ ПОДКЛЮЧЕНИЯ К ЭТОМУ СЕРВЕРУ! Любая автоматизированная задача завершится неудачей при такой ошибке, и открытый ключ не будет отправлен. Единственный законный случай, когда вы захотите кропотливо обойти такую ошибку (клиент openssh даст вам указания, как это сделать), - это когда отпечаток ключа на сервере изменяется, обычно из-за обновления SSH на этом сервере. . Если вы не являетесь администратором удаленного сервера, свяжитесь напрямую с этим человеком и спросите, изменилось ли что-нибудь на его сервере, прежде чем изменять базу данных ключей вашего хоста.