Как переопределить идентификатор SSH по умолчанию?

Question

Краткая версия: как я могу отключить / переопределить расположение файла идентификации SSH по умолчанию ~/.ssh/id_{rsa,dsa} и заставить SSH использовать другой (первый)?

Длинная версия:

Я пытаюсь настроить Gitolite с помощью SSH ключа доступа. От моего клиента я хотел бы получить доступ к репозиторию gitolite-admin с моей идентификацией по умолчанию ~/.ssh/id_rsa , в то время как я создал отдельную идентификацию ~/.ssh/id_rsa_git для доступа к обычным репозиториям.

Кроме того, я создал псевдоним SSH в ~/.ssh/config:

Host git
    Hostname <servername>
    User gitolite
    ForwardX11 no
    ForwardAgent no
    GSSAPIAuthentication no
    IdentityFile ~/.ssh/id_rsa_git

Теперь, когда я пытаюсь получить доступ к хранилищу gitolite как пользователь без прав администратора, я получаю

$ ssh -v git true
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/jaap/.ssh/config
debug1: /home/jaap/.ssh/config line 105: Applying options for git
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <servername> port 22.
debug1: Connection established.
debug1: identity file /home/jaap/.ssh/id_rsa_git type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/jaap/.ssh/id_rsa_git-cert type -1
debug1: identity file /home/jaap/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: identity file /home/jaap/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze3
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze3 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA <...>
debug1: Host '<servername>' is known and matches the RSA host key.
debug1: Found key in /home/jaap/.ssh/known_hosts:19
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/jaap/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: Authentication succeeded (publickey).

Это показывает, что мой ключ по умолчанию ./ssh/id_rsa предлагается первым и принимается. Но этот ключ не предоставляет доступ к репозиториям без прав администратора, поэтому я хочу, чтобы SSH предлагал только /first ./ssh/id_rsa_git . Как я могу это сделать?

Я попытался добавить IdentitiesOnly=yes , но это только отключает ключи ssh-agent. Кажется, в конфигурации ssh (для всего сайта или для каждого пользователя) нет возможности отключить идентификаторы по умолчанию, но я также не могу найти способ указать их порядок.

Answer 1

Существует настройка SSH Config под названием IdentitiesOnly, которая по умолчанию имеет значение "нет". Установите значение yes в вашем конфигурационном файле (глобально или для определенного хоста), и ваша проблема должна быть решена.

например, поместите это в ~/.ssh/config:

Host your.server.com
    IdentityFile ~/example/your_new.key
    User your_user
    IdentitiesOnly yes

Со страницы Man для ssh_config:

 IdentitiesOnly
         Specifies that ssh(1) should only use the authentication identity
         files configured in the ssh_config files, even if ssh-agent(1) or a
         PKCS11Provider offers more identities.  The argument to this keyword
         must be ``yes'' or ``no''.  This option is intended for situations
         where ssh-agent offers many different identities.  The default is
         ``no''.

У меня была точно такая же проблема (и заблокирован fail2ban). Это исправило это.

Answer 2

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

Я храню все мои файлы идентификации в другом каталоге (~/.ssh2), который не известен непосредственно клиенту SSH. Единственный файл в ~/.ssh - это config , который содержит серию разделов {host -> key-to-use}.

С этой конфигурацией единственный способ для SSH-клиента найти заданный файл идентификации - это указать его в командной строке с помощью -i или добавить раздел с именем файла идентификации в ~/.ssh/config .

Answer 3

Не уверен, почему ваша установка не работает должным образом, но вы можете обойти это, передав определенную идентификацию в ssh:

ssh -i ./ssh/id_rsa_git git

Со страницы руководства:

 -i identity_file
         Selects a file from which the identity (private key) for
         public key authentication 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.  Identity files may also be speci‐
         fied on a per-host basis in the configuration file.  It
         is possible to have multiple -i options (and multiple
         identities specified in configuration files).  ssh will
         also try to load certificate information from the file‐
         name obtained by appending -cert.pub to identity file‐
         names.

Это также может быть связано с тем, что хост известен. Попробуйте удалить соответствующую строку (строка 19) из файла .ssh/known_hosts и затем снова подключиться.