OpenSSH: autorização baseada em chave, comprimento máximo da chave


9

Estou usando o Putty no Windows com autenticação baseada em chave para acessar alguns dos servidores da mina.

Funciona totalmente bem com a chave ~ 3700 bits, mas com a chave ~ 17000 bits, ele pensa por 20 segundos no lado do cliente e depois diz "Acesso negado" e pede uma senha.

Existe algum limite de tamanho ou tempo limite no OpenSSH para autenticação baseada em chave?

Eu entendo que o uso de teclas grandes não tem muito sentido prático, especialmente quando analisamos esses 20 segundos de cálculo, apenas tentando resolver os problemas que enfrento: -) ...


Vi problemas semelhantes acontecerem em algumas versões do OpenSSH, com as quais trabalhei usando um tamanho de chave que era uma potência de dois.
kasperd

Respostas:


9

Em um ponto, procurei na fonte do OpenSSL as chaves Diffie-Hellman e descobri que havia um limite "10K" arbitrário no tamanho das chaves DH. Mudei a fonte para um teste e descobri que funcionava. Eu escrevi um bug para os autores e eles responderam que era intenção do projeto impedir o DoS usando chaves maciças.

Não me surpreenderia ver algo semelhante no OpenSSH.


5

Não há tamanho máximo de chave ou tempo limite definido no protocolo (ou pelo menos nenhum que você esteja atingindo), mas uma implementação pode não suportar chaves longas. Um tempo de processamento de 20 segundos com a chave privada não soa alto para uma chave RSA de 17kbit. Em seguida, o servidor pode não querer gastar muito poder computacional em um usuário não autenticado: recusar chaves muito grandes é uma proteção contra ataques de negação de serviço.

Atualmente, 2048 bits são considerados razoáveis ​​para uma chave RSA; 4096 bits é maior que o necessário, mas geralmente é suportado; além disso, você não deve se surpreender se alguns programas rejeitarem a chave.


Essa proteção parece razoável. É sintonizável ou codificado no código fonte?
BarsMonster

Não há opção para isso no manual, portanto, qualquer limite deve estar no código fonte. Dito isto, não sei se existe realmente uma proteção, apenas quis dizer que seria razoável ter uma. Suspeito que a resposta de AndreasM esteja mais próxima da realidade.
Gilles 'SO- stop be evil'

3

Você conseguiu gerar esse tamanho de chave no sistema de destino pretendido? Você pode estar com um limite para o que é suportado. O meu atual sistema Centos suporta um máximo de 16k que parece suficiente para chaves massivas. Você deve ver o máximo se tentar ultrapassá-lo com o ssh-keygen, como mostrado abaixo.

[nathan@omni ~]# ssh-keygen -t rsa -b 32768
key bits exceeds maximum 16384

O mesmo no Debian 8.2. Meu netbook pode gastar um bom tempo gerando essa chave de 16384 bits ... as coisas que faço para rir.
Underscore_d

O mesmo no "Git Bash" para Windows 7, baseado no MinGW.
user1364368

Também o mesmo no OpenSuse Leap 42.1.
user1364368

1

O servidor openssh possui uma configuração LoginGraceTime. Na página do manual:

The server disconnects after this time if the user has not suc-
cessfully logged in.  If the value is 0, there is no time limit.
The default is 120 seconds.

Esse pode ser um limite que você está atingindo se estiver definido como 20 segundos.

Um palpite: também pode ser que a massa tenha esse limite, pensando que, se o processamento do cliente da autenticação de chave pública demorar tanto, algo está errado.


Eu pensei o mesmo, e conjunto LoginGraceTime 1200 Bem, mensagem de erro está no console, assim que eu duvido que seja algo em Putty ...
BarsMonster

1
Verifique os logs do servidor. Com um tamanho de chave como este, recebo: RSA_public_decrypt falhou: erro: 04067069: lib (4): func (103): reason (105). (por causa do tamanho da chave, aparentemente.) Vou tentar uma chave 2 ^ n.
21810 AndreasM

1
16384 bits parecem funcionar. Para obter resultados com 32kbits ver hermann-uwe.de/blog/... :)
AndreasM

1
Você está certo: Encontrado thid: sshd [1014]: erro: RSA_public_decrypt falhou: erro: 04067069: lib (4): func (103): reason (105) Portanto, isso deve ser um bug no sshd / OpenSSL :-)
BarsMonster
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.