Verifique quais chaves ssh são aceitas no servidor

Question

Eu tenho um diretório cheio de chaves privadas ssh e gostaria de verificar quais teclas são aceitas em qual servidor sem efetuar login. Como posso fazer isso sem adicionar as chaves ssh ao meu cliente de autenticação com o ssh-add? ou logar no servidor? Como o ssh sabe com quais chaves ele deve tentar autenticar? O servidor envia as impressões digitais das chaves que pode usar ou o cliente envia todas as impressões digitais e o servidor as verifica?

    

Answer 1

Você pode usar algo como:

#!/bin/bash

KEYPATH=~/.ssh/*
HOSTS=( localhost hosta hostb )

probekey ()
{
    for privkey in $KEYPATH
    do
    if [[ "$(file $privkey)" =~ "private" ]]
    then
        #echo "Probing key $privkey for host $1"
            ssh -i "${privkey}" -o "IdentitiesOnly yes" -o "PreferredAuthentications publickey" -o "ControlMaster no" "$1" exit 2>/dev/null
            if [ "$?" == "0" ]
            then
            echo "Key ${privkey} matches for host $1"
        fi
    fi
    done
}

for HOST in ${HOSTS[@]}
do
    probekey $HOST
done

O que este script basicamente faz é percorrer uma matriz de hosts ( $HOSTS ) e executa a função probekey . A função itera através da lista de arquivos em $KEYPATH , verifica se o tipo de arquivo contém private (para arquivos de chave privada RSA ou DSA) e, se isso corresponder, iniciará uma conexão ssh com o host usando essa chave específica. Se a conexão foi bem sucedida, o código de retorno é 0 e uma mensagem é impressa.

Esta não é uma resposta exata para a pergunta, porque faz login no host (quando uma chave corresponde) e executa o comando exit para efetuar logout diretamente novamente.

    

Answer 2

Você não pode verificar quais teclas são aceitas no servidor sem efetuar login. A única maneira de saber se uma chave é aceita é tentar fazer login com ela.

Se houvesse uma maneira de listar quais chaves são aceitas para uma conta, isso seria uma violação da privacidade e tornaria as violações mais fáceis em algumas circunstâncias. O SSH nem mesmo informa se o nome da conta é válido: um login negado é um login negado, seja porque o nome da conta não é conhecido ou porque os dados de autenticação são inválidos. Fazer o contrário, pelo menos, violaria a privacidade, expondo quem tem uma conta na máquina. Também tornaria os ataques de força bruta contra contas com senhas fracas mais fáceis e mais difíceis de detectar em logs e em sistemas anti-intrusão, já que o invasor poderia se concentrar em contas existentes.

Cabe ao cliente SSH escolher qual (is) chave (s) ele tenta enviar para o servidor. Com o OpenSSH, isso pode ser configurado com a opção de configuração IdentityFile (opção de linha de comando -i ) e selecionando as chaves a serem carregadas no agente ssh ou especificando a opção de configuração IdentitiesOnly . O servidor envia um desafio (uma string gerada aleatoriamente) para o cliente. O cliente deve responder com o desafio assinado criptograficamente com uma chave privada, juntamente com a chave pública correspondente¹. O servidor verifica se a assinatura é uma assinatura válida do desafio com essa chave e se a combinação do nome de usuário solicitado e da chave pública é válida. (Normalmente, essa última parte significa que há uma linha com essa chave pública no arquivo ~/.ssh/authorized_keys do usuário.) O cliente tem várias tentativas permitidas (depois de algumas, o servidor desistirá e fechará a conexão).

Se você esqueceu qual das suas chaves é válida para qual servidor, a maneira mais simples é efetuar login no servidor e verificar o arquivo ~/.ssh/authorized_keys lá. Se a única maneira que você sabe de fazer login nesse servidor é tentar todas as chaves até conseguir, então você terá que fazer isso (o que, é claro, lhe dirá qual chave você pode usar, então você não precisa ler% código%). Se você tiver que fazer muitas tentativas na mesma conta, esteja preparado para o servidor fechar a conexão antes de terminar; aguarde alguns segundos e tente novamente.

Para referência futura, se você tiver muitas chaves diferentes, mantenha um ~/.ssh/authorized_keys que tenha a diretiva .ssh/config adequada para cada host.

¹ _{Estou simplificando o protocolo real , mantendo apenas o que é necessário aqui.}