Моя машина недавно перестала принимать входящую аутентификацию с открытым ключом. У меня есть рабочий стол Ubuntu 11.04, который я использую с компьютера Windows. Я использую замазку с театрализованным представлением. Я могу подключиться, но только с интерактивной аутентификацией по паролю, а не с моим ключом rsa, который я настроил.
Я уже проверил, что ключ указан в ~ / .ssh / authorized_keys. Как мне это исправить и что я проверяю?
Если аутентификация с открытым ключом не работает: убедитесь, что на стороне сервера ваш домашний каталог (~
), каталог ~/.ssh
и файл ~/.ssh/authorized_keys
доступны для записи только их владелец . В частности, ни один из них не должен быть доступен для записи группе (даже если пользователь в группе один). chmod 755
или chmod 700
- в порядке, chmod 770
- нет.
Что нужно проверить, если что-то не так:
ssh -vvv
, чтобы увидеть много результатов отладки. Если вы публикуете вопрос с вопросом, почему вы не можете соединиться с ssh, включите этот вывод (вы можете захотеть анонимизировать имена хостов и пользователей). /var/log/auth.log
. Я бы позаботился о том, чтобы у вас были правильные настройки в / etc / ssh / sshd_config.
Чтобы принудительно использовать только PKI и запретить пароли, найдите строку
#PasswordAuthentication yes
в вашем файле, раскомментируйте ее и установите значение
PasswordAuthenticate no
. баланс настроек, чтобы убедиться, что они имеют смысл. В частности, постарайтесь убедиться, что вы используете ключи RSA, поскольку известно, что DSA скомпрометирован.
Если вы проверите разрешения для каталогов, и там есть «.» сразу после них у вас может быть включен selinux, что приведет к путанице с обменом ключами, и по умолчанию будет установлена идентификация пароля вручную.
Вы можете отключить SELinux для устранения неполадок, следуя инструкциям здесь: http://www.centos.org/docs/5/html/5.1/Deployment_Guide/sec-sel-enable-disable-enforcement .html , или просто отредактируйте файл / etc / selinux / config и измените его с «принудительного» на «отключенный».
Надеюсь, это поможет.
Я столкнулся с тем же и, наконец, понял, что это потому, что я зашифровал мой домашний каталог. SSH не может прочитать файл author_keys до тех пор, пока вы не войдете в систему, поэтому в основном он заставляет вас сначала пройти аутентификацию по паролю. См. Раздел о зашифрованном домашнем каталоге по следующей ссылке:
https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Encrypted_Home_Directory
Так или иначе это работало на меня:
root@kaiser: энергия ~#/etc/ssh/sshd_config
Измените эту строку от да до № 28 StrictModes нет
Попробовать еще раз
sysadmin@suselinux1: ~> подставляют Приветствие кайзера системного администратора к Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-25-универсальный i686)
Последний вход в систему: пятница 9 ноября 15:40:11 2012 от 10.1.3.25 sysadmin@kaiser:~ дата $ соперничает 9 ноября 17:53:11$ CST 2012 sysadmin@kaiser:~
У меня была та же самая проблема, но изменение разрешений с помощью chmod
не помогло, так как оказалось, что у меня нет владельца файла ~/.ssh/authorized_keys
. Вы можете изменить владельца каталога .ssh
с помощью:
sudo chown -R "$USER" ~/.ssh
Я исправил эту проблему, сняв комментарий «PasswordAuthentication yes» в / etc / ssh / sshd_config.
Одной из возможных причин проблемы является то, что у вас есть ключи DSA, но теперь SSH (по-видимому) по умолчанию требует наличия ключей RSA. У меня проблема при обновлении до 16.04. Вы можете увидеть больше здесь , но краткий ответ - добавить следующее к ~/.ssh/config
:
PubkeyAcceptedKeyTypes ssh-dss
Из-за необходимости устранения неполадок связи между двумя разными машинами у меня было два закрытых ключа в ~/.ssh
на стороне клиента.
Вместо того чтобы настраивать каждый хост-сервер с соответствующим закрытым ключом в ~/.ssh/identity
, как я должен был сделать, у меня был вторичный (и в данном случае неправильный) ключ, настроенный для всех хостов:
Host *
IdentityFile ~/.ssh/identity_b
Исправление ~/.ssh/identity
решило проблему:
Host a
IdentityFile ~/.ssh/identity_a
Host b
IdentityFile ~/.ssh/identity_b