SSH: autenticação de dois fatores

30

Atualmente, tenho um Ubuntu Server 12.04 executando o OpenSSH junto com o Samba e alguns outros serviços. No momento, tenho a autenticação de chave pública configurada e estou imaginando se é possível configurar a autenticação de dois fatores? Estive pesquisando no Google Authenticator, que atualmente uso com minha conta do Gmail.

Encontrei um módulo PAM que parece compatível, no entanto, parece que você é forçado a usar uma senha e o código gerado.

Gostaria de saber se existe uma maneira de usar o aplicativo Google Authenticator (ou algo semelhante) junto com minha chave pública para autenticar no meu servidor SSH?

— Burro de concreto
fonte

A maioria dos comentários parece ser um relatório de bug mencionando que é impossível usar o PAM e a autenticação de chave pública com o OpenSSH. Também encontrei partes mencionando que é redundante, pois estou usando uma frase secreta com minha chave. Com todas as soluções aparentemente permitindo apenas o Google Authenticator e uma senha, não uma chave pública. Eu poderia estar perdendo completamente, mas simplesmente não vejo como implementar os dois.

— Concrete Donkey

Não sei por que isso tem -1, essa é uma pergunta muito interessante e eu também gostaria de saber a resposta (não que eu provavelmente a use, mas mesmo assim, é bom guardar nos bancos de conhecimento)

— Mark Henderson

@Pierre Você está tentando exigem ambos autenticação de chave pública e um Google OTP?

— mgorven

@mgorven Sim, eu estava tentando configurar a chave pública e o Google OTP. Ouvi algumas pessoas dizerem que basta ter uma senha na chave como dois fatores, mas estou preocupado com o malware que rouba a chave não criptografada da memória. Eu prefiro ter dois dispositivos completamente separados usados para autenticação, sou um pouco paranóico.

— Concrete Donkey

Pretende-se que ele seja implementado oficialmente na

— versão

8

A Red Hat adicionou um patch ao OpenSSH no RHEL (e, portanto, no CentOS) 6.3 para exigir vários mecanismos de autenticação, para que você possa fazer algo assim:

RequiredAuthentications2 publickey,keyboard-interactive

Veja as notas de versão para obter mais detalhes.

Infelizmente, esse recurso não parece estar no OpenSSH upstream nem no Ubuntu 12.04, portanto, a menos que você queira encontrar o patch e recompilar o OpenSSH, receio que você esteja sem sorte.

— mgorven
fonte

Devo dizer que agradeço o esforço que você fez para me encontrar uma resposta; certamente tentei passar por algumas páginas dos resultados do Google, mas tudo indicava que você mencionou que eu tinha que usar uma senha e apenas um OTP. Provavelmente vou criar uma VM CentOS para brincar com o recurso.

— Concrete Donkey

@Pierre Não que muito esforço, eu sabia sobre esse recurso antes ;-)

— mgorven

Encontrei o bug correspondente e algumas notas adicionais . O bug inclui o patch como um anexo.

— precisa saber é o seguinte

E aqui está um bug do openssh upstream . Parece que funcionalidades semelhantes estarão disponíveis no openssh em breve.

— Robie Basak

O openssh 6.2 chegou à versão de desenvolvimento do Ubuntu, portanto, para qualquer desastre, esse suporte estará na versão 13.10 esperada. Ele usa upstream's AuthenticationMethodspara especificar vários métodos necessários, para que você possa exigir uma chave ssh e PAM, com o PAM executando o final do Google Authenticator.

— precisa

8

Você está procurando Duo Security

— Ajith
fonte

11

Este. Sim. Eu amo essa coisa!

— LVLAaron

Definitivamente - é fácil configurar o Duo para Unix / Linux (link na resposta), OpenVPN ( duosecurity.com/docs/openvpn_as ) ou qualquer serviço de dois fatores baseado em OATH TOTP ou gerenciamento de senhas LastPass. Qualquer serviço compatível com o Google Authenticator (que usa TOTP) pode ser usado com o aplicativo móvel do Duo ou com um token de hardware compatível com TOTP.

— RichVel

5

Você pode usar o módulo PAM do Google Authenticator e as chaves públicas, mas apenas um de cada vez será usado para uma determinada autenticação. Ou seja, se um usuário efetuar login com uma chave pública autorizada, nenhum token será necessário.

Ou, para dizer o contrário: os tokens são necessários apenas para autenticações de senha, não chaves SSH.

A propósito, essa limitação não vem do módulo Google Authenticator, mas do SSH, que implementa apenas a autenticação de dois fatores (via ChallengeResponseAuthentication) para o PAM, mas não chama o PAM quando uma chave pública válida é fornecida.

