Як я можу заблокувати власний обліковий запис із віддаленого входу в ssh за допомогою пароля?


10

Я не хочу взагалі відключати віддалений вхід із паролем, але хочу зробити так, щоб мій обліковий запис був доступний лише з аутентифікацією пари ключів (є інші користувачі, які хочуть використовувати паролі для входу). Чи можливо це змінити на основі кожного користувача, в ідеалі без зміни системних налаштувань?

І щоб було зрозуміло, мій обліковий запис має доступ до sudo, тому я не хочу блокувати пароль.

Відповіді:


9

Ви можете використовувати опцію "Збіг" у sshd_config

Матч Вводить умовний блок. Якщо всі критерії в рядку відповідності задовольняються, ключові слова в наступних рядках замінюють задані в глобальному розділі конфігураційного файлу до тих пір, поки не з’явиться інший рядок відповідності або в кінці файлу. [1]

Отже, в кінці цього файлу ви можете вказати:

Match User yourusername
PasswordAuthentication no

Перегляньте man 5 sshd_configвсі доступні варіанти.

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5


Це вже добре, але я хочу побачити, чи можу я обійтися без редагування sshd_config.
phunehehe

2
Зважаючи на те, що ви хочете внести системні зміни, тобто такі, які не впливають на інших користувачів, це, здається, малоймовірно ...
jasonwryan

а як щодо ~ / .ssh / config? Ви намагалися включити налаштування там?
ttyS0

1
AFAK ~ / .ssh / конфігурує для клієнта, а не для сервера.
Адам Биртек

1

Відповідь від jasonwryan буде правильний спосіб зробити це зміна. Єдине доповнення, яке я хотів би зробити, це те, що ви можете встановити збіг груповим, щоб будь-які користувачі групи колеса повинні були використовувати автентифікацію ключів, а інші могли використовувати паролі.

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

Щоб зрозуміти, чому це проблема, уявіть сценарій навпаки. Системний адміністратор (який може змінювати файли конфігурації системи) встановлює систему лише на основі ключових даних для входу. Потім, якийсь користувач приходить і має лише доступ до свого власного файлу користувача та встановлює свій обліковий запис, щоб дозволити автентифікацію пароля, що переосмислює системну політику. Бджола . Проблема безпеки!

Чи пояснює це, чому тип змін, який ви хочете внести, можливий лише з файлу конфігурації системи?


Важко так подумати, оскільки, якби я був звичайним користувачем, який не користується судом, я можу із задоволенням налаштувати свої ключі, а потім заблокувати пароль, зробивши таким чином мій обліковий запис «ключем лише для автентифікації».
phunehehe

Іншою думкою я можу заблокувати свій пароль кожного разу, коли я збираюся вийти, що повинно заборонити весь пароль для мого облікового запису. Потім, як тільки я ввійду в систему за допомогою своїх ключів, я можу знову включити пароль до sudo. Очевидно, це не гарне рішення, але це змушує мене думати, що це можливо.
phunehehe

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

"додавання обмежень для себе, нічого не змінюючи" - це саме те, що я хочу зробити.
phunehehe

@Caleb: Не було б жодних проблем із безпекою в дозволі authorized_keysвстановити більше обмежень, як це хоче phunehehe. Наприклад, authorized_keysможна обмежити певні клавіші певними командами.
Жил "ТАК - перестань бути злим"

0

Додавання обмежень для себе, нічого не змінюючи

Чому б не на стороні клієнта, якщо впевнений, що ssh буде клієнтом, який буде використовуватися для спроб входу? Якщо так, спробуйте внести зміни до ssh_config замість sshd_config. Перевірте параметр "Ні пароля, ні автентифікацію" та "Переповнені автентифікації"

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