Назад | Перейти на главную страницу

Ошибка входа в SSH с использованием открытого ключа

На локальном хосте работает служба sshd. Созданы две пары ключей rsa для root и user1 используя ssh-keygen. Скопировано из root / .ssh / id_rsa.pub в user1 / .ssh / id_rsa.pub. Сменил разрешения на 600. Пробовал ssh -l user1 localhost и ssh -l root localhost но оба потерпели неудачу с В доступе отказано (открытый ключ, интерактивная клавиатура).. Нужно ли копировать открытый ключ в ~/.ssh папка для обоих пользователей? Что не так с конфигурацией? Почему я не могу подключиться к localhost?

файл /etc/ssh/sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
UsePAM no
AllowUsers user1 root
PermitRootLogin yes

В файле /etc/ssh/ssh_config это раскомментированные строки:

   RSAAuthentication yes
   PasswordAuthentication no
   ForwardX11 no
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no
   PubkeyAuthentication yes

ИЗМЕНИТЬ 1

Я пытаюсь подключиться к localhost. Я должен иметь возможность войти в систему user1, используя только открытый ключ, хотя можно войти в систему как root с открытым ключом и / или паролем.

РЕДАКТИРОВАТЬ 2

Я скопировал cp ~/.ssh/id_rsa.pub /home/user1/.ssh/authorized_keys. Изменены разрешения chmod -R 700 ~/.ssh и chmod -R 700 /home/user1/.ssh. Перезапустил sshd 'service ssh restart'. Но вроде не работает.

РЕДАКТИРОВАТЬ 4

root@ubuntu:~# ssh-copy-id user1@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is 34:29:b6:1b:fe:84:eb:82:85:77:87:f6:25:39:61:5a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Permission denied (publickey,keyboard-interactive).

root@ubuntu:~# ssh-copy-id root@localhost
Permission denied (publickey,keyboard-interactive).

Журнал:

# tail /var/log/auth.log

... ubuntu sshd[8476]: User root not allowed because account is locked

Хорошая статья по устранению неполадок SSH: Проблемы и решения

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

passwd user1
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

  1. Когда вы сталкиваетесь с проблемой ssh'ing на сервере, всегда лучше добавить -v флаг, например 

    $ ssh -v host -l user

  2. В обоих вышеупомянутых случаях открытый ключ (id_rsa.pub) следует добавить в файл .ssh / authorized_keys удаленного пользователя. В вашем случае выше как root, так и user1. Это легко сделать с помощью ssh-copy-id команда.

  3. /var/log/secure будет содержать подсказки относительно того, почему вход в систему не был успешным.

  4. Разрешения каталога должны быть 700 [rwx] (не 600) [rw-]

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

chmod -R 600 ~/.ssh

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

Еще думаю, что нужно переименовать файл из id_rsa.pub в authorized_keys.

Некоторые примечания: Поскольку вы специально отключили аутентификацию по паролю, вы не можете войти с паролем. Я считаю, что вам нужно настроить разрешенных пользователей с некоторыми другими (Match User, возможно, лучший способ двигаться вперед). Кроме того, вам нужно специально разрешить пользователю root (PermitRootLogin установите его в yes).

Имеет смысл дать нам дополнительную информацию о настройках в /etc/ssh/sshd_config, в частности StrictModes (grep StrictModes /etc/ssh/sshd_config). StrictModes настройка, определяющая, насколько чувствительны sshd реагирует на права доступа к файлам и папкам каждого пользователя. ~/.ssh и ~/.ssh/authorized_keys. Вы также не дали нам настройку AuthorizedKeysFile в твоем sshd_config. Очень актуально, если ваш SSH-сервер ищет файл в другом месте, чем вы его поместили.

Но помимо ответов на этот вопрос, для этого может быть множество причин. Проблема в том, что даже несмотря на то, что вы пытались, информации недостаточно, чтобы точно догадаться, что не так.

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

Но позвольте мне дать вам общий метод отладки таких проблем.

Общее устранение неполадок sshd

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

Вы запускаете его из терминала так:

# $(which sshd) -Ddp 10222

Это даст вам много отладочной информации, которая иначе не появилась бы (без -d) или попадут в журналы, если вам повезет.

NB: в $(which sshd) лучший способ удовлетворить sshd требование абсолютного пути. В противном случае вы получите следующую ошибку: sshd re-exec requires execution with an absolute path. В -p 10222 делает sshd прослушивать этот альтернативный порт, переопределяя файл конфигурации - так, чтобы он не конфликтовал с потенциально запущенным sshd экземпляры. Обязательно выберите здесь свободный порт.

Этот метод много раз помогал мне в поиске проблем, будь то проблемы с аутентификацией, проблемы с производительностью или другие типы проблем. Чтобы получить действительно подробный вывод в stdout, используйте $(which sshd) -Ddddp 10222 (обратите внимание на добавленный dd для увеличения многословности). Для дополнительной проверки исправности отладки man sshd.

На стороне клиента ssh может взять -v (вплоть до -vvv), чтобы быть действительно подробным о том, что он делает.

Строка журнала

... ubuntu sshd[8476]: User root not allowed because account is locked

намекает на то, что проблема, поэтому запустите:

sudo passwd -u root

В CentOS selinux может блокировать аутентификацию. Для решения проблемы используйте команду:

restorecon -Rv ~ /. ssh