Зупинити ssh клієнт пропонувати всі відкриті ключі, які він може знайти?


32

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

Чи є спосіб сказати моєму ssh-клієнту, щоб він не пропонував усі ключі ssh?


2
Чому ви хочете мати різний ключ для кожного хоста? Ключі також можуть бути спільними між хостами в межах одного адміністративного домену. Очевидно, ви б використовували один ключ для своїх робочих машин, а інший для своїх приватних машин, але яка логіка використання окремого ключа для кожної машини на роботі?
Алекс Холст

@AlexHolst Я використовую багато клавіш. У мене за замовчуванням один зашифрований (який вимагає ввести пароль) для внутрішньої інфраструктури. У мене є ще один не зашифрований (без пароля), який я використовую для однієї конкретної послуги, де я не міг використовувати агент, а також не хотів вводити пароль щохвилини. У мене є інші підключення, які не є частиною нашої внутрішньої інфраструктури. Це добра практика, оскільки, хоча хтось повинен бути досить важким відновити приватний ключ із відкритого ключа, це можна зробити. наприклад, Debian openssh bug кілька років тому ...
Huygens

@Huygens Я хотів би побачити ваш документ з аналізу ризику, який призвів до висновку, що вам потрібно використовувати кілька ключів SSH, але наявність чітких текстових ключів - це добре. Чи можете ви опублікувати посилання?
Алекс Холст

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

Відповіді:


31

Це очікувана поведінка відповідно до сторінки людини ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

В основному, вказуючи IdentityFiles просто додає ключі до поточного списку, агент SSH, вже представлений клієнтові.

Спробуйте змінити таку поведінку таким чином у нижній частині .ssh/configфайлу:

Host *
  IdentitiesOnly yes

Ви також можете змінити цей параметр на рівні хосту, наприклад:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

4
Ви також можете використовувати ssh -o "IdentitiesOnly true" -v -A user@hostте, що я використовую для входу в машину, на якій немає жодного з моїх ключів, але я хочу запропонувати переадресацію агента продовжувати. ( -vдля багатослівної налагодження).
eckes

1
@eckes, це приємна порада, але чи не повинно це бути yes(і ні true)?
aexl

IdentitiesOnlyможе не завжди допомогти, можливо, вам доведеться спеціально виключити хост; дивіться superuser.com/questions/859661/…
aexl

38

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

ssh -o 'PubkeyAuthentication no' myhostname.mydomain

3
Ідеально .. Рішення ІМХО
drAlberT

1
Правильно це повинно було бути прийнятою відповіддю.
Дж. М. Бекер

11

Виконуючи рішення Джеймса Снерінгера, ви можете просто встановити ssh_config за рядками:

Host *.mycompany.com
  IdentityFile .ssh/id_dsa_mycompany_main

Host *.mycustomer.com
  IdentityFile .ssh/id_dsa_mycustomer

Host *
  RSAAuthentication no #this should be up top, avoid ssh1 at all costs
  PubkeyAuthentication no

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


2

Подібно до рішення user23413, ви можете повністю відключити аутентифікацію відкритих ключів для певного хоста (або шаблону підстановки):

Host *.example.org
RSAAuthentication no        # SSHv1
PubkeyAuthentication no     # SSHv2

-1

Якщо ви вкажете на певний файл ключа з ssh -i / path / to / key, він використовуватиме лише той, навіть якщо інші завантажені в агент, і вам не буде запропоновано ввести пароль. Ви також можете редагувати ~ / .ssh / config та рекламувати щось подібне ...

Хост foo.example.com
IdentityFile .ssh / id_rsa_foo.example.com

Ви також можете зробити ...

Хост * .example.org
IdentityFile .ssh / id_rsa_example.org


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