— ℝaphink
fonte

Isso estava correto, mas agora mudou. O openssh 6.2 adiciona um AuthenticationMethodsparâmetro de configuração que pode inverter isso. Agora você pode exigir os dois.

— precisa

3

Esta pergunta é de 2012. Desde então, o SSH mudou e o protocolo SSH2 foi implementado.

Nas versões mais recentes do SSH (> = 6.2), o man sshd_config menciona:

AuthenticationMethods
       Specifies the authentication methods that must be successfully completed for a user to be
       granted access.  This option must be followed by one or more comma-separated lists of
       authentication method names.  Successful authentication requires completion of every method
       in at least one of these lists.

       For example, an argument of ``publickey,password publickey,keyboard-interactive'' would
       require the user to complete public key authentication, followed by either password or key-
       board interactive authentication.  Only methods that are next in one or more lists are
       offered at each stage, so for this example, it would not be possible to attempt password or
       keyboard-interactive authentication before public key.

       This option is only available for SSH protocol 2 and will yield a fatal error if enabled if
       protocol 1 is also enabled.  Note that each authentication method listed should also be
       explicitly enabled in the configuration.  The default is not to require multiple authentica-
       tion; successful completion of a single authentication method is sufficient.

Esta página http://lwn.net/Articles/544640/ também menciona a possibilidade de usar uma chave pública e uma autenticação PAM ao mesmo tempo.

— liquidez
fonte

2

Eu sei que essa pergunta é um pouco obsoleta, mas, para o futuro de pessoas (inclusive eu) que estão procurando uma solução, também se fala em usar a opção ForceCommand no arquivo sshd_config para executar um script que executa a autenticação. Há um exemplo de script aqui que você pode modificar um pouco de acordo com suas necessidades, embora nesse exemplo ele o chame a partir do arquivo allowed_keys em vez de torná-lo em todo o sistema com o ForceCommand do sshd_config.

— Amazingant
fonte

1

Obtenha um YubiKey e siga este guia http://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

AFAIK, esta é a melhor maneira de implementar o Yubikey no seu servidor para acesso SSH. O guia acima permite que você use chave pública + yubikey, enquanto que, se você seguir o guia oficial ( http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM ), ele não funcionará com o public- chave.

Atenciosamente, Vip

— vagarwal
fonte

0

Se você definir uma senha na sua chave privada, já terá uma autenticação de dois fatores. Para fazer login, as pessoas precisariam de:

algo que você tem - sua chave privada
algo que você sabe - a senha da sua chave privada

— Bart B
fonte

3

Duas senhas não fazem autenticação de dois fatores. A chave em si não é um "algo que você tem" válido, porque não é uma coisa, apenas uma informação. A coisa deve ser não copiável, ou pelo menos não trivialmente copiável, para ser útil como um fator de autenticação.

— MadHatter apoia Monica

2

Eu discordo inteiramente. Se chaves e certificados não são "algo que você possui", o que são? Definitivamente, eles não são "algo que você conhece" (você tem o hábito de aprender com sua chave SSH?) E absolutamente não são "algo que você é". Essas são as únicas três opções, portanto, por um processo de eliminação, elas certamente são "algo que você tem".

— Bart B

11

Concordo; para mim, o problema está na máxima (algo que você | sabe | é). A idéia da autenticação de dois fatores é exigir membros de duas classes com propriedades diferentes; algo que você conhece é fácil de carregar, mas pode ser conhecido por outra pessoa ao mesmo tempo em que você o conhece; então adicionamos um segundo fator diferente. O "algo que você tem" só é diferente se não puder ser copiado (ou difícil de copiar). Caso contrário, com certeza, não é algo que você sabe, mas não é qualitativamente diferente de algo que você conhece , porque outra pessoa pode tê-lo ao mesmo tempo que você.

— MadHatter apoia Monica

2

Definitivamente, concordo que um par de chaves protegido por senha é uma grande melhoria na segurança em relação a nome de usuário + senha. Infelizmente, não concordo que esse par conta como dois fatores, e provavelmente teremos que concordar em discordar disso.

— MadHatter apoia Monica

3

Se você possui uma chave privada criptografada com senha, você prova apenas uma coisa para o servidor: que seu cliente conhece a chave privada. Não prova para o servidor que você conhece sua senha; o servidor nem sabe sobre a existência da sua senha. Portanto, é apenas "algo que você sabe" (já que seu cliente sabe) e apenas um fator. Se um invasor se apossar de apenas uma coisa (sua chave privada), você estará comprometido. Esse é um fator. Argumentar que sua senha e chave privada contam como dois fatores é apenas um exercício de sofisma. O que conta é o que acontece no fio.

— precisa saber é o seguinte