ssh больше не разрешает проверку открытого ключа

Моя машина недавно перестала принимать входную аутентификацию открытого ключа. У меня есть рабочий стол ubuntu 11.04, который я схожу с Windows-машины. Я использую шпатлевку с конкурсом. Я могу подключиться, но только с интерактивной аутентификацией пароля, а не с моим ключом rsa, который у меня установлен.

Я уже подтвердил, что ключ указан в ~ / .ssh / authorized_keys. Как это исправить и что я проверю?

22
задан 20 October 2011 в 00:27

9 ответов

Если аутентификация с открытым ключом не работает: убедитесь, что на вашей стороне ваш домашний каталог (~), каталог ~/.ssh и файл ~/.ssh/authorized_keys доступны для записи только их владельцем. В частности, ни одна из них не должна быть доступна для записи группой (даже если пользователь одинок в группе). chmod 755 или chmod 700 в порядке, chmod 770 нет.

Что нужно проверить, если что-то не так:

Запустите ssh -vvv, чтобы увидеть много отладочного вывода. Если вы зададите вопрос, почему вы не можете подключиться к ssh, включите этот вывод (вы можете анонимизировать имена хостов и пользователей). Если вы можете, проверьте журналы сервера в /var/log/auth.log. Если аутентификация с открытым ключом не работает, проверьте разрешения снова, особенно групповой бит (см. Выше).
27
ответ дан 25 May 2018 в 17:52
  • 1
    (из тега U & amp; L wiki , скопированного в AU ) – Gilles 20 October 2011 в 23:02
  • 2
    @RexLogan Вот что говорит мое первое предложение ... – Gilles 26 April 2012 в 23:05
  • 3
    Хороший ответ! Я забыл свой homedir: o – RobAu 2 November 2015 в 16:08
  • 4
    Если вы используете последнюю версию ssh (или sshd), DSA-ключи больше не поддерживаются по умолчанию из-за проблем с безопасностью. Единственное реальное решение - перейти на RSA или лучшие клавиши. – Mikko Rantalainen 4 February 2016 в 17:37
  • 5
    Я изменил разрешения моей домашней папки и что? Я был заблокирован из SSH! Я изменил ключи ssh, нет, сервер все еще отказывается от подключения! Я был сумасшедшим, пытаясь найти решение и с вашим ответом chmod 700 в мою домашнюю папку, ssh начал работать !!!!!!! Благодаря! Если мое терминальное соединение было сброшено при попытке найти решение, я был бы полностью заблокирован с сервера. Поэтому будьте осторожны, чтобы не играть с разрешениями вашей домашней папки! (Я только что изменил права на домашнюю папку, а не папку .ssh, но все еще заблокирован SSH) – Tarik 3 September 2017 в 15:17

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

https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Encrypted_Home_Directory

9
ответ дан 25 May 2018 в 17:52

Я хотел бы убедиться, что у вас есть свои настройки в / etc / ssh / sshd_config.

Чтобы принудительно использовать PKI и чтобы запретить использование паролей, найдите строку

#PasswordAuthentication yes 
[d2 ] в вашем файле, раскомментируйте его и установите на

PasswordAuthenticate no

. Я также прочитал бы баланс настроек, чтобы они имели смысл. В частности, постарайтесь убедиться, что вы используете ключи RSA, поскольку DSA известно, что они скомпрометированы.

5
ответ дан 25 May 2018 в 17:52
  • 1
    Вы объясняете, как отключить аутентификацию паролей. Это не поможет выполнить проверку подлинности с открытым ключом (сначала проверяется открытый ключ). Эндрю: не отключайте аутентификацию паролей, пока не убедитесь, что работает аутентификация открытого ключа! – Gilles 20 October 2011 в 19:14

Если вы проверяете права доступа к каталогам и есть "." сразу после них, то вы можете включить selinux, что будет беспорядочно с обменом ключами, а по умолчанию - ручным идентификатором пароля.

Вы можете отключить SELinux для устранения неполадок, следуя инструкциям здесь: http://www.centos.org/docs/5/html/5.1/Deployment_Guide/sec-sel-enable-disable-enforcement.html , или просто отредактируйте файл / etc / selinux / config и измените его с «принудительного» на «отключено».

Надеюсь, это поможет.

3
ответ дан 25 May 2018 в 17:52
  • 1
    Я включил selinux, но отключить его, похоже, не исправить. Что для меня было трюк chmod 600 ~/.ssh/authorized_keys - файл был записан в группу. (через pyrosoft.co.uk/blog/2013/01/12/… ) – David Carboni 13 April 2016 в 19:33

Я исправил эту проблему, не комментируя «PasswordAuthentication yes» в / etc / ssh / sshd_config.

2
ответ дан 25 May 2018 в 17:52

Из-за необходимости устранения неполадок связи между двумя разными машинами у меня было два закрытых ключа в ~/.ssh на стороне клиента.

Вместо настройки каждого хоста сервера с соответствующим закрытым ключом в ~/.ssh/identity, как и следовало бы сделать, у меня был вторичный (и в этом случае неправильный) ключ, настроенный для всех хостов:

Host *
IdentityFile ~/.ssh/identity_b

Исправление ~/.ssh/identity разрешило проблему:

Host a
IdentityFile ~/.ssh/identity_a
Host b
IdentityFile ~/.ssh/identity_b
1
ответ дан 25 May 2018 в 17:52

Одна из возможных причин проблемы заключается в том, что у вас есть ключи DSA, но теперь SSH (по-видимому) по умолчанию требует использования ключей RSA. У меня возникла проблема при обновлении до 16.04. Вы можете увидеть больше здесь, но короткий ответ добавляет следующее к ~/.ssh/config:

PubkeyAcceptedKeyTypes ssh-dss
1
ответ дан 25 May 2018 в 17:52

У меня была такая же проблема, но изменение разрешений с помощью chmod не помогло, так как оказалось, что у меня не было права собственности на файл ~/.ssh/authorized_keys. Вы можете изменить право собственности на каталог .ssh с помощью:

sudo chown -R "$USER" ~/.ssh
0
ответ дан 25 May 2018 в 17:52

Как-то это сработало для меня:

root @ kaiser: ~ # vim / etc / ssh / sshd_config

Измените эту строку от «да» до «нет» 28 «StrictModes no

Повторите попытку

sysadmin @ suselinux1: ~> con sysadmin kaiser Добро пожаловать в Ubuntu 12.04.1 LTS (GNU / Linux 3.2.0-25-generic i686)

Документация: https://help.ubuntu.com/

Последний вход: Пт ноя 9 15:40:11 2012 от 10.1.3.25 sysadmin @ kaiser: ~ $ date vie nov 9 17:53:11 CST 2012 sysadmin @ kaiser: ~ $

-1
ответ дан 25 May 2018 в 17:52
  • 1
    Выполнение чего-либо, не зная, что он делает и почему оно работает, может быть приемлемым, но предлагать то же самое плохо, и быть справедливым, хуже, если речь идет о системе безопасности. – Mahesh 10 November 2012 в 11:17
  • 2
    согласовано. пусть это будет стимулом для создания более совершенных документов sshd, которые точно не попадают в «хорошее чтение в субботу». категория – code_monk 25 December 2014 в 09:24

Другие вопросы по тегам:

Похожие вопросы: