Не позволить клиенту ssh предложить все открытые ключи, которые он может найти?

32

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

Есть ли способ сказать моему SSH-клиенту не предлагать все SSH-ключи?

ssh public-key private-key

— Рори
источник

2

Почему вы хотите разные ключи для каждого хоста? Ключи также могут быть разделены между хостами в пределах одного административного домена. Очевидно, что вы бы использовали один ключ для своих рабочих машин, а другой - для своих частных машин, но какова логика использования отдельного ключа для каждой машины в работе?

— Алекс Холст

@AlexHolst Я использую много ключей. У меня есть шифрование по умолчанию (которое требует от меня ввода пароля) для внутренней инфраструктуры. У меня есть другой, не зашифрованный (без пароля), который я использую для одной конкретной службы, где я не мог использовать агент и не хотел каждую минуту вводить пароль. У меня есть другие для соединений, которые не являются частью нашей внутренней инфраструктуры. Это хорошая практика, потому что, хотя для кого-то должно быть довольно сложно восстановить закрытый ключ из открытого ключа, это можно сделать. например, ошибка openssh Debian несколько лет назад ...

— Гюйгенс

@Huygens Я хотел бы увидеть ваш документ по анализу рисков, который привел к выводу, что вам нужно использовать несколько ключей SSH, но хорошо иметь ключи с открытым текстом. Вы можете опубликовать ссылку?

— Алекс Холст

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

— Гюйгенс

31

Это ожидаемое поведение в соответствии с man-страницей 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

Исправьте это должен был быть принятый ответ.

— JM Becker

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

— ryanc
источник

Это просто добавляет к целевому ключу конец списка, что не решит проблему. IdentitiesOnlyтолько с этим будет.

— Джо Ретт