Добавление открытого ключа в ~ / .ssh / authorized_keys не приводит меня к автоматическому входу в систему

Отчаявшиеся могут также убедиться, что у них нет лишних символов новой строки в файле authorized_keys из-за копирования текста файла id_rsa.pub из сбитого с толку терминала.

Перечисление открытого ключа в .ssh / authorized_keys необходимо, но недостаточно для того, чтобы sshd (сервер) принял его. Если ваш закрытый ключ защищен парольной фразой, вам нужно будет каждый раз передавать парольную фразу ssh (клиенту). Или вы можете использовать ssh-agent или эквивалент GNOME.

Ваша обновленная трассировка соответствует закрытому ключу, защищенному парольной фразой. См. Ssh-agent или используйте ssh-keygen -p.

Далее user - ваше имя пользователя.

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

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

Попробуйте "ssh-add", который у меня сработал.

В конце концов, мне удалось помочь мне убедиться, что владелец / группа не был root, а user:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user

Поищите в файле /var/log/auth.log на сервере sshd ошибки аутентификации.

Если ничего не помогает, запустите сервер sshd в режиме отладки:

sudo /usr/sbin/sshd -ddd -p 2200

Затем подключитесь с клиента:

ssh user@host -p 2200

В моем случае я нашел в конце раздел ошибок:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Обладая этой информацией, я понял, что мой sshd_config файл ограничивал вход в систему для членов группы ssh. Следующая команда исправила эту ошибку разрешения:

sudo usermod -a -G ssh NEW_USER

Выполните их в командной строке:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

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

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

В моем случае мне нужно было поместить свой authorized_keys файл в .openssh.

Это местоположение указано в /etc/ssh/sshd_config в параметре AuthorizedKeysFile %h/.ssh/authorized_keys.

Еще один совет, который следует запомнить: начиная с версии 7.0 OpenSSH по умолчанию отключает ключи SSH DSS / DSA из-за их унаследованной слабости. Поэтому, если у вас OpenSSH v7.0 +, убедитесь, что ваш ключ не ssh-dss.

Если вы застряли с ключами DSA, вы можете повторно включить поддержку локально, обновив свои файлы sshd_config и ~/.ssh/config такими строками: PubkeyAcceptedKeyTypes=+ssh-dss

Убедитесь, что у целевого пользователя установлен пароль. Запустите passwd username, чтобы установить его. Это было необходимо для меня, даже если пароль для входа в SSH был отключен.

Еще одна проблема, о которой вы должны позаботиться: если ваши сгенерированные имена файлов не соответствуют значениям по умолчанию id_rsa и id_rsa.pub.

Вам необходимо создать файл .ssh / config и вручную определить, какой файл id вы собираетесь использовать с подключением.

Пример здесь:

Host remote_host_name
    HostName 172.xx.xx.xx
    User my_user
    IdentityFile /home/my_user/.ssh/my_user_custom

Просто посмотрите файл /var/log/auth.log на сервере. Установка дополнительной детализации с помощью -vv на стороне клиента не поможет, потому что сервер вряд ли предложит слишком много информации возможному злоумышленнику.

Моя проблема заключалась в изменении AuthorizedKeysFile, когда автоматизация для заполнения / etc / ssh / authorized_keys еще не была запущена.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Убедитесь, что вы скопировали весь открытый ключ в authorized_keys; префикс ssh rsa необходим для работы ключа.

Я выполнил sudo chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys и chmod go-w $HOME $HOME/.ssh из предыдущего ответа, и это устранило мою проблему на CentOS 7 ящик, в котором я испортил разрешения, пытаясь заставить работать общие ресурсы Samba .

