Exemplo de módulo PAM demonstrando autenticação de dois fatores para fazer login em servidores via SSH, OpenVPN, etc…
Este projeto não se trata de fazer login no Google, Facebook ou outros sistemas TOTP/HOTP Second Factor, mesmo que eles recomendem o uso dos aplicativos do Google Authenticator.
A senha única baseada em HMAC (HOTP) é especificada no RFC 4226 e a senha única baseada no tempo (TOTP) é especificada no RFC 6238.
./bootstrap.sh
./configure
make
sudo make installSe você não tiver acesso ao "sudo", precisa se tornar manualmente "raiz" antes de ligar para "fazer instalar".
Para maior segurança, verifique se a senha e o OTP estão sendo solicitadas, mesmo que a senha e/ou o OTP estejam incorretas. Isso significa que pelo menos o primeiro de pam_unix.so (ou qualquer outro módulo é usado para verificar senhas) e pam_google_authenticator.so deve ser definido conforme required , não é requisite . Provavelmente não pode required os dois, mas pode depender do restante da sua configuração PAM.
Se você usar o HOTP (contador, em oposição ao tempo baseado), adicione a opção no_increment_hotp para garantir que o contador não seja incrementado para tentativas com falha.
Adicione esta linha ao seu arquivo de configuração do PAM:
auth required pam_google_authenticator.so no_increment_hotp
Execute o binário google-authenticator para criar uma nova chave secreta em seu diretório doméstico. Essas configurações serão armazenadas em ~/.google_authenticator .
Se o seu sistema suportar a biblioteca "libqrencode", você receberá um QRCode que poderá digitalizar usando o aplicativo Android "Google Authenticator".
Se o seu sistema não tiver essa biblioteca, você poderá seguir o URL que google-authenticator sai ou deverá inserir manualmente a chave secreta alfanumérica no aplicativo Android "Google Authenticator".
Em ambos os casos, depois de adicionar a tecla, clique e tome até o aparelho do menu de contexto. Em seguida, verifique se o valor de verificação da chave corresponde (esse recurso pode não estar disponível em todas as compilações do aplicativo Android).
Cada vez que você fizer login no seu sistema, agora você será solicitado para o seu código TOTP (Password único baseado em tempo) ou HOTP (contador baseado), dependendo das opções fornecidas ao google-authenticator , depois de inserir seu ID de usuário normal e sua senha normal da conta Unix.
Durante o processo de lançamento inicial, você pode achar que nem todos os usuários criaram uma chave secreta ainda. Se você ainda quiser que eles possam fazer login, pode passar na opção "Nullok" na linha de comando do módulo:
auth required pam_google_authenticator.so nullok
Se o seu sistema criptografar os diretórios residenciais até depois que seus usuários inseriram a senha, você precisará reorganizar as entradas no arquivo de configuração do PAM para descriptografar o diretório da casa antes de solicitar o código OTP ou você precisar armazenar o arquivo secreto em Um local fora do padrão:
auth required pam_google_authenticator.so secret=/var/unencrypted-home/${USER}/.google_authenticator
seria uma escolha possível. Certifique -se de definir permissões apropriadas. Você também deve dizer aos seus usuários para mover manualmente seu arquivo .google_authenticator para este local.
Além de "$ {user}", a opção secret= também reconhece "~" e ${HOME} como mão curta para o diretório inicial do usuário.
Ao usar a opção secret= , você também pode definir a opção user= . Este último força o módulo PAM a mudar para um ID de usuário codificado e codificado para fazer qualquer operações de arquivo. Ao usar a opção user= , você não deve incluir "~" ou "$ {home}" no nome do arquivo.
A opção user= também pode ser útil se você deseja autenticar usuários que não possuem contas UNIX tradicionais no seu sistema.
Veja "Diretórios domésticos criptografados", acima.
Substitui o prompt de token padrão. Se você deseja incluir espaços no prompt, envolva todo o argumento entre colchetes:
auth required pam_google_authenticator.so [authtok_prompt=Your secret token: ]
Força o módulo PAM a mudar para um ID de usuário codificado antes de fazer qualquer operações de arquivo. Comumente usado com secret= .
Opção perigosa!
Por padrão, o módulo PAM exige que o arquivo Secrets seja de propriedade do usuário de login (ou se user= for especificado, de propriedade desse usuário). Esta opção desativa essa verificação.
Essa opção pode ser usada para permitir que os daemons não sejam executados como root ainda lidam com arquivos de configuração não pertencentes a esse usuário, por exemplo, de propriedade dos próprios usuários.
Opção perigosa!
Por padrão, o módulo PAM exige que o arquivo de segredos seja legível apenas pelo proprietário do arquivo (modo 0600 por padrão). Em situações em que o módulo é usado em uma configuração não padrão, um administrador pode precisar de mais permissões de arquivo ou uma configuração específica para o seu caso de uso.
Habilite mais mensagens de log verbosas no syslog.
Alguns clientes PAM não podem levar ao usuário mais do que apenas a senha. Para contornar esse problema, este módulo PAM suporta o empilhamento. Se você passar na opção forward_pass , o módulo pam_google_authenticator consulta o usuário para a senha do sistema e o código de verificação em um único prompt. Em seguida, encaminha a senha do sistema para o próximo módulo PAM, que deverá ser configurado com a opção use_first_pass .
Por sua vez, o módulo pam_google_authenticator também suporta as opções padrão use_first_pass e try_first_pass . Mas a maioria dos usuários não precisaria definir aqueles no pam_google_authenticator .
Se você descobrir que seu código TOTP nunca funciona, esse é mais comumente o resultado do relógio do seu servidor ser diferente do do seu dispositivo Android. O módulo PAM faz uma tentativa de compensar a inclinação do tempo. Você pode ensiná -lo sobre a quantidade de inclinação que está experimentando, tentando registrá -lo três vezes seguidas. Certifique -se de esperar sempre 30s (mas não mais), para obter três códigos TOTP distintos.
Alguns administradores preferem que a inclinação do tempo não seja ajustada automaticamente, pois faz isso resulta em uma configuração de sistema um pouco menos segura. Se você deseja desativá -lo, pode fazê -lo na linha de comando do módulo:
auth required pam_google_authenticator.so noskewadj
Não aumente o contador para tentativas de HOTP com falha. Normalmente, você deve definir isso para que as tentativas de senha com falha por um invasor sem um token não bloqueie o usuário autorizado.
Permita que os usuários efetuem login sem OTP, se ainda não configurarem o OTP.
O PAM requer pelo menos uma resposta SUCCESS de um módulo, e nullok faz com que esse módulo diga IGNORE . Isso significa que, se essa opção for usada pelo menos um outro módulo deverá ter dito SUCCESS . Uma maneira de fazer isso é adicionar auth required pam_permit.so ao final da configuração do PAM.
Por padrão, o módulo PAM não ecoa o código de verificação quando for inserido pelo usuário. Em algumas situações, o administrador pode preferir um comportamento diferente. Passe a opção echo_verification_code para o módulo para ativar o eco.
Se você deseja que os códigos de verificação sejam baseados em contador, em vez de baseados no tempo, use o binário google-authenticator para gerar uma chave secreta em seu diretório doméstico com a opção adequada. Nesse modo, a inclinação do relógio é irrelevante e a opção de tamanho da janela agora se aplica a quantos códigos além do atual que seriam aceitos, para reduzir os problemas de sincronização.
Se presente e diferente de zero, forneça um período de carência durante o qual um segundo código de verificação não será solicitado. Tente definir segundos para 86400 para permitir um dia inteiro entre solicitar códigos; ou 3600 por uma hora.
Isso funciona adicionando um par (endereço IP, registro de data e hora) ao arquivo de segurança após um login de sucesso único bem-sucedido; Somente os últimos dez endereços IP distintos são rastreados.
Opção perigosa!
Com esta opção, um invasor com capacidade de preencher o sistema de arquivos (servidor de inundação com solicitações da Web ou se eles tiver uma conta, basta preencher o disco) pode forçar uma situação em que as palavras-passagens únicas podem ser reutilizadas, derrotando o objetivo de " uma vez ".
Por padrão, se a opção grace_period for definida, o módulo PAM exigir algum espaço livre para armazenar o endereço IP e o registro de data e hora do último login. Pode impedir o acesso se um servidor não tiver espaço livre ou em caso de um erro de arquivo de configuração de atualização. Com a opção allow_readonly , você pode ignorar quaisquer erros que possam ocorrer durante a atualização do arquivo de configuração.