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

Несмотря на всю доступную информацию, я озадачен входами без пароля. Помогите?

Итак, у меня есть домашний компьютер и сервер. Я хочу, чтобы сервер мог подключаться к моему домашнему компьютеру по SSH без пароля. Я следил за различными руководствами и могу использовать ssh из домой к сервер без пароля. Все нормально работает. Когда я пытаюсь отменить процесс и ssh из сервер к домой Я получаю в разрешении отказано (публичный ключ) ошибка. Я могу войти на обе машины, используя пароль.

Соответствующие биты из подробной попытки следующие:

   debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).

Мой файл / etc / ssh / sshd_config на домашнем ПК выглядит так:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  ~/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords yes

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

Домашний ПК работает под управлением Ubuntu, а сервер - CentOS.

Ваша строка AuthorizedKeysFile должна читать AuthorizedKeysFile .ssh/authorized_keys. Также убедитесь, что права доступа к вашему каталогу .ssh 700 и разрешения для вашего файла authorized_keys 600.

BinaryOrganic ... Я просмотрел ваше сообщение и увидел, что ваш файл / etc / ssh / sshd_config имеет параметр записи, который вызывает ваш сбой и это сообщение об ошибке.

В прошлом у меня и других не было проблем с использованием логинов клиента x2go в Ubuntu / Debian x2goservers.

Однако когда-то за последний год или два из обновлений ОС Ubuntu и Debian что-то изменилось, что привело к тому, что обычный профиль сеанса x2goclient, требующий ввода идентификатора пользователя и пароля, не смог бы выдать сообщение об ошибке на клиенте, в котором говорится:

В доступе отказано. Аутентификация, которая может продолжаться: открытый ключ, интерактивная клавиатура

Я наконец выяснил причину такого изменения поведения и вот как это исправить.

Получите сеанс терминала с вашим x2goserver и отредактируйте / etc / ssh / sshd_config

sudo nano / etc / ssh / sshd_config

в / etc / ssh / sshd_config (пример был скопирован из Ubuntu 12.04) вы увидите следующие записи:

* # Измените на yes, чтобы включить пароли запроса-ответа (остерегайтесь проблем с некоторыми модулями и потоками PAM)

* # ChallengeResponseAuthentication да

* # Измените на no, чтобы отключить туннелированные пароли в открытом виде

Пароль Аутентификации нет **

Чтобы исправить это ИЗМЕНЕНИЕ ПарольАутентификация к "да"и сохраните файл и перезапустите ssh

sudo /etc/init.d/ssh перезапуск

ПРИЧИНА отказа и изменение поведения от предыдущих / более старых версий Ubuntu. Я установил несколько более старых версий Ubuntu, вернувшись к Ubuntu 9.10, и обнаружил, что установка Ubuntu Server изменила содержимое файла / etc / ssh / sshd_config!

В старых системах запись для проверки подлинности пароля говорила:

# Измените на no, чтобы отключить туннелированные пароли в открытом виде

# PasswordAuthentication нет

где строка PasswordAuthentication была закомментирована ... что затем по умолчанию было "YES"

-или-

строка проверки подлинности пароля была фактически раскомментирована, НО установлена на "ДА"

# Измените на no, чтобы отключить туннелированные пароли в открытом виде

ПарольАутентификация да

Таким образом, эти более старые версии ОС и x2go будут работать с использованием идентификаторов входа и паролей.

Когда-то во время одного из выпусков Ubuntu 11.x запись PasswordAuthentication была фактически изменена на «нет», как в случае с серверами Ubuntu 12.04, и строка была оставлена без комментариев, поэтому она была активной ...

# Измените на no, чтобы отключить туннелированные пароли в открытом виде

Пароль Аутентификация нет

Вот что вызвало сбой входа в систему x2go с использованием паролей и представило пользователю это сообщение об ошибке:

В доступе отказано. Аутентификация, которая может продолжаться: открытый ключ, интерактивная клавиатура

Я внес это изменение сейчас и больше не вижу проблемы на своих серверах, поэтому я хотел поделиться этой информацией, так как мои поиски в Google по этому сообщению об ошибке показали, что многие люди публикуют ту же ошибку при использовании множества других инструментов удаленного доступа ( freenx, x2go, NoMachine NX и т. д.). Надеюсь, это тебе тоже поможет.

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

PermitRootLogin да

Это действительно должно быть отказом. Это разумный дополнительный уровень защиты.

RSAAuthentication да

Сделайте это "нет". Это относится к ssh v1, который вам не нужен, если вы говорите.

PermitEmptyPasswords да

Изменить на нет.

ChallengeResponseAuthentication да

Если вы используете открытый ключ, вам не нужно включать CHAP, поэтому не стоит.

Учтите это:

MaxAuthTries 3

Заставить злоумышленника повторить первоначальное рукопожатие в качестве штрафа за три неудачные попытки в сеансе.

MaxStartups 5 # максимальное количество одновременных сессий ssh, для домашнего пользователя должно хватить 5

Вероятно, вам следует изменить эту строку:

AuthorizedKeysFile ~ / .ssh / authorized_keys

к этому

AuthorizedKeysFile .ssh / authorized_keys

Вы создали пользовательский ключ на сервере, а затем скопировали ЭТО открытый ключ в .ssh / authorized_keys в своем домашнем ящике?

Более простой вариант - создать свой ключ с помощью обычной команды ssh-keygen ..., а затем использовать команду ssh-copy-id для перемещения открытого ключа на другую машину.

ssh-keygen (follow the prompts)
ssh-copy-id -i ~/.ssh/id_rsa.pub me@home_system

измените id_rsa.pub на любой выбранный вами метод ключа (параметры строки cmd для ssh-keygen), конечно.

Помните, что ключи ssh односторонние ... ОТ сюда ДО туда. поэтому, если вы хотите использовать вход без пароля, идущий по другому пути, вам также необходимо это настроить.