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


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

Quando eu me conecto aos servidores, vou especificar o arquivo de identidade para usar, com algo como

ssh -i ~ / .ssh / client1-identity client1@10.1.1.10

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

ssh user123@example.com

Eu recebo o erro

Muitas falhas de autenticação para o usuário123

Eu entendo que é porque se nenhum arquivo de identidade for especificado e o ssh puder encontrar arquivos de identidade, ele tentará todos eles.

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

Anfitrião example.com
PreferredAuthentications keyboard-interactive, password

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

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


82


origem


Re "Eu entendo que é porque ..." - use ssh -v para descobrir com certeza. - grawity


Respostas:


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

Neste exemplo, o ssh  procure 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 \
    user123@example.com

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


75



A exemplo seria bom - rubo77
Não é: IdentitiesOnly yes (sem o "=")? - Dimitrios Mistriotis
@DimitriosMistriotis De acordo com a página man do ssh_config, é aceitável: Configuration options may be separated by whitespace or optional whitespace and exactly one '='; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option. - Nick Anderegg
@NickAnderegg agradecimentos - Dimitrios Mistriotis


A resposta curta do 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 a minha opção de configuração do arquivo de identidade"?

Em primeiro lugar, ao contrário de todas as outras opções em ssh_config, o ssh não usa o primeiro IdentityFile que encontra. Em vez disso, IdentityFile opção adiciona esse arquivo a uma lista de identidades usadas. Você pode empilhar vários IdentityFile opções, e o cliente ssh tentará todas elas 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. Esta é uma razão comum pela qual você pode obter Too many authentication failures for user erro. Usando o IdentitiesOnly yes opção irá desativar esse comportamento.

Se você ssh como vários usuários para vários sistemas, eu recomendo colocar IdentitiesOnly yes na sua seção global do ssh_config, e colocando cada IdentityFile dentro das subseções Host apropriadas.


69



bem explicado, obrigado. Não é óbvio que esse parâmetro "IdentitiesOnly" signifique TakeOnlyWhatIExplicitlySpecifyThenFailoverToPassword. E aparentemente, a chave ./ssh/id_rsa ainda está listada. - lImbus
Colocando IdentitiesOnly yes na seção global do ssh_config é o que fez para mim. Obrigado! - jamix
Obrigado pelo comentário detalhado. Eu costumava usar ('\' para nova linha) Host * \ IdentityFile ~/.ssh/mykeycomo uma opção de configuração e, a princípio, parecia estranho que ter uma entrada diferente para um site específico, por exemplo Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yes continuou a fornecer mykey ao invés de specialkey. Certamente não ficou claro, até que percebi (a partir de sua resposta) que as entradas do IdentityFile são empilhadas em uma ordem de avaliação e a última definida será usada. Removendo IdentityFile ~/.ssh/mykey resolveu o problema, e a chave única correta foi usada. - Ryder
Antes de tentar isso, notei minha git pull/push os comandos estavam tentando todas as identidades carregadas no meu agente. Não foi um problema até que em um ponto eu tinha muitas chaves. - sdkks


Eu geralmente faço assim:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com

As opções são as seguintes:

  • -o IdentitiesOnly=yes - diz ao SSH para usar somente chaves que são fornecidas via CLI e nenhuma das $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 root@someserver.mydom.com
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 no-more-sessions@openssh.com
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 o my_id_rsa chave privada através do CLI e que ele usa para se conectar ao someserver.

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

15



Obrigado, esta é a única solução completa. Pelo visto, -F /dev/null é a peça que faltava nas outras respostas. - leden


No cenário em que você tem muitas chaves, você invariavelmente vai encontrar o erro "Too many Authentication Failures". Se você tiver uma senha e quiser simplesmente usar a senha para fazer login, veja como você faz isso.

Para usar APENAS 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 user@example.com

9





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 evite os erros "Muitos erros de autenticação", tente isto:

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

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

  3. usar ssh-add -D quando você recebe erros de 'muita 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 conexões futuras 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
    

4



Irá aceitar as chaves adicionadas ao chaveiro? - vfclists


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

Host *
PreferredAuthentications keyboard-interactive,password

Trabalhou para mim.


0



A pergunta foi feita sobre como limitar quais chaves públicas são usadas. Essa resposta desativa totalmente a autenticação de chave pública. - chrishiestand
Eu + 1'd porque era a resposta que eu estava pesquisando, obrigado @Henry Grebler - matiu


O cliente ssh e o agente ssh 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 inicialização).

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

$ SSH_AUTH_SOCK= ssh user@server

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

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

0