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

101

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

Quando eu me conectar a servidores, especificarei o arquivo de identidade a ser usado, 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 como isto:

ssh user123@example.com

Eu recebo o erro

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

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

Também entendo que posso editar o ~/.ssh/configarquivo e especificar algo como:

Host example.com
PreferredAuthentications, teclado interativo, senha

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

Portanto, acho que posso mover meus arquivos de identidade para fora do ~/.ssh/diretório ou especificar cada host para o qual desejo desativar a autenticação de arquivos de identidade no arquivo de configuração, mas existe alguma maneira de dizer ao SSH para comprar o SSH padrão, não procurar arquivos de identidade? Ou para especificar os que ele procurará?

— cwd
fonte

4

Re "Eu entendo que é porque ..." - use ssh -vpara descobrir com certeza.

— grawity

101

Você pode usar a IdentitiesOnly=yesopção junto com IdentityFile(consulte a página de manual do ssh_config ). Dessa forma, você pode especificar quais arquivos devem procurar.

Neste exemplo, o ssh procurará apenas as identidades fornecidas nos arquivos ssh_config + as 4 listadas 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 -ie -o IdentityFile=são intercambiáveis.

— init_js
fonte

7

Um exemplo seria bom

— rubo77

1

Não é: IdentitiesOnly yes(sem o "=")?

— Dimitrios Mistriotis

3

@DimitriosMistriotis De acordo com a página de manual ssh_config, qualquer um é 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

IdentitiesOnlynem sempre funciona, talvez você precise excluir um host especificamente; consulte superuser.com/questions/859661/…

— aexl

79

A resposta curta de user76528 está correta, mas eu apenas tive esse problema e achei que alguma elaboração seria útil. Você também pode se importar com esta solução se se perguntar "Por que o ssh está ignorando minha opção de configuração do arquivo de identidade"?

Primeiramente, diferente de todas as outras opções do ssh_config, o ssh não usa a primeira IdentityFileque encontra. Em vez disso, a IdentityFileopção adiciona esse arquivo a uma lista de identidades usadas. Você pode empilhar várias IdentityFileopçõ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á usar automaticamente 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 para o Too many authentication failures for usererro. O uso da IdentitiesOnly yesopção desabilitará esse comportamento.

Se você fizer o ssh como vários usuários em vários sistemas, recomendo colocar IdentitiesOnly yesna seção global do ssh_config e colocar cada um IdentityFilenas subseções Host apropriadas.

— chrishiestand
fonte

5

bem explicado, obrigado. Não é óbvio que esse parâmetro 'IdentitiesOnly' signifique TakeOnlyWhatIExplicitlySpecifyThenFailoverToPassword . E, aparentemente, a chave ./ssh/id_rsa ainda está listada.

— LImbus

Colocar IdentitiesOnly yesna seção global de ssh_config foi o que fez por mim. Obrigado!

— 21315 Jamix

1

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 ter uma entrada diferente para um site específico, por exemplo, Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yescontinuar fornecendo em mykeyvez de specialkey. Certamente não estava claro, até que eu percebi (pela sua resposta) que as entradas do IdentityFile estão empilhadas em uma ordem de avaliação e a última definida será usada. A remoção IdentityFile ~/.ssh/mykeyresolveu o problema e a chave única correta foi usada.

— Ryder

1

Antes de tentar isso, notei que meus git pull/pushcomandos estavam tentando cada identidade carregada no meu agente. Não foi um problema até que, a certa altura, eu tinha muitas chaves.

— Sdkks

21

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- instrui o SSH a usar apenas as chaves fornecidas pela CLI e nenhuma do $HOME/.sshou 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 sshapenas identificou a my_id_rsachave privada via CLI e que ela a usa para conectar-se a um 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).

— slm
fonte

1

Obrigado, esta é a única solução completa. Aparentemente, -F /dev/nullé a peça que falta nas outras respostas.

— leden

10

No cenário em que você tem muitas chaves, você sempre encontrará o erro "Demasiadas falhas de autenticação". Se você possui uma senha e deseja simplesmente usá-la para efetuar login, eis como você o faz.

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

ssh -o PreferredAuthentications=password user@example.com

— Greg Rundlett
fonte

7

Use o IdentityFile, mas continue usando o ssh-agent para evitar reformulações de senha

A solução aceita de usar IdentitiesOnly yessignifica que você nunca poderá tirar proveito do ssh-agent, resultando em repetidas solicitações para sua senha ao carregar sua chave.

Para continuar usando ssh-agente evitar os erros 'Demasiadas falhas de autenticação', tente o seguinte:

Remova todos os scripts de inicialização do console interativo que carregam chaves automaticamente ssh-agent.
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.
use ssh-add -Dquando você receber erros de 'muita autenticação'. Isso simplesmente 'redefine' (exclui) seu cache do ssh-agent. Em seguida, tente a conexão novamente na mesma sessão. Você será solicitado a digitar uma senha e, uma vez aceita, ela será adicionada ao seu agente. Como você terá apenas uma chave em seu agente, você poderá se conectar. O ssh-agent ainda está lá para futuras conexões durante a mesma sessão, a fim de evitar novas solicitações.
```
Host ex example.com
   User joe
   HostName example.com
   PreferredAuthentications publickey,password
   IdentityFile /path/to/id_rsa
   AddKeysToAgent yes
```

— AndrewD
fonte

Aceitará chaves adicionadas ao chaveiro?

— vfclists

2

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

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

$ SSH_AUTH_SOCK= ssh user@server

Uma chamada do cliente como essa falhará na comunicação com o agente e poderá oferecer apenas ao servidor as identidades disponíveis como arquivos ~/.ssh/ou como especificado na linha de comando -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

— biquíni
fonte

Esta é uma ótima resposta. É simples e funciona quando você está usando comandos que usam SSH "sob o capô", como o git. Uma pena que eu não posso votar mais.

— rsuarez 7/08

1

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

Host *
PreferredAuthentications keyboard-interactive,password

Trabalhou para mim.

— Henry Grebler
fonte

8

A pergunta feita sobre como limitar quais chaves públicas são usadas. Esta resposta desativa completamente a autenticação de chave pública.

— chrishiestand

1

I marcado com +1 porque era a resposta que eu estava pesquisando para, graças @Henry Grebler

— matiu

1

adicione isso no final do ~/.ssh/configarquivo para impedir o uso de chaves para servidores que não são de configuração:

Host *
IdentitiesOnly=yes

— Maxim Akristiniy
fonte