Похоже на проблему с разрешением. Обычно это происходит, если права доступа к какому-либо файлу / каталогу настроены неправильно. В большинстве случаев это ~/.ssh и ~/.ssh/*. В моем случае это /home/xxx.

Вы можете изменить уровень журнала sshd, изменив файл /etc/ssh/sshd_config (найдите LogLevel и установите для него значение DEBUG), а затем проверьте вывод в файле /var/log/auth.log, чтобы узнать, что именно произошло.

Это решает мою проблему:

ssh-agent bash

ssh-add

Вам необходимо проверить свойства файлов.

Чтобы назначить необходимое свойство, используйте:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

Я так и использую.

cat ~/.ssh/id_rsa.pub| ssh user@remote-system 'umask 077; cat >>~/.ssh/authorized_keys'

В этой заметке убедитесь, что в вашей конфигурации sshd есть такая строка:

PermitRootLogin without-password

Установите, как указано выше, а затем перезапустите sshd (/etc/init.d/sshd restart).

Выйдите из системы и попробуйте войти снова!

Я считаю, что по умолчанию это:

PermitRootLogin no

В моем случае это потому, что группа пользователя не указана в AllowGroups файла конфигурации / etc / ssh / sshd_config. После добавления все работает нормально.

У меня домашний каталог находится в нестандартном месте, и в журналах sshd есть следующая строка, даже если все разрешения были в порядке (см. Другие ответы):

Не удалось открыть авторизованные ключи '/data/home/user1/.ssh/authorized_keys': в доступе отказано

Я нашел здесь решение: в RHEL 6.5

В моем конкретном случае:

• В /etc/selinux/targeted/contexts/files/file_contexts.homedirs добавлена ​​новая строка:

• Это исходная строка для обычных домашних каталогов:

  /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• Это моя новая строка:

  /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• Затем следует restorecon -r /data/ и sshd перезапуск.

У меня была эта проблема, и ни один из других ответов не решил ее, хотя, конечно, другие ответы были правильными.

В моем случае оказалось, что сам каталог /root (не например, /root/.ssh) имел неправильные разрешения. Мне было нужно:

chown root.root /root
chmod 700 /root

Конечно, эти разрешения должны быть примерно такими (может быть chmod 770) в любом случае. Однако это специально препятствовало работе sshd, хотя и /root/.ssh, и /root/.ssh/authorized_keys имели правильные разрешения и владельцев.

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

Допустим, есть пользователь с SSH-входом с именем userA и пользователь с именем userB, не входящий в SSH-вход. userA также имеет группу userA. Я изменил userB, чтобы также иметь группу userA. Это привело к описанному поведению, так что userA не смог войти в систему без приглашения.

После того, как я удалил группу userA из userB, логин без приглашения снова заработал.

У меня были те же проблемы с тех пор, но сегодня мне пришлось настроить один новый сервер. Что я смог узнать за это время ...

Базовый процесс разрешения аутентификации без пароля выглядит следующим образом:

1. На сервере проверьте, есть ли в вашей домашней папке .ssh папка. Если он не существует, вы можете создать его вручную с помощью команды mkdir, а затем назначить правильные разрешения с помощью chmod, или же вы можете использовать ту же утилиту ssh-keygen для создания частных / открытых ключей, но на сервере для вашего Пользователь. В результате будет создана необходимая папка .ssh.

2. На локальном компьютере вам также необходимо создать закрытый / открытый ключи с помощью утилиты ssh-keygen.

3. Вам нужно переместить свой открытый ключ в файл .ssh/authorized_keys на сервере. Для этого можно использовать служебную программу ssh-copy-id или сделать это вручную с помощью команд cat и scp.

4. В лучшем случае это позволит подключиться к вашему серверу без пароля.

Хорошо, теперь проблемы, которые я обнаружил сегодня: сначала есть несколько алгоритмов генерации ключей: rsa, dsa, ecdsa и ed25519, и есть много выпусков OpenSSH (вы можете иметь одну версию на вашем локальном компьютере и старую версию на вашем сервере) :

Подсказка: Использование ssh -v помогает увидеть дополнительную информацию при подключении к серверу.

OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f 31 Mar 2020

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3

Ошибка в моем сегодняшнем случае заключалась в том, что я пытался использовать ключ с алгоритмом нового поколения, который не поддерживался установленной версией OpenSSH на сервере. Когда я проверил поддерживаемые алгоритмы, я обнаружил еще одну ошибку: сервер отклонял мой алгоритм:

debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

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

Примечания к выпуску OpenSSH: Ссылка