Linux ssh: дозволяють аутентифікацію відкритого ключа, не даючи користувачеві права на читання приватного ключа

Користувачі, які увійшли на мій сервер Linux, повинні мати можливість перейти на певний віддалений комп'ютер із обліковим записом за замовчуванням. Для аутентифікації на віддаленій машині використовується відкритий ключ, тому на сервері є відповідний приватний ключ.

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

Як я можу дозволити користувачам відкривати ssh-з'єднання, не надаючи їм доступу до приватного ключа?

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

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

Це одна з причин sudo. Просто дозвольте своїм користувачам запускати одну єдину команду лише за попередньо дозволеними параметрами командного рядка та вирішено найбільш очевидні обходи. напр

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

встановлює sudoтак, що всі члени групи usersможуть виконувати команду ssh як користувач some_uid, не вводячи власний пароль (або пароль облікового запису some_uid), коли вони виконують:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

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

Це здається гарним випадком використання для аутентифікації на основі хоста. Це метод аутентифікації, коли SSH не використовує індивідуальний користувальницький ключ на локальній машині (у цьому випадку на вашому сервері) для аутентифікації; натомість він використовує приватний ключ хоста , той, який зберігається /etc/ssh/і який читається лише користувачем root.

Щоб налаштувати це, вам потрібно створити файл, названий .shostsна віддаленій машині, у домашній каталог користувача, якого ви хочете, щоб люди входили як (не входить ~/.ssh). Файл повинен містити вміст

server-hostname +

звідки server-hostnameім’я вашого сервера, і +це буквальний знак плюс, який служить символом підстановки, що означає "будь-який користувач".

Вам також потрібно переконатися, що віддалений апарат може перевірити ключ хоста сервера, а значить, ключ хоста сервера повинен бути вказаний у тому /etc/ssh/ssh_known_hostsчи ~/.ssh/known_hostsна віддаленій машині. Якщо це ще не так, ви можете налаштувати його, увійшовши у віддалену машину та запустивши

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

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

Ви також можете легко робити такі дії, як дозволити або заборонити певним користувачам доступ до віддаленої машини. Перегляньте довідкові сторінки sshта hosts.equivдеталі.

Одна з проблем цієї установки полягає в тому, що користувачі, які ввійшли у віддалену машину, можуть змінювати .shosts. Вони нічого не можуть зробити, що дозволило б їм увійти до віддаленої машини як інший користувач, але вони могли б відключити свій чи чужий доступ до віддаленої машини. Якщо це турбує, ви можете зробити так, щоб це було зроблено .shostsлише для запису, rootабо щось таке - я не впевнений, чи це працює, але ви можете спробувати і побачити. (Інші методи, як той, що sudoє, схильні до того ж ризику, оскільки користувач завжди може видалити ~/.ssh/authorized_keys.)