Чи потрібно називати ключ ssh id_rsa?

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

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

Коли я намагаюся підключитися до Бендер, я отримую наступний вихід із моїм багатослівним ssh-з'єднанням

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bozo/.ssh/.ssh/identity
debug1: Trying private key: /home/bozo/.ssh/.ssh/id_rsa
debug1: Trying private key: /home/bozo/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Він пропонує лише ключ id_rsa, як ви бачите вище. Це правильно? Якщо так, чому? Як змусити її запропонувати більше ключів? Я знаю, що це проблема, яку я бачу з перервами, бо вдома я маю кілька клавіш без особливих проблем.

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

Будь ласка і дякую.

За замовчуванням ssh здійснює пошук id_dsaта id_rsaфайли. Клавіші не повинні називатися таким чином, ви можете назвати його mykeyтак само добре, або навіть помістити його в інший каталог. Однак якщо ви робите будь-який з цих, вам потрібно чітко посилатися на ключ у команді ssh, як-от так:

ssh user@server -i /path/to/mykey

Якщо команда не приймає -i, наприклад sshfs, скористайтеся IdentityFileопцією:

sshfs -o IdentityFile=/path/to/mykey user@host:/path/on/remote /mountpoint

Як це працює

При генерації ключа ви отримаєте два файли: id_rsa(приватний ключ) та id_rsa.pub(відкритий ключ). Як свідчать їх назви, приватний ключ слід зберігати в таємниці, а відкритий ключ можна публікувати.

Аутентифікація відкритого ключа працює з відкритим і приватним ключем. І клієнт, і сервер мають свої власні ключі. При встановленні openssh-serverсервера публічні та приватні ключі генеруються автоматично. Для клієнта вам доведеться це зробити самостійно.

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

Сервер перевіряє, чи дозволено вам підключитися (визначено в /etc/ssh/sshd_config) і чи вказаний ваш відкритий ключ у ~/.ssh/authorized_keysфайлі. Можливі причини заборони відкритого ключа:

• /etc/ssh/sshd_config:
  • AllowUsersабо AllowGroupsвказано, але користувач вашого сервера не вказаний у списку груп або користувачів (за замовчуванням не визначено, що не обмежує користувачів або груп увійти в систему).
  • DenyUsersабо DenyGroupsвказано, і ви знаходитесь у списку користувачів або груп.
  • Ви намагаєтесь увійти як root, але PermitRootLoginвстановлено значення No(за замовчуванням yes).
  • PubkeyAuthenticationвстановлено No(за замовчуванням yes).
  • AuthorizedKeysFileвстановлено в іншому місці, і відкриті ключі до цього файлу не додаються (за замовчуванням .ssh/authorized_keysвідносно домашнього dir)
• ~/.ssh/authorized_keys: ваш відкритий ключ не доданий у цей файл (зауважте, що цей файл читається як користувач root)

Використання декількох клавіш

Не рідкість використовувати кілька клавіш. Замість бігу ssh user@host -i /path/to/identity_file, ви можете використовувати файл конфігурації ~/.ssh/config.

Загальні параметри - IdentityFile (клавіші) та порт. Наступна конфігурація перевірятиме "id_dsa" та "bender" лише при з'єднанні з ssh youruser@yourhost:

Host yourhost
   IdentityFile ~/.ssh/id_dsa
   IdentityFile ~/.ssh/bender

Якщо ви відмовитеся Host yourhost, налаштування застосовуватимуться до всіх з'єднань SSH. Інші параметри також можуть бути вказані для цього хостового матчу, наприклад User youruser, Port 2222і т. Д. Це дозволить вам з'єднатися зі скороченням ssh yourhostзамість ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender.

Мій улюблений метод дозволяє автоматично вибирати приватний ключ

IdentityFile ~/.ssh/%l_%r@%h_id_rsa

SSH замінить% l іменем локальної машини,% r - віддаленим іменем користувача, і% h - віддаленим хостом, таким чином, якщо я хотів би підключитися зі своєї машини під назвою foo до bar як користувача, я запускаю:

ssh bar

І ssh автоматично використовуватиме:

~/.ssh/foo_user@bar_id_rsa

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

Враховуючи коментар StevenRoose про те, що вказувати багато клавіш потрібно більше часу, і я, мабуть, розгулююся з великою кількістю клавіш, я хотів би запропонувати своє особисте рішення.

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

Тут я зв'язав свої ключі для машин під управлінням virtualbox:

$ cd .ssh/
$ ln -s adam_vbox-id_rsa.pub id_rsa.pub
$ ln -s adam_vbox-id_rsa id_rsa

$ ls -l
total 12
-rw------- 1 adam adam 1675 2013-10-04 02:04 adam_vbox-id_rsa
-rw-r--r-- 1 adam adam  396 2013-10-04 02:04 adam_vbox-id_rsa.pub
lrwxrwxrwx 1 adam adam   16 2013-10-04 02:17 id_rsa -> adam_vbox-id_rsa
lrwxrwxrwx 1 adam adam   20 2013-10-04 02:17 id_rsa.pub -> adam_vbox-id_rsa.pub
-rw-r--r-- 1 adam adam 3094 2013-10-04 02:09 known_hosts

Можна також додати дійсно швидкий скрипт для переходу на інший набір без необхідності знову вводити команду ln .

Знову ж таки, це не рішення лише для двох клавіш, але для більшої кількості це може бути працездатним.