Як дозволити ssh викорінювати користувача лише з локальної мережі?

Я встановив Google-аутентифікатор на машину CentOS 6.5 і налаштував певних користувачів на надання OTP.

Під час редагування /etc/ssh/sshd_configя бачив директиву, PermitRootLoginяка коментується за замовчуванням.

Я хотів би встановити " PermitRootLogin no", але все-таки мати можливість ssh на машину як root тільки з локальної мережі.

Це можливо?

linux ssh centos6

— Ітаї Гано
джерело

Ніколи цього не роби. SSH, як ваші користувачі, а потім використовуйте sudo для підвищення дозволів. Зробіть це так, щоб він залишив паперовий слід, і таким чином ви дізнаєтесь, який обліковий запис було порушено.

— SnakeDoc

@SnakeDoc: Це одна школа думок, але це не чітко, і я б стверджував протилежне. Судо - це величезна складна атакова поверхня, і не те, що я б хотів коли-небудь встановити. SSH pubkey auth є значно меншою поверхнею атаки. Можна входити в журнал, але журнал не дуже корисний, коли користувач (root) може редагувати або видаляти журнали, що завжди має місце, якщо ви не увійдете у зовнішнє сховище, додане лише для додавання.

— R ..

@R .. Якщо правильно налаштувати sudoers, використовуючи принцип найменшого привілею, ці описані вами проблеми здебільшого не є проблемою. Жоден користувач не повинен мати змогу вступити в sudo - suкорінь або вступити або виконувати все, що їх користувачам не потрібно (у судорах ви використовуєте білий список для команд). Якщо вам потрібен корінь, ви повинні фізично бути біля консолі - тобто. Корінь через SSH ніколи не повинен бути дозволений ... ключі чи ні.

— SnakeDoc

@SnakeDoc: Ви помиляєтесь. Судо має як власні складні поверхні атаки, так і фундаментальну складну поверхню атаки, яка властива двійковій інформації, у вигляді всього стану, що успадковується через execve. У деяких випадках помилка в самій програмі suid (suid) навіть не потрібна; помилок в базовій інфраструктурі, такі як динамічний лінкер (наприклад, CVE-2010-3856), може бути достатньо.

— Р ..

@R .. Ви припускаєте, що ви завжди будете знати, якщо ключ просочився. Це одна біса припущення. Крім того, потрапивши до вашого, зловмисник має кореневі привілеї. Ще краще надіслати їх через непривілейований рахунок і змусити їх піднятись до root. Таким чином у вас є ключ, який потрібно просочити, ключову парольну фразу, яку потрібно зламати, а потім звичайний пароль облікового запису користувача, який потрібно зламати. І якщо зловмисник переживає все це ... вони нічого не можуть зробити, тому що цей користувач налаштований під судори з дуже обмеженими можливостями ... Бачите вигоду зараз? Не дозволяти прямого входу в корінь протягом ssh ... періоду. Це хороша гігієна

— SnakeDoc

Відповіді:

Використовуйте Matchпараметр config у /etc/ssh/sshd_config:

# general config
PermitRootLogin no 

# the following overrides the general config when conditions are met. 
Match Address  192.168.0.*
    PermitRootLogin yes

Побачити man sshd_config

— Свен
джерело

Чому я не придумав цього?

— Товариш

Ви також можете обмежити джерело для ключів аутентифікації в ~root/.ssh/authorized_keys. Префікс ключа за допомогою from="192.168.0.0/24 ".

— BillThor

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

— kasperd

FYI Якщо ви додатково використовуєте директиву AllowUser , вам доведеться також (і контр-інтуїтивно) також робитиAllowUser root

— Роберт Ридл,

Match addressМетод вже згадувався, але ви також можете обмежити користувач (або групи), які дозволені для входу на систему. Наприклад, обмежити вхід для користувача itai(з будь-якого місця) таroot (з певної мережі), використовуйте:

AllowUsers itai root@192.168.0.*

Це заважає всім іншим користувачам (наприклад apache) входити через SSH.

Дивіться також AllowUsersключове слово у посібнику sshd_config (5) .

— Лекенштейн
джерело

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

— CVn

@ MichaelKjörling Також AllowGroups означає, що вам не потрібні дозволи на редагування для sshd_config, якщо ваша команда розширюється або скорочується. Це може навіть дозволити більше управлінських типів чи інтернів.

— Nzall

Хороші моменти, зауважте, що ви можете комбінувати варіанти, є, AllowUsers itai root@192.168.0.*і AllowGroups ssh-usersви не випадково

— викличете