SSH, server refused our key. (Решено).

Писал заметочку о CentOS на VPS дошёл до ssh авторизации по ключу. и нормально так встрял аж на две недели)), забегая вперёд скажу, что ошибка была наивная и от того досадной)), но было интересно!

Ну-с, начнём по-порядку расписывать картину моего позора))

  1. Сгенерировал ключики в путти-ген

putty-gen1 putty-gen2 putty-gen3

  1. публичный закинул в хом

pscp

  1. настройки sshd_config

вытягиваем sshd_config

pscp-dl

рассматриваем то, что есть. Оставляем то, что нужно.

4 смена порта

в секции Port пишем нестандартный порт (отобьёт немалую часть срача в логи на предмет неудачной авторизации армии ботов))

5 настройка iptables

не забиываем отметить изменение порта (я так пару раз переустанавливал системы)).

6 PubKeyAuthentication yes

явно указываем аутентификацию по ключу.

7 PasswordAuthentication yes

это отключаем в последнюю очередь

9 user — server refused our key

и вот на этом я встрял — ситуация такова: рут с ключами заходит — пользователь (группа wheel) по ключам не заходит, только по паролю.

Что я только не делал, все рецептики предлагаемые в рунете были вычитаны, осмыслены, применены и нифига)) рут — всё ок, юзер — болт.

Я потерял покой и сон.

Далее пара моментов, которые не помогли в решении, но показались интересными

10 AddressFamily

отключаем поддержку ipv6

11 Очень занятная опция Match

И заодно настроил SFTP.

Проблема была в преднастроенном профиле PuTTY. Профиль для рута был настроен верно, с правильными путями к секурному ключу. А вот профиль пользователя был настроен с путями к старому ключу, не соответствующего паре публичного ключа на сервере)) вот такой я тормаз!


UPD — настройка PuTTY для нормального отображения псевдографики в консоли
Terminal > Keyboard > «The Function keys and keypad» = linux
Window > Translation > Character set — выставляем правильную кодировку
Connection > Data > «Terminal-type string» пишем linux