Як розблокувати обліковий запис для авторизації ssh відкритого ключа, але не для авторизації пароля?


32

Ssh не дозволить мені ввійти, оскільки обліковий запис заблоковано. Я хочу розблокувати користувача на моєму сервері для авторизації відкритого ключа через ssh, але не вмикати вхід паролем.

Я спробував:

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

Авторизовані записи журналу:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

ви повинні (IMHO) зробити це для всіх користувачів ... простий конфігурація, коли це
робиться

passwd -uце погана ідея. Дивіться відповідь Гілз нижче.
Пітер Дженкінс

Відповіді:


15

Розблокуйте обліковий запис і надайте користувачеві складний пароль, як пропонує @Skaperen.

Відредагуйте /etc/ssh/sshd_configта переконайтеся, що у вас є:

PasswordAuthentication no

Переконайтеся, що рядок не коментований ( #на початку) та збережіть файл. Нарешті, перезапустіть sshdслужбу.

Перш ніж зробити це, переконайтеся, що аутентифікація вашого відкритого ключа спочатку працює.

Якщо вам потрібно зробити це лише для одного (або невеликої кількості) користувачів, залиште PasswordAuthenticationввімкненим і замість цього скористайтеся Match User:

Match User miro, alice, bob
    PasswordAuthentication no

Розмістіть у нижній частині файлу так, як він дійсний до наступної Matchкоманди або EOF.

Ви також можете використовувати Match Group <group name>або запереченняMatch User !bloggs

Як ви згадуєте в коментарях, ви також можете змінити його так, щоб автентифікація пароля була відключена в основній частині конфігурації та використовувати Matchоператори, щоб увімкнути її для кількох користувачів:

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

У мене склалося враження, що Міро хотів вимкнути пароль лише для одного використання. але дивіться мій попередній коментар
Скаперен

@Skaperen - ти цілком можеш мати рацію. Я трохи змінив свою відповідь.
garethTheRed

Цей Matchсинтаксис виглядає добре, але я спробую його перевернути. Увімкнути вхід із паролем для користувачів (кілька кульгавих).
kravemir

@Miro - Це гарна ідея, я додав її до своєї відповіді для подальшого ознайомлення.
garethTheRed

37

Що б ви не робили, не залишайте обліковий запис у залишеному стані passwd -u , з порожнім полем пароля: це дозволяє входити без введення пароля (за винятком SSH, оскільки SSH відмовляється від цього).

Змініть обліковий запис, щоб не було пароля, але розблокуйте. У облікового запису немає пароля, якщо хеш паролів у базі даних паролів не є хесом жодної строки. Традиційно односимвольний рядок типу* або !використовується для цього.

Заблоковані облікові записи також використовують спеціальний маркер у полі пароля, який призводить до того, що рядок не є хешом жодної рядки. Маркер залежить від системи. В Linux passwdкоманда відмічає заблоковані паролі, поставивши a! на початку, і OpenSSH трактує обліковий запис як заблокований, якщо поле починається з! . Інші варіанти Unix, як правило, використовують подібні, але не однакові механізми, тому будьте уважні, якщо ваша база даних паролів поділяється між неоднорідною мережею.

У Linux ви можете відключити доступ до облікового запису на основі пароля, дозволивши доступ до SSH (за допомогою іншого способу аутентифікації, як правило, пари ключів) за допомогою

usermod -p '*' username

Користувач не зможе змінити обліковий запис назад до пароля, оскільки для цього потрібно ввести дійсний пароль.

Якщо ви хочете, можете замість цього налаштувати SSH для відмови в автентифікації пароля, незалежно від того, чи є в облікового запису пароль. Вам все одно доведеться домовитись про те, щоб SSH не вважав обліковий запис заблокованим, тому, наприклад, в Linux вам потрібно буде видалити поле !з паролем (але не роблять поле порожнім - встановіть його, *як пояснено вище ). Щоб вимкнути автентифікацію пароля для SSH, додайте PasswordAuthenticationдирективу до /etc/sshd_configабо /etc/ssh/sshd_config(що б це не було у вашій системі). Використовуйте Matchблок, щоб зробити цю директиву застосованою лише до конкретного користувача; Matchповинні з’явитися блоки

…
Match User username
    PasswordAuthentication no

6
Спасибі - usermod -p '*' usernameспрацював шарм!
Homme Zwaagstra

1
OpenSSHd дозволяє заблокованим користувачам (тобто хешу паролів з !префіксом) входити в систему за допомогою іншого способу аутентифікації, якщо UsePAM yesвін встановлений sshd_config. Це, мабуть, за замовчуванням для більшості дистрибутивів (наприклад, Fedora).
maxschlepzig

1
У мене вбудована система без пам’яті PAM, тому відмінність '*'порівняно '!'- дуже корисна.
jpkotta

8

Вам не потрібно вмикати або встановлювати паролі, і вам справді не слід, якщо ви вже використовуєте сильні клавіші. Просто заблокуйте свій обліковий запис (sudo passwd -l ім'я користувача) із існуючого сеансу та виправте конфігурацію SSH.

Причина, чому це сталося, ймовірно, тому, що ви відредагували один із параметрів демона SSH за замовчуванням (в / etc / ssh / sshd_config).

Змініть це в / etc / ssh / sshd_config та перезапустіть SSH:

UsePAM yes

Загалом, якщо ви не маєте дійсно вагомих причин відключити PAM, я рекомендую вам увімкнути його; включення PAM в SSH дозволить вам все-таки входити в систему, навіть якщо вилучений пароль. Що б ви не робили, не встановлюйте порожній пароль чи подібне ... блокування поля пароля не повинно означати вимкнення всього облікового запису.

Короткий підказок, коли возитися з SSH: тримати ще один сеанс відкритим (в іншому вікні) кожного разу, коли вносите зміни до своєї конфігурації SSH, а потім перевіряйте, чи можете ви все-таки увійти; якщо ви ненавмисно порушили доступ, скористайтеся поточним сеансом, щоб виправити його.

(Відмова: я працюю в Userify, який надає програмне забезпечення для управління ключами SSH.)


0

У мене була ця проблема в CentOS 7. Я звичайний користувач Linux, що базується на Debian, тому я був рибою з води. Я помітив, що на деяких серверах він працював, а лише в одному - не. Audit.log не сказав нічого корисного, а безпечний.лог також нічого не дав. Я виявив, що єдиною реальною різницею були деякі розбіжності в контексті безпеки файлів і каталогів між тими, що працювали, і тими, які не працювали. Отримайте безпеку за допомогою

sudo ls -laZ <user-home>/.ssh

каталогу (я припускаю, що на sshd_config багато за замовчуванням).

Ви повинні побачити деякі ssh_home_tі user_home_tатрибути. Якщо цього немає, використовуйте chconкоманду, щоб додати відсутні атрибути.

Наприклад

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

У моєму випадку я підозрюю, що користувач був створений нестандартним чином. Його домом був каталог в /var/lib.

Більше інформації: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/


-2

розблокувати обліковий запис і змінити пароль на якусь випадкову рядок

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.