Como eu configuro o SSH para que ele não tente todos os arquivos de identidade automaticamente?

Question

Eu tenho colocado meus arquivos de identidade ssh dentro da minha pasta ~ / .ssh /. Eu tenho provavelmente cerca de 30 arquivos lá.

Quando me conecto a servidores, especificarei o arquivo de identidade a ser usado, com algo como

ssh -i ~/.ssh/client1-identity [email protected]

No entanto, se eu não especificar um arquivo de identidade e apenas usar algo assim:

ssh [email protected]

Eu recebo o erro

Too many authentication failures for user123

Entendo que, se nenhum arquivo de identidade for especificado e o ssh puder localizar arquivos de identidade, ele tentará todos eles.

Eu também entendo que posso editar o arquivo ~/.ssh/config e especificar algo como:

Host example.com
PreferredAuthentications keyboard-interactive,password

para evitar que essa conexão tente arquivos de identidade conhecidos.

Então, eu acho que eu poderia mover meus arquivos de identidade para fora do diretório ~/.ssh/ , ou eu poderia especificar cada host que eu quero desabilitar a autenticação do arquivo de identidade no arquivo de configuração, mas há alguma maneira de dizer SSH comprar padrão não busca por arquivos de identidade? Ou para especificar os que procurará?

    

Answer 1

Você pode usar a opção IdentitiesOnly=yes junto com IdentityFile (consulte a página man ssh_config ). Dessa forma, você pode especificar qual arquivo (s) ele deve procurar.

Neste exemplo, ssh irá somente procurar nas identidades dadas nos arquivos ssh_config + os 4 listados na linha de comando (as identidades fornecidas pelo agente serão ignoradas):

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    [email protected]

Os formulários -i e -o IdentityFile= são intercambiáveis.

    

Answer 2

A resposta curta de user76528 está correta, mas acabei de ter esse problema e pensei que alguma elaboração seria útil. Você também pode se preocupar com essa solução se tiver perguntado "Por que o ssh está ignorando minha opção de configuração do arquivo de identidade"?

Primeiramente, diferente de todas as outras opções em ssh_config, o ssh não usa o primeiro IdentityFile que encontra. Em vez disso, a opção IdentityFile adiciona esse arquivo a uma lista de identidades usadas. Você pode empilhar várias opções de IdentityFile , e o cliente ssh tentará todas até que o servidor aceite uma ou rejeite a conexão.

Segundo, se você usar um ssh-agent, o ssh tentará automaticamente usar as chaves no agente, mesmo que você não as tenha especificado na opção IdentityFile (ou -i) do ssh_config. Esse é um motivo comum pelo qual você pode obter o erro Too many authentication failures for user . Usar a opção IdentitiesOnly yes desativará esse comportamento.

Se você for ssh como vários usuários para vários sistemas, recomendo colocar IdentitiesOnly yes em sua seção global de ssh_config e colocar cada IdentityFile nas subseções Host apropriadas.

    

Answer 3

Eu geralmente faço assim:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa [email protected]

As opções são as seguintes:

• -o IdentitiesOnly=yes - diz ao SSH para usar somente as chaves fornecidas pela CLI e nenhuma da $HOME/.ssh ou via ssh-agent
• -F /dev/null - desativa o uso de $HOME/.ssh/config
• -i ~/path/to/some_id_rsa - a chave que você deseja usar explicitamente para a conexão

Exemplo

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa [email protected]
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
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 f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
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,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

Observe na saída acima que ssh identificou apenas a chave privada my_id_rsa via CLI e que ela é usada para conectar-se a algum servidor.

Especificamente, estas seções:

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1

e:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

    

Answer 4

No cenário em que você tem muitas chaves, você invariavelmente encontrará o erro "Muitos erros de autenticação". Se você tiver uma senha e quiser simplesmente usar a senha para fazer login, veja como você faz isso.

Para usar SOMENTE a autenticação por senha e NÃO usar a chave pública e NÃO usar o "teclado interativo" um tanto enganador (que é um superconjunto que inclui senha), você pode fazer isso a partir da linha de comando:

ssh -o PreferredAuthentications=password [email protected]

    

Answer 5

Use o IdentityFile, mas continue usando o ssh-agent para evitar a repetição de frases secretas

A solução aceita de usar IdentitiesOnly yes significa que você nunca poderá tirar proveito do ssh-agent, resultando em repetidos prompts para sua senha ao carregar sua chave.

Para continuar usando ssh-agent e evitar os erros "Muitos erros de autenticação", tente o seguinte:

1. Remova quaisquer scripts de inicialização do console interativo que carreguem automaticamente as chaves em ssh-agent .

2. adicione AddKeysToAgent yes à configuração ssh do seu cliente. Isso solicitará a senha na primeira conexão, mas depois adicionará a chave ao seu agente.

3. use ssh-add -D quando você obtiver erros de 'excesso de autenticação'. Isso simplesmente "redefine" (exclui) o cache do seu agente ssh. Em seguida, tente a conexão novamente na mesma sessão. Você será solicitado a inserir uma frase secreta e, uma vez aceita, ela será adicionada ao seu agente. Como você terá apenas uma chave no seu agente, você poderá se conectar. O ssh-agent ainda está lá para futuras conexões durante a mesma sessão para evitar reprompts.

   Host ex example.com
      User joe
      HostName example.com
      PreferredAuthentications publickey,password
      IdentityFile /path/to/id_rsa
      AddKeysToAgent yes
   

Answer 6

O cliente ssh e o ssh-agent estão se comunicando através de um soquete de domínio Unix cujo nome é especificado para o cliente pela variável de ambiente SSH_AUTH_SOCK (definida pelo agente na sua inicialização).

Assim, para impedir que uma única chamada do cliente consulte o agente, essa variável pode ser definida explicitamente como algo inválido, como uma string vazia;

$ SSH_AUTH_SOCK= ssh user@server

Uma invocação do cliente como essa falhará na comunicação com o agente e só poderá oferecer as identidades disponíveis como arquivos em ~ / .ssh /, ou qualquer especificado na linha de comando usando -i, para o servidor.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

    

Answer 7

Você teve a resposta o tempo todo (quase):

Host *
PreferredAuthentications keyboard-interactive,password

Trabalhei para mim.