Разрешения на закрытый ключ в папке.ssh?

Обычно вы хотите, чтобы разрешения были:

• .ssh каталог: 700 (drwx------)
• открытый ключ (.pub файл): 644 (-rw-r--r--)
• закрытый ключ (id_rsa): 600 (-rw-------)
• наконец, ваш домашний каталог не должен быть доступен для записи ни группе, ни другим 755 (drwxr-xr-x)).

Я предполагаю, что вы имеете в виду, что вы должны вводить системный / пользовательский пароль каждый раз, а ранее вам не приходилось. Ответ cdhowie предполагает, что вы задали пароль / фразу-пароль при генерации ключей, и если вы это сделали, то, как он говорит, вам придется вводить пароль каждый раз, если вы не используете агент ssh.

Я боролся с этим вечно и наконец понял, что нужно. замещать $USER везде с именем пользователя SSH вы хотите войти на сервер. Если вы пытаетесь войти как root вам нужно будет использовать /root/.ssh и т. д. вместо /home/root/.ssh как для некорневых пользователей.

• Домашний каталог на сервере не должен быть доступен для записи другим пользователям: chmod go-w /home/$USER
• Папка SSH на сервере требует 700 разрешений: chmod 700 /home/$USER/.ssh
• Файл Authorized_keys нуждается в 644 разрешениях: chmod 644 /home/$USER/.ssh/authorized_keys
• Удостоверься что user владеет файлами / папками, а не root: chown user:user authorized_keys а также chown user:user /home/$USER/.ssh
• Поместите сгенерированный открытый ключ (из ssh-keygen) в пользователе authorized_keys файл на сервере
• Убедитесь, что домашний каталог пользователя установлен так, как вы ожидаете, и содержит правильные .ssh папка, которую вы изменяли. Если нет, используйте usermod -d /home/$USER $USER чтобы решить проблему
• Наконец, перезапустите ssh: service ssh restart
• Затем убедитесь, что у клиента есть файлы открытого и закрытого ключей в локальном пользователе. .ssh папка и логин: ssh user@host.com

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

Резюме основано на цитатах из man-страницы (ссылка в конце):

Все цитаты из справочной страницы взяты из http://linuxcommand.org/lc3_man_pages/ssh1.html .

Также убедитесь, что ваш домашний каталог не доступен для записи другим пользователям.

chmod g-w,o-w ~

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

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

Фелипе прав: каталог, содержащий ваш каталог.ssh, не должен быть доступен для записи ни группе, ни другим. таким образом chmod go-w ~ следующая логическая вещь, которую нужно попробовать, если вам все равно будет предложено ввести пароль при запуске ssh'ing после запуска ssh-keygen -t rsa; cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keysпри условии, что вы не назначаете фразу-пароль в команде ssh-keygen, а ваш каталог.ssh находится в вашем домашнем каталоге.

Стоит отметить, что текущее руководство OpenSSH (по состоянию наOpenSSH 9.0/9.0p1 (2022-04-08)) обычно предполагает, что владелецauthorized_keysфайл - это пользователь, который аутентифицирует, следовательно илиrw- --- ---в таблице («...чтение/запись для пользователя и недоступно другим»).

Основная причина заключается в том, что демон/сервер SSH OpenSSH обычно работает именно в таком порядке (при условии, что служба ssh работает под управлениемUID 0):

1. Проверяет, существует ли в среде пользователь, который пытается пройти аутентификацию;

   2.1. Если такого нет, делает запрос недействительным (например,May 01 01:12:34 host sshd[123456]: Invalid user user3 from x.x.x.x port 12345);

2. Создает отдельный процесс sshd с UID и GID аутентифицирующего пользователя;

3. В случаеpubkey, новый процесс пытается прочитать «authorized_keys» в настроенных путях.

   3.1. В случае, если новый процесс не может прочитать файл «authorized_keys», он существует, и это делает запрос недействительным.

4. Проверяет пару ключей...

# pstree -pugT:

      systemd(1,1)-+...
             `-sshd(40976,40976)-+-sshd(194915,194915)---sshd(194939,194915,user1)-+-sshd(938266,938266)
                                 |                                                   `-tmux: client(194943,194943)
                                 `-sshd(2129889,2129889)---sshd(2130234,2129889,user2)---sshd(2130615,2130615)

Для подтверждения вышесказанного необходимо исследование источника, однако, подведем итог: сервер OpenSSH в настоящее время считывает файл «authorized_keys» в качестве UID аутентифицирующего пользователя и основного GID.

Если режим «authorized_keys»600и владелец файла не является UID аутентифицирующего пользователя, аутентификация должна завершиться неудачно. Это может быть тот случай, когда файл «authorized_keys» был создан, например, пользователем root.

В этом выпуске параметр sshd_config UsePrivilegeSeparation устарел, что делает разделение привилегий обязательным. Разделение привилегий включено по умолчанию уже почти 15 лет, а песочница включена по умолчанию почти последние пять лет.

Источник: https://www.openssh.com/releasenotes.html.

Связанный: /questions/288022/chtenie-fajlareg-eksportirovannogo-iz-staroj-ustanovki/288029#288029 (...OpenSSH в версии 7.5 устарела опция UsePrivilegeSeparation...)

Не делайте ничего из этого вручную, просто используйте веб-интерфейс Webminс этим плагином и сделайте все это за несколько кликов графического интерфейса!