Como sobrescrever a identidade padrão do SSH?

Question

Versão resumida : como eu posso desabilitar / substituir os locais padrão do arquivo de identidade SSH ~/.ssh/id_{rsa,dsa} e forçar o SSH a usar outro (primeiro)?

Versão longa :

Estou tentando configurar o gitolite com o acesso por chave ssh. Do meu cliente, gostaria de acessar o repositório gitolite-admin com minha identidade ~/.ssh/id_rsa padrão, enquanto criei uma identidade separada ~/.ssh/id_rsa_git para acessar os repositórios normais.

Além disso, criei um alias de SSH em ~/.ssh/config :

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

Agora, quando tento acessar o repositório gitolite como usuário não administrador, obtenho

$ 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).

Isso mostra que minha chave padrão ./ssh/id_rsa é oferecida primeiro e aceita. Mas essa chave não fornece acesso aos repositórios não administrativos, portanto, quero que o SSH ofereça apenas / first ./ssh/id_rsa_git . Como posso fazer isso?

Eu tentei adicionar IdentitiesOnly=yes , mas isso só desativa as chaves do agente ssh. Parece que não há nenhuma opção na configuração ssh (em todo o site ou por usuário) para desativar as identidades padrão, mas também não consigo encontrar uma maneira de especificar sua ordem.

    

Answer 1

Existe uma configuração de SSH Config chamada IdentitiesOnly, cujo padrão é "no". Defina como sim no seu arquivo de configuração (globalmente ou para um host específico) e seu problema deve ser resolvido.

por exemplo, coloque isso em ~ / .ssh / config:

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

Na página Man do 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''.

Eu estava tendo exatamente o mesmo problema (e sendo bloqueado pelo fail2ban). Isso resolveu isso.

    

Answer 2

Acho melhor não armazenar arquivos de identidade (chaves) no diretório ~/.ssh , já que ele é conhecido pelo cliente SSH, o qual (como você observou) tem uma tendência irritante de tentar todas as identidades encontradas neste diretório. diretório, mesmo quando você especificar explicitamente um único arquivo de identidade para ele usar.

Eu armazeno todos os meus arquivos de identidade em outro diretório ( ~/.ssh2 ) que não é conhecido diretamente pelo cliente SSH. O único arquivo em ~/.ssh é config , que contém uma série de {host - > key-to-use} estrofes.

Com essa configuração, a única maneira de o cliente SSH localizar um determinado arquivo de identidade é especificá-lo na linha de comando com -i ou adicionar uma sub-rotina que nomeia o arquivo de identidade em ~/.ssh/config .

    

Answer 3

Não tenho certeza de por que sua configuração não está funcionando como esperado, mas você pode contorná-la passando uma identidade específica para ssh :

ssh -i ./ssh/id_rsa_git git

Da página do manual:

 -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.

Também pode ser porque o host é conhecido. Tente excluir a linha relevante (linha 19) do seu arquivo .ssh/known_hosts e, em seguida, conecte-se novamente.