Nós usamos OTPW para isso. Implementação simples. Fácil de replicar a lista de senhas. O sistema solicita senhas por número, portanto, não há problemas em manter as listas em sincronia.
Certamente não é uma boa idéia entrar em um sistema remoto a partir de um computador não confiável. Mas às vezes é necessário. Expor um arquivo-chave SSH não criptografado não é uma opção, é claro. Inserir uma senha normal também não é.
S / Key parece ser a solução "usual", mas requer seguir estritamente a ordem das senhas em uma lista. Isso é indesejável para contas compartilhadas, pois todas as partes precisariam sincronizar o uso da lista.
Qualquer maneira de fazer OTPs sem requisitos em relação à ordem de uso? Outras ideias?
Histórico: dois administradores compartilham uma conta. Outro deve receber um "envelope de emergência" que é lacrado e contém informações para essa conta. Quebrar o selo é permitido apenas no caso de os outros administradores não estarem disponíveis.
Nós usamos OTPW para isso. Implementação simples. Fácil de replicar a lista de senhas. O sistema solicita senhas por número, portanto, não há problemas em manter as listas em sincronia.
S / Key é ideal para este cenário, mas você precisa fazer um pouco mais de trabalho.
Crie contas especiais para cada envelope de emergência. Essas contas são adicionadas aos sudoers e podem assumir raiz. Isso lhe dá a trilha de auditoria que você deve ter (uma conta por envelope, um envelope por usuário) e a flexibilidade que você precisa.
Após uma emergência, o administrador deve trazer de volta o envelope para a próxima senha, o que lhe dá a trilha de auditoria.
Eu sou fã do Yubikey há algum tempo.
O problema parece ser que você está tentando usar contas de grupo. Vejo duas possibilidades
No segundo caso, você terá que testar o que a tecla s / pensa que um usuário é (UID ou UID) e se você pode atribuir a cada login uma lista separada.
(Eu admito - eu nunca tentei o # 2 no Linux, mas costumávamos usá-lo há um tempo atrás para dar aos operadores um shell alternativo, que na verdade era um sistema de menu para -los para executar alguns comandos fixos como root.Estes dias, você só faria isso w / sudo)
Dê uma olhada no mobile-otp - é um token de software 'barato' que pode ser executado em um celular com capacidade para java. Eu usei-o com sucesso apenas com web-apps, mas como eu vejo eles têm módulo pam também.
como alternativa, há wikid , mas eu nunca usei este.
Este é um tópico antigo, mas alguém pode se deparar com ele. Existem dois requisitos interessantes:
uma conta compartilhada por vários seres humanos
o envolope de emergência, que eu acho que deve funcionar apenas uma vez.
O LinOTP pode lidar com isso. Você pode atribuir vários tokens OTP diferentes de fornecedores diferentes a um usuário. (req. 1)
Além disso, você pode criar um token de senha fixa. Coloque isso no envelope. Agora vem a parte legal: você pode definir com que frequência um token pode ser usado para uma autenticação bem-sucedida. Então você pode definir este valor = 1 para este token de envelope de emergência (req. 2)
Coisas como Vasco Vacman fornecem autenticação RADIUS, que você pode usar para logar no linux usando o PAM regular. Eles exigem um token físico, e são caros, então provavelmente não se adequam à sua situação atual.
Outra alternativa de autenticação strong seria o RSA SecurID.
Prós: Muitos fatores para escolher, desde o dispositivo keyfob "clássico" até tokens de software (incluindo iPhone!) até "OnDemand" (ou seja, códigos OTP enviados via SMS / e-mail), é isso que eu provavelmente usaria este caso. (ou seja, você tem todas as "opções" mencionadas no artigo)
Prós: fácil integração com praticamente qualquer sistema, permitindo autenticação strong na maioria dos sistemas
Prós: fácil de usar, do usuário final POW.
Contras: preço. Não é a solução mais barata no mercado.
Eu costumava usar o OPIE. Ele pede as senhas por número, então você sabe qual delas está na lista.
Mas agora eu mudei para o Yubikey.
Não entendo por que o S / Key padrão não atende aos seus requisitos.
Sempre que alguém faz login, envia um "desafio" visível que inclui o número de índice da senha desejada. Informações suficientes são fornecidas para descobrir qual linha de uma lista impressa de senhas únicas está sendo solicitada ... sem qualquer tipo de coordenação com qualquer outro usuário que compartilhe a conta. (Outra maneira de ver isso é que toda a coordenação necessária é fornecida pelo próprio computador, sem a necessidade de os múltiplos usuários conversarem entre si.) Da mesma forma, há informações suficientes (tanto o número do índice quanto a semente) para dar a um programa para regenerar a senha solicitada (desde que você conheça o segredo).
O envelope pode conter outra cópia impressa de toda a lista de senhas de uso único ou a senha original (sem skey), que ainda funciona. (É claro que para máxima segurança, se o envelope for aberto, você quer mudar o que ele continha [ou a sequência de OTPs ou a senha original].)
Portanto, o skey parece preencher facilmente ambos os requisitos. Diga-me novamente por que você está procurando por algo diferente?