Вопрос или проблема
Почему SSH игнорирует файл конфигурации пользователя
ssh сначала не читает пользовательский конфигурационный файл, а обращается к системным настройкам.
Вот мой подробный вывод ssh (при использовании локального пользователя, а не root):
-bash-4.1$ ssh -v [email protected]
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 фев 2013
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: Применение параметров для *
debug1: Подключение к github.com [192.30.253.113] порт 22.
debug1: Соединение установлено.
debug1: файл идентификации /var/www/html/.ssh/identity тип -1
debug1: файл идентификации /var/www/html/.ssh/identity-cert тип -1
debug1: файл идентификации /var/www/html/.ssh/id_rsa тип -1
debug1: файл идентификации /var/www/html/.ssh/id_rsa-cert тип -1
debug1: файл идентификации /var/www/html/.ssh/id_dsa тип -1
debug1: файл идентификации /var/www/html/.ssh/id_dsa-cert тип -1
debug1: файл идентификации /var/www/html/.ssh/id_ecdsa тип -1
debug1: файл идентификации /var/www/html/.ssh/id_ecdsa-cert тип -1
debug1: Удаленная версия протокола 2.0, удаленная версия программного обеспечения libssh-0.7.0
debug1: нет совпадения: libssh-0.7.0
debug1: Включение режима совместимости для протокола 2.0
debug1: Локальная версия строка SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT отправлено
debug1: SSH2_MSG_KEXINIT получено
debug1: kex: сервер->клиент aes128-ctr hmac-sha1 none
debug1: kex: клиент->сервер aes128-ctr hmac-sha1 none
debug1: отправка SSH2_MSG_KEXDH_INIT
debug1: ожидает SSH2_MSG_KEXDH_REPLY
Аутентичность хоста 'github.com (192.30.253.113)' не может быть установлена.
Отпечаток ключа RSA: 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Вы уверены, что хотите продолжить подключение (да/нет)? да
Предупреждение: 'github.com,192.30.253.113' (RSA) навсегда добавлен в список известных узлов.
debug1: ssh_rsa_verify: подпись верна
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидает SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS получено
debug1: SSH2_MSG_SERVICE_REQUEST отправлено
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug1: Аутентификации, которые могут продолжаться: publickey
debug1: Следующий метод аутентификации: publickey
debug1: Попытка использовать закрытый ключ: /var/www/html/.ssh/identity
debug1: Попытка использовать закрытый ключ: /var/www/html/.ssh/id_rsa
debug1: Попытка использовать закрытый ключ: /var/www/html/.ssh/id_dsa
debug1: Попытка использовать закрытый ключ: /var/www/html/.ssh/id_ecdsa
debug1: Нет больше методов аутентификации для проб.
Доступ запрещён (publickey).
Следовательно, он не может найти мои ключи, местоположение которых указано в локальной конфигурации. Почему ssh игнорирует локальный конфигурационный файл, находящийся в ~/.ssh/config? У файла установлен режим доступа 600. Я также пробовал 400, но безуспешно.
Убедитесь, что владелец ~/.ssh/config соответствует имени пользователя, под которым вы вошли. Судя по вашему захвату, вы вошли как www-data, поэтому следует выполнить chown www-data:www-data /var/www/html/.ssh/config из оболочки root.
Обратите внимание, если у вас Apache настроен на /var/www/html, это КРАЙНЕ ПЛОХО, так как ваши SSH ключи могут быть где-то в доступе Apache, так как простая ошибка конфигурации или уязвимость PHP приложения может раскрыть ваши ключи любому, кто имеет доступ к Apache. Вы должны изменить домашний каталог пользователя www-data на что-то вне любого каталога, доступного Apache. Вы можете сделать это, вручную создав каталог в другом месте (например, /etc/systemhome/www-data или создать /home/www-data) и редактируя запись для www-data в /etc/passwd; вам нужно будет выйти и снова войти, чтобы изменения вступили в силу.
Используйте идентификатор хоста в конфигурационном файле, и тогда он будет использовать все, что указано в вашей конфигурации для этого хоста (не то же самое, что и DNS имя).
Например:
Host github
HostName github.com
IdentityFile ~/.ssh/id_rsa.pem
User srg-b
Это происходит, когда каталог .ssh не исполняем для процесса ssh. В любом случае /var/www/html/.ssh не должно существовать, так что что-то не так.
Запуск
sudo chown -R <user> ~/.ssh
…решил эту надоедливую проблему для меня после слишком долгих попыток диагностировать это – по какой-то причине по крайней мере один из файлов в папке SSH не принадлежал пользователю, которому принадлежит каталог.
Мой .ssh/config игнорировался, потому что в нём была строка Host 191.168.1.*, которую я намеревался использовать для любого устройства в локальной сети. Оказалось, что сопоставление хостов выполняется по тексту, введённому в команде ssh, так что, даже если устройство bravo имеет IP 191.168.1.40, команда ssh bravo не совпадала с конфигурацией.
Изменение на ‘Host alpha bravo gamma’ сработало отлично.
Ответ или решение
Проблема с тем, что SSH игнорирует файл конфигурации пользователя, обычно связана с несколькими ключевыми аспектами, которые необходимо учитывать при диагностике.
-
Путь к конфигурационному файлу: Убедитесь, что вы используете правильный путь к файлу конфигурации. Обычно он должен находиться в
~/.ssh/config, где~обозначает домашний каталог текущего пользователя. В вашем случае путь указан как/var/www/html/.ssh/config. Если вы выполняете команду от имени пользователя, например,www-data, то убедитесь, что файлconfigдействительно находится в каталоге/var/www/html/.ssh/. -
Права доступа: SSH требует строгих прав доступа к конфигурационным файлам и директориям. Правила доступа должны быть настроены следующим образом:
- Директория
~/.sshдолжна иметь права700(только владелец может читать, записывать и выполнять). - Файл
~/.ssh/configдолжен иметь права600(только владелец может читать и записывать). Использованиеchmod 400не является необходимым здесь, так как это ограничит запись, что не всегда нужно для конфигурационного файла.
- Директория
-
Владельцы файлов: Важным шагом является также удостовериться, что владелец файла
~/.ssh/configсовпадает с пользователем, под которым вы выполняете SSH-команду. Используйте командуchownдля изменения владельца:sudo chown www-data:www-data /var/www/html/.ssh/configЗамените
www-dataна соответствующее имя пользователя, если это необходимо. -
Настройка хоста в конфигурационном файле: Если вы хотите, чтобы ваш конфигурационный файл обрабатывал различные хосты, убедитесь, что у вас правильно настроены записи. Например, для работы с GitHub можно использовать следующее:
Host github HostName github.com IdentityFile ~/.ssh/id_rsaТакже стоит отметить, что сопоставление хоста происходит по полному имени хоста или алиасу, указанным в конфигурационном файле, поэтому не используйте IP-адреса или общие записи вроде
191.168.1.*, так как это может не сработать с командами SSH. -
Проблемы с доступом: Убедитесь, что процесс SSH имеет доступ к директории
~/.ssh. Если папка не имеет прав на выполнение, SSH не сможет прочитать содержимое, что приведет к игнорированию файла конфигурации. Убедитесь, что домашняя директория (например,/var/www/html) и все родительские директории также имеют соответствующие права. - Использование sudo: Если вы запускаете SSH с помощью
sudoили от имени другого пользователя, давайте в этом убедимся. В случае, если вы используетеsudo, используйте его опцию-E, чтобы сохранить окружение пользователя, что может помочь в доступе к конфигурационным файлам.
Если после выполнения всех этих рекомендаций проблема всё ещё сохраняется, попробуйте запустить SSH с дополнительными параметрами отладки, как это вы уже сделали (используя опцию -v), чтобы получить больше информации о том, что происходит во время попытки подключения.