Parar o cliente ssh de oferecer todas as chaves públicas que encontrar?

32

Como a maioria dos administradores de sistemas, eu uso o openssh o tempo todo. Eu tenho cerca de uma dúzia de chaves ssh, gosto de ter uma chave ssh diferente para cada host. No entanto, isso causa um problema quando estou me conectando a um host pela primeira vez, e tudo o que tenho é uma senha. Eu quero apenas conectar ao host usando uma senha, sem chave ssh neste caso. No entanto, o cliente ssh oferecerá todas as chaves públicas no meu ~/.ssh/(eu sei disso olhando a saída de ssh -v). Como tenho tantas, ficarei desconectado por muitas falhas de autenticação.

Existe alguma maneira de dizer ao meu cliente ssh para não oferecer todas as chaves ssh?

ssh public-key private-key

— Rory
fonte

2

Por que você deseja uma chave diferente para cada host? As chaves também podem ser compartilhadas entre hosts em um único domínio administrativo. Obviamente, você usaria uma chave para suas máquinas de trabalho e outra para suas máquinas particulares, mas qual é a lógica por trás de usar uma chave separada para cada máquina no trabalho?

— Alex Holst

@AlexHolst Estou usando muitas chaves. Eu tenho um padrão criptografado (que exige que eu digite uma senha) para a infraestrutura interna. Eu tenho outro não criptografado (sem senha) que uso para um serviço específico em que não podia usar um agente nem queria digitar a senha a cada minuto. Eu tenho outros para conexões que não fazem parte da nossa infraestrutura interna. É uma boa prática, porque mesmo que deva ser bastante difícil alguém recuperar a chave privada da chave pública, isso pode ser feito. por exemplo, o bug do openssh do Debian há alguns anos ...

— Huygens

@Huygens Eu adoraria ver seu documento de análise de risco que resultou na conclusão de que você precisa usar várias chaves SSH, mas ter chaves de texto não criptografado é bom. Você pode postar um link?

— Alex Holst

@ AlexHolst, você não precisa ser tão "direto". Antes de tudo, minha resposta foi sobre razões para ter vários pares de chaves. Eu acho que te dei várias. Depois, todos nós temos que lidar com peculiaridades e quais não. Eu tenho um sistema de teste para o qual não posso usar um aplicativo que encapsula dados via SSH sem ser solicitado continuamente a senha da chave, tornando o software inutilizável. Parece ser um bug devido a incompatibilidade de versões ou não. Recebo uma notificação por e-mail para qualquer logon SSH e sou o único logon nessa caixa. Portanto, o risco é aceitável.

— Huygens

31

Esse é o comportamento esperado de acordo com a página do manual ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity 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.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Basicamente, especificar IdentityFiles apenas adiciona chaves a uma lista atual que o agente SSH já apresentou ao cliente.

Tente substituir esse comportamento por este na parte inferior do seu .ssh/configarquivo:

Host *
  IdentitiesOnly yes

Você também pode substituir essa configuração no nível do host, por exemplo:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

— Mathias Bynens
fonte

4

Você também pode usar o ssh -o "IdentitiesOnly true" -v -A user@hostque eu uso para fazer login em uma máquina que não possui nenhuma das minhas chaves, mas quero oferecer o encaminhamento de agente para continuar. ( -vpara depuração detalhada).

— Eckes

11

@ cheques que é uma boa dica, mas não deveria ser yes(e não true)?

— aexl 01/10

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

— aexl

38

Embora outros tenham sugerido isso com soluções baseadas em configuração, provavelmente vale a pena ressaltar que você pode fazer isso facilmente apenas uma vez na linha de comando com:

ssh -o 'PubkeyAuthentication no' myhostname.mydomain

— Andrew Ferrier
fonte

3

Perfeito .. A solução IMHO

— drAlberT 21/10

11

Corrija que essa deveria ter sido a resposta aceita.

— JM Becker

11

Seguindo a solução de James Sneeringer, você pode querer definir um ssh_config ao longo das linhas de:

Host *.mycompany.com
  IdentityFile .ssh/id_dsa_mycompany_main

Host *.mycustomer.com
  IdentityFile .ssh/id_dsa_mycustomer

Host *
  RSAAuthentication no #this should be up top, avoid ssh1 at all costs
  PubkeyAuthentication no

Se você se conectar com uma chave específica a muitas máquinas que não estão em um domínio comum, considere fornecer a elas todos os CNAMEs em seu próprio DNS. Eu faço isso com todos os sistemas do cliente.

— Justin Alan Ryan
fonte

2

Semelhante à solução do user23413, você pode desativar completamente a autenticação de chave pública para um host específico (ou padrão curinga):

Host *.example.org
RSAAuthentication no        # SSHv1
PubkeyAuthentication no     # SSHv2

— James Sneeringer
fonte

-1

Se você apontar para um arquivo de chave específico com ssh -i / path / to / key, ele somente o usará, mesmo que outros estejam carregados no agente, e a senha não será solicitada. Você também pode editar seu ~ / .ssh / config e adicionar algo assim ...

Host foo.example.com
IdentityFile .ssh / id_rsa_foo.example.com

você também pode fazer ...

Host * .example.org
IdentityFile .ssh / id_rsa_example.org

— Ryanc
fonte

Isso apenas adiciona à chave de destino no final da lista, o que não resolverá o problema. IdentitiesOnlysomente com essa vontade.

— Jo Rhett