ssh запрашивает пароль несмотря на ssh-copy-id

Я уже некоторое время использую аутентификацию с открытым ключом на удаленном сервере для удаленного использования оболочки, а также для монтирования sshfs. После форсирования umount моего каталога sshfs я заметил, что ssh начал запрашивать у меня пароль. Я попытался очистить удаленный .ssh / authorized_keys от любого упоминания локальной машины, и я очистил локальную машину от ссылок на удаленную машину. Затем я повторил свой ssh-copy-id, он запросил у меня пароль и вернулся нормально. Но, о чудо, когда я ssh к удаленному серверу, мне все равно предлагается пароль. Я немного озадачен тем, что может быть проблемой, какие-либо предложения?

sshd получает странные сведения о разрешениях для $ HOME, $ HOME / .ssh (оба каталога) и для $ HOME / .ssh / authorized_keys.

Одна из моих Linux-коробок оказалась с правами drwxrwxrwx в моем каталоге $ HOME. Ящик Arch Linux абсолютно не будет входить в систему с использованием открытых ключей, пока я не удалю разрешение 'w' для группы, другое в моем каталоге $ HOME.

Попробуйте сделать так, чтобы $ HOME и $ HOME / .ssh / имели более строгие разрешения для группы и других. Посмотрим, не позволит ли это сделать sshd.

Требуются следующие разрешения:

• .sshПапка:700 (drwx------)
• Открытый ключ: 644 (-rw-r--r--)
• Закрытый ключ: 600 (-rw-------)

Недавно я тоже столкнулся с этой проблемой.

Это было исправлено путем изменения разрешений $HOMEкаталога. Тем не менее, просто запуск chmod g-w ~/не решил проблему. Кроме того , чтобы chmod g-w ~/я также необходимо изменить права othersна $HOMEкаталог, выполнивchmod o-wx ~/

Все вместе:

chmod g-w ~/
chmod o-wx ~/

Обратите внимание, что я не уверен, было ли o-xэто необходимо, я просто использовал его в качестве меры предосторожности.

Изменение разрешений для папки ~ / .ssh решило мою проблему согласно этому посту на Super User SE .

Возникает ли проблема также при параллельном входе в систему, т.е. если вы пытаетесь смонтировать sshfs во время открытого сеанса ssh? Если нет, то я бы предположил, что у вас есть домашний каталог в зашифрованном виде? В этом случае $HOME/.ssh/authorized_keysстанет доступным для использования на удаленном компьютере только после первого входа в систему (используя ваш пароль).

Обратитесь к https://help.ubuntu.com/community/SSH/OpenSSH/Keys# Устранение неполадок для получения объяснения и необходимого обходного пути.

Я бы опубликовал это как комментарий, но, вероятно, это было бы слишком долго. Я просто хотел добавить, что ssh-copy-idпытается отправить открытый ключ из папки /.sshвнутри вашей $HOMEпапки.

Если вы пытаетесь войти в систему sshкак пользователь root с открытым ключом (сохраните комментарии, связанные с безопасностью), ssh-copy-idвозможно, вы пытаетесь войти в систему с неправильным открытым ключом, если для вашей $HOMEпеременной установлено значение, отличное от /root(например, для домашнего каталога обычного пользователя) ), таким образом, пользователю root будет предложено, потому что открытый ключ root не установлен в удаленной системе.

Вы можете использовать следующую однострочную строку для указания точного открытого ключа:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

Я сталкивался с этим сценарием в дикой природе несколько раз (включая это утро) и подумал, что постараюсь поставить свои 2 цента, на случай, если кто-нибудь окажется в такой же ситуации.

Как упоминали другие участники, это, вероятно, проблема с разрешениями.

Лучший способ диагностировать это - перезапустить демон SSH на удаленном сервере с включенной опцией отладки - обычно это опция -d. Демон OpenSSH очень явный. Например, вы увидите такие сообщения:

Authentication refused: bad ownership or modes for directory /some/path

Причина, по которой открытый ключ не сохранился после перезагрузки, заключалась в том, что домашний каталог моего сервера был зашифрован. (вы делаете это при установке сервера)

Другая возможная проблема заключается в том, что сервер не поддерживает ваш алгоритм ключа. В моем случае я нашел следующие сообщения в своих sshdжурналах ( /var/log/auth.logв моем случае):

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

Если это так, вам нужно включить поддержку этого алгоритма в вашей sshdконфигурации (что может потребовать обновления до более поздней sshdверсии) или переключить ключ на алгоритм, поддерживаемый тем, к которому sshdвы пытаетесь подключиться ,

Поскольку эти вопросы появляются в числе первых результатов поиска при поиске такого поведения, я также добавлю свое решение:

В моем случае это не было связано с разрешениями. По любой причине (не удосуживаясь выяснить, по какой причине на самом деле, поскольку я нашел быстрое решение), при выполнении команды ssh программа не искала правильный файл идентификации. Одним из решений было добавить вручную на удаленном сервере ключ SSH, который пыталась использовать программа SSH. Вы можете наблюдать за тем, что делает программа SSH при выполнении команды, добавив -v к команде:

ssh -v username@your-host-ip-or-domain 

Затем вы просто получаете на своем локальном компьютере любой открытый ключ, для которого SSH-программа пытается найти файл идентификации / закрытый ключ, например, на Mac:

cat ~/.ssh/id_rsa.pub

... и добавьте его в файл author_keys пульта дистанционного управления в:

~/.ssh/authorized_keys

Другим, в моем случае, лучшим решением было добавить собственный хост в мой локальный конфигурационный файл ssh. На моем Mac это:

/Users/my-user-name/.ssh/config

Здесь вы можете добавить, например, что-то вроде этого:

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

Тогда вам просто нужно выполнить:

ssh mynewserver

... и вуаля