Como configurar a autenticação multi-factor para SSH no CentOS 7

Introdução

Um factor de autenticação é uma única peça de informação usada para provar que você tem os direitos de executar uma acção, como fazer login num sistema. Um canal de autenticação é a forma como um sistema de autenticação entrega um fator ao usuário ou requer que o usuário responda. Senhas e tokens de segurança são exemplos de fatores de autenticação; computadores e telefones são exemplos de canais.

SSH usa senhas para autenticação por padrão, e a maioria das instruções de endurecimento do SSH recomenda o uso de uma chave SSH. No entanto, isso ainda é apenas um fator. Se um mau actor comprometeu o seu computador, então eles podem usar a sua chave para comprometer os seus servidores também.

Neste tutorial, vamos configurar a autenticação multi-factor para combater isso. A autenticação multi-factor (MFA) requer mais do que um factor para se autenticar, ou entrar no sistema. Isto significa que um mau actor teria de comprometer várias coisas, como o seu computador e o seu telefone, para poder entrar. Os diferentes tipos de fatores são frequentemente resumidos como:

1. Algo que você sabe, como uma senha ou pergunta de segurança
2. Algo que você tem, como um aplicativo autenticador ou ficha de segurança
3. Algo que você é, como sua impressão digital ou voz

Um fator comum é um aplicativo OATH-TOTP, como o Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) é um protocolo aberto que gera uma senha de uso único, geralmente um número de 6 dígitos que é reciclado a cada 30 segundos.

Este artigo irá rever como habilitar a autenticação SSH usando um aplicativo OATH-TOTP, além de uma chave SSH. Entrar no seu servidor via SSH irá requerer dois fatores em dois canais, tornando-o mais seguro que uma senha ou chave SSH sozinha. Além disso, vamos rever alguns casos de uso adicional para MFA e algumas dicas e truques úteis.

Prerequisites

Para seguir este tutorial, você precisará:

• Um servidor CentOS 7 com um usuário sudo não-root e chave SSH, que você pode configurar seguindo este tutorial de Configuração Inicial do Servidor.
• Um smartphone ou tablet com um aplicativo OATH-TOTP instalado, como o Google Authenticator (iOS, Android).

Passo 1 – Instalando o PAM do Google

Neste passo, vamos instalar e configurar o PAM do Google.

PAM, que significa Pluggable Authentication Module, é uma infra-estrutura de autenticação usada em sistemas Linux para autenticar um usuário. Como o Google fez um aplicativo OATH-TOTP, eles também fizeram um PAM que gera TOTPs e é totalmente compatível com qualquer aplicativo OATH-TOTP, como o Google Authenticator ou Authy.

First, precisamos adicionar o repo.

EPEL (Extra Packages for Enterprise Linux) repo.

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Next, instale o PAM. Você pode ser solicitado a aceitar a chave EPEL se esta for a primeira vez que usaremos o repo. Uma vez aceite, não lhe será pedido para aceitar novamente a chave.

sudo yum install google-authenticator

Com o PAM instalado, usaremos um aplicativo auxiliar que vem com o PAM para gerar uma chave TOTP para o usuário ao qual você deseja adicionar um segundo fator. Esta chave é gerada usuário a usuário, não em todo o sistema. Isso significa que todo usuário que quiser usar um aplicativo TOTP auth precisará fazer login e executar o aplicativo helper para obter sua própria chave; você não pode executá-lo apenas uma vez para habilitá-lo para todos (mas há algumas dicas no final deste tutorial para configurar ou requerer MFA para muitos usuários).

Executar o aplicativo de inicialização.

google-authenticator

Depois de executar o comando, serão feitas algumas perguntas a você. A primeira pergunta se os tokens de autenticação devem ser baseados no tempo.

Output
Do you want authentication tokens to be time-based (y/n) y

Este PAM permite tokens baseados no tempo ou seqüenciais. O uso de tokens baseados em seqüenciais significa que o código começa em um certo ponto e então incrementa o código após cada uso. O uso de tokens baseados no tempo significa que o código muda aleatoriamente após um certo tempo decorrido. Vamos nos ater ao tempo porque é isso que aplicativos como o Google Authenticator antecipam, então responda y para sim.

Após responder esta pergunta, muitas saídas irão rolar para trás, incluindo um grande código QR. Neste ponto, use o seu aplicativo autenticador no seu telefone para digitalizar o código QR ou digite manualmente a chave secreta. Se o código QR for muito grande para digitalizar, você pode usar a URL acima do código QR para obter uma versão menor. Uma vez adicionado, você verá um código de seis dígitos que muda a cada 30 segundos no seu aplicativo.

Note: Certifique-se de gravar a chave secreta, o código de verificação e os códigos de recuperação em um lugar seguro, como um gerenciador de senhas. Os códigos de recuperação são a única maneira de recuperar o acesso se você, por exemplo, perder o acesso ao seu aplicativo TOTP.

As perguntas restantes informam ao PAM como funcionar. Passaremos por elas uma a uma.

Output
Do you want me to update your "/home/sammy/.google_authenticator" file (y/n) y

Isso escreve a chave e as opções no arquivo .google_authenticator. Se você disser não, o programa sai e nada é escrito, o que significa que o autenticador não vai funcionar.

Output
Do you want to disallow multiple uses of the same authenticationtoken? This restricts you to one login about every 30s, but it increasesyour chances to notice or even prevent man-in-the-middle attacks (y/n) y

Ao responder sim aqui, você está evitando um ataque de replay fazendo com que cada código expire imediatamente após o uso. Isto evita que um atacante capture um código que você acabou de usar e entre com ele.

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n

Responder sim aqui permite até 8 códigos válidos em uma janela móvel de quatro minutos. Ao responder não, você o limita a 3 códigos válidos em uma janela rolante de 1:30 minutos. A menos que você encontre problemas com a janela de 1:30 minutos, responder não é a escolha mais segura.

Output
If the computer that you are logging into isn't hardened against brute-forcelogin attempts, you can enable rate-limiting for the authentication module.By default, this limits attackers to no more than 3 login attempts every 30s.Do you want to enable rate-limiting (y/n) y

Relimitar a taxa significa que um atacante remoto só pode tentar um certo número de palpites antes de ser bloqueado. Se você não configurou anteriormente a limitação de taxa diretamente no SSH, fazê-lo agora é uma ótima técnica de endurecimento.

Note: Uma vez que você terminar esta configuração, se você quiser fazer backup da sua chave secreta, você pode copiar o arquivo ~/.google-authenticator para um local confiável. A partir daí, você pode implantá-lo em sistemas adicionais ou reimplantá-lo após um backup.

Agora que o PAM do Google esteja instalado e configurado, o próximo passo é configurar o SSH para usar sua chave TOTP. Vamos precisar contar ao SSH sobre o PAM e depois configurar o SSH para usá-lo.

Passo 2 – Configurando o OpenSSH

Porque nós estaremos fazendo mudanças no SSH sobre o SSH, é importante nunca fechar sua conexão SSH inicial. Ao invés disso, abra uma segunda sessão de SSH para fazer testes. Isto é para evitar bloquear-se fora do seu servidor se houver um erro na configuração do seu SSH. Uma vez que tudo funcione, então você pode fechar com segurança qualquer sessão.

Para começar, vamos editar o arquivo de configuração sshd. Aqui, estamos usando nano, que não está instalado no CentOS por padrão. Você pode instalá-lo com sudo yum install nano, ou usar seu editor de texto alternativo favorito.

sudo nano /etc/pam.d/sshd

Adicionar a seguinte linha ao final do arquivo.

. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

A palavra nullok no final da última linha diz ao PAM que este método de autenticação é opcional. Isso permite que usuários sem um token OATH-TOTP ainda possam fazer login usando sua chave SSH. Quando todos os usuários tiverem um token OATH-TOTP, você pode remover nullok desta linha para tornar o MFA obrigatório.

Salvar e fechar o arquivo.

Próximo, vamos configurar o SSH para suportar este tipo de autenticação. Abra o arquivo de configuração do SSH para edição.

sudo nano /etc/ssh/sshd_config

Localize para as linhas ChallengeResponseAuthentication. Comente a linha no e descomente a linha no line.

. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

Guardar e fechar o ficheiro, depois reinicie o SSH para recarregar os ficheiros de configuração. Reiniciar o serviço sshd não fechará as conexões abertas, então você não arriscará se bloquear com este comando.

sudo systemctl restart sshd.service

Para testar se tudo está funcionando até agora, abra outro terminal e tente fazer login sobre o SSH. Se você criou previamente uma chave SSH e está usando-a, você vai notar que não precisava digitar a senha do seu usuário ou o código de verificação MFA. Isto é porque uma chave SSH substitui todas as outras opções de autenticação por padrão. Caso contrário, você deveria ter obtido uma senha e um código de verificação.

Se você quiser ter certeza que o que você fez até agora funciona, em sua sessão SSH aberta navegue até ~/.ssh/ e renomeie o arquivo authorized_keys, temporariamente, e abra uma nova sessão e entre com nossa senha e código de verificação.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Após ter verificado que o token TOTP funciona renomeie as ‘authorized_keys’.bak’ de volta ao que era.

mv authorized_keys.bak authorized_keys

Próximo, precisamos habilitar uma chave SSH como um fator e o código de verificação como um segundo e dizer ao SSH quais fatores usar e impedir que a chave SSH sobreponha todos os outros tipos.

Passo 3 – Tornando o SSH Consciente do MFA

Reabrir o arquivo de configuração sshd.

sudo nano /etc/ssh/sshd_config

Adicionar a seguinte linha na parte inferior do arquivo. Isto diz ao SSH quais métodos de autenticação são necessários. Esta linha diz ao SSH que precisamos de uma chave SSH e uma senha ou um código de verificação (ou todos os três).

. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

Guardar e fechar o ficheiro.

Próximo, abra novamente o PAM sshd ficheiro de configuração.

sudo nano /etc/pam.d/sshd

Linha auth substack password-auth em direcção ao topo do ficheiro. Comente-o adicionando um caractere # como primeiro caractere na linha. Isto diz ao PAM para não pedir uma senha.

. . .#auth substack password-auth. . .

Guardar e fechar o ficheiro, depois reinicie o SSH.

sudo systemctl restart sshd.service

Tente agora fazer login no servidor novamente com uma sessão diferente. Ao contrário da última vez, o SSH deve perguntar pelo seu código de verificação. Ao inseri-lo, você estará logado. Mesmo que você não veja nenhuma indicação de que sua chave SSH foi usada, sua tentativa de login usou dois fatores. Se você quiser verificar, você pode adicionar -v (para verbose) após o comando SSH:

Example SSH output\
. . .debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /Users/sammy/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 279Authenticated with partial success.debug1: Authentications that can continue: keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification code:

Towards o fim da saída, você verá onde o SSH usa sua chave SSH e então pede o código de verificação. Agora você pode fazer login sobre o SSH com uma chave SSH e uma senha única. Se você quiser reforçar os três tipos de autenticação, você pode seguir o próximo passo.

Passo 4 – Adicionando um Terceiro Fator (Opcional)

No Passo 3, listamos os tipos aprovados de autenticação no arquivo sshd_config:

1. publickey (chave SSH)
2. password publickey (senha)
3. keyboard-interactive (código de verificação)

Embora tenhamos listado três fatores diferentes, com as opções que escolhemos até agora, eles só permitem uma chave SSH e o código de verificação. Se você gostaria de ter os três fatores (chave SSH, senha e código de verificação), uma mudança rápida irá habilitar todos os três.

Abrir o PAM sshd arquivo de configuração.

sudo nano /etc/pam.d/sshd

Localize a linha que você comentou anteriormente, #auth substack password-auth, e descomente a linha removendo o caractere #. Salve e feche o arquivo. Agora mais uma vez, reinicie SSH.

sudo systemctl restart sshd.service

Ativando a opção auth substack password-auth, o PAM irá agora solicitar uma senha, além da verificação de uma chave SSH e pedir um código de verificação, que nós tínhamos trabalhando anteriormente. Agora podemos usar algo que sabemos (senha) e dois tipos diferentes de coisas que temos (chave SSH e código de verificação) em dois canais diferentes.

Até agora, este artigo delineou como habilitar o MFA com uma chave SSH e uma senha única baseada no tempo. Se isto é tudo o que você precisa, você pode terminar aqui. No entanto, esta não é a única maneira de fazer autenticação multi-factor. Abaixo estão algumas formas adicionais de usar este módulo PAM para autenticação multi-factor e algumas dicas e truques para recuperação, uso automático e mais.

Tip 1 – Recuperando Acesso

Como com qualquer sistema que você endureça e proteja, você se torna responsável por gerenciar essa segurança. Neste caso, isso significa não perder sua chave SSH ou sua chave secreta TOTP e ter certeza de que você tem acesso ao seu aplicativo TOTP. Entretanto, às vezes as coisas acontecem, e você pode perder o controle das chaves ou aplicativos que você precisa entrar.

Perder uma chave SSH ou chave secreta TOTP

Se você perder sua chave SSH ou chave secreta TOTP, a recuperação pode ser dividida em alguns passos. O primeiro é voltar a entrar sem saber o código de verificação e o segundo é encontrar a chave secreta ou regenerá-la para o login normal do MFA.

Para entrar depois de perder a chave secreta que gera o código de verificação em uma DigitalOcean Droplet, você pode simplesmente usar o console virtual do seu painel de controle para entrar usando seu nome de usuário e senha.

Outra forma, você precisará de um usuário administrativo que tenha acesso sudo; certifique-se de não ativar o MFA para esse usuário, mas use apenas uma chave SSH. Se você ou outro usuário perder sua chave secreta e não conseguir entrar, então o usuário administrativo pode entrar e ajudar a recuperar ou regenerar a chave para qualquer usuário usando sudo.

Após você estar logado, existem duas maneiras de ajudar a obter o segredo TOTP:

1. Recuperar a chave existente
2. Gerar uma nova chave

No diretório home de cada usuário, a chave secreta e as configurações do Google Authenticator são salvas em ~/.google-authenticator. A primeira linha deste ficheiro é uma chave secreta. Uma forma rápida de obter a chave é executar o seguinte comando, que mostra a primeira linha do ficheiro google-authenticator (ou seja, a chave secreta). Então, pegue essa chave secreta e digite-a manualmente em um aplicativo TOTP.

head -n 1 /home/sammy/.google_authenticator

Se houver uma razão para não usar a chave existente (por exemplo, não conseguir compartilhar facilmente a chave secreta com o usuário impactado com segurança ou a chave existente foi comprometida), você pode remover o arquivo ~/.google-authenticator diretamente. Isso permitirá que o usuário faça o login novamente usando apenas um único fator, assumindo que você não tenha imposto o AMF removendo ‘nullok’ no arquivo ‘/etc/pam.d/sshd’. Eles podem então executar google-authenticator para gerar uma nova chave.

Perder acesso ao aplicativo TOTP

Se você precisar entrar no seu servidor mas não tiver acesso ao seu aplicativo TOTP para obter seu código de verificação, você ainda pode entrar usando os códigos de recuperação que foram exibidos quando você criou sua chave secreta pela primeira vez. Observe que esses códigos de recuperação são usados uma única vez. Uma vez usado para fazer login, ele não pode ser usado como código de verificação novamente.

Tip 2 – Alterar configurações de autenticação

Se você quiser alterar suas configurações de AMF após a configuração inicial, em vez de gerar uma nova configuração com as configurações atualizadas, basta editar o arquivo ~/.google-authenticator. Esse arquivo é apresentado da seguinte forma:

<secret key><options><recovery codes>

Opções que são definidas nesse arquivo têm uma linha na seção de opções; se você respondeu “não” para uma determinada opção durante a configuração inicial, a linha correspondente é excluída do arquivo.

Aqui estão as alterações que você pode fazer neste arquivo:

• Para ativar códigos seqüenciais ao invés de códigos baseados em tempo, altere a linha " TOTP_AUTH para " HOTP_COUNTER 1.
• Para permitir múltiplos usos de um único código, remova a linha .
• Para estender a janela de expiração do código para 4 minutos, adicione a linha " WINDOW_SIZE 17.
• Para desativar múltiplos logins com falhas (limite de taxa), remova a linha " RATE_LIMIT 3 30.
• Para alterar o limite de limite de taxa, encontre a linha " RATE_LIMIT 3 30 e ajuste os números. O 3 no original indica o número de tentativas durante um período de tempo, e o 30 indica o período de tempo em segundos.
• Para desativar o uso de códigos de recuperação, remova os cinco códigos de 8 dígitos na parte inferior do arquivo.

Tip 3 – Evitando AMF para algumas contas

Pode haver uma situação em que um único usuário ou algumas contas de serviço (ou seja, contas utilizadas por aplicativos, não humanos) precisem de acesso SSH sem AMF habilitado. Por exemplo, alguns aplicativos que utilizam SSH, como alguns clientes FTP, podem não suportar o MFA. Se uma aplicação não tem uma maneira de solicitar o código de verificação, a solicitação pode ficar presa até que o tempo de conexão SSH se esgote.

Desde que algumas opções em /etc/pam.d/sshd estejam definidas corretamente, você pode controlar quais fatores são usados em uma base usuário por usuário.

Para permitir MFA para algumas contas e chave SSH apenas para outras, certifique-se de que as seguintes configurações em /etc/pam.d/sshd estão ativas.

#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Aqui, auth substack password-auth é comentado porque as senhas precisam ser desabilitadas. O MFA não pode ser forçado se algumas contas forem para ter o MFA desabilitado, então deixe a opção nullok na linha final.

Após definir esta configuração, simplesmente execute google-authenticator como qualquer usuário que precise do MFA, e não execute para usuários onde somente chaves SSH serão usadas.

Tip 4 – Automating Setup with Configuration Management

Muitos administradores de sistemas usam ferramentas de gerenciamento de configuração, como Puppet, Chef, ou Ansible, para gerenciar seus sistemas. Se você quer usar um sistema como este para instalar configurar uma chave secreta quando uma nova conta de usuário é criada, há um método para fazer isso.

google-authenticator suporta comutadores de linha de comando para definir todas as opções em um único comando não-interativo. Para ver todas as opções, você pode digitar google-authenticator --help. Abaixo está o comando que configuraria tudo como descrito no Passo 1:

google-authenticator -t -d -f -r 3 -R 30 -W

Este comando responde todas as perguntas que respondemos manualmente, salva-o em um arquivo, e então sai a chave secreta, código QR, e códigos de recuperação. (Se você adicionar a bandeira -q, então não haverá nenhum output). Se você usar este comando de forma automatizada, certifique-se de capturar a chave secreta e/ou códigos de recuperação e torná-los disponíveis para o usuário.

Tip 5 – Forçar AMF para todos os usuários

Se você quiser forçar o AMF para todos os usuários, mesmo no primeiro login, ou se preferir não contar com seus usuários para gerar suas próprias chaves, há uma maneira fácil de lidar com isso. Você pode simplesmente usar o mesmo arquivo .google-authenticator para cada usuário, pois não há dados específicos do usuário armazenados no arquivo.

Para fazer isso, após o arquivo de configuração ser inicialmente criado, um usuário privilegiado precisa copiar o arquivo para a raiz de cada diretório home e alterar suas permissões para o usuário apropriado. Você também pode copiar o arquivo para /etc/skel/ para que ele seja automaticamente copiado para o diretório home de um novo usuário ao ser criado.

Aviso: Isto pode ser um risco de segurança porque todos estão a partilhar o mesmo segundo factor. Isto significa que se for vazado, é como se cada usuário tivesse apenas um fator. Leve isto em consideração se quiser usar esta abordagem.

Outro método para forçar a criação da chave secreta de um utilizador é usar um script bash que:

1. Cria um token TOTP,
2. Prompta-os para descarregar a aplicação Google Authenticator e verificar o código QR que será exibido, e
3. Executar a aplicação google-authenticator para eles depois de verificar se o ficheiro .google-authenticator já existe.

Para ter certeza que o script é executado quando um usuário faz login, você pode nomeá-lo .bash_login e colocá-lo na raiz do diretório home deles.

Conclusion

Dito isto, por ter dois fatores (uma chave SSH + ficha MFA) em dois canais (seu computador + seu telefone), você tornou muito difícil para um agente externo forçar a entrada bruta deles na sua máquina via SSH e aumentou muito a segurança da sua máquina.