Autenticação fácil de vários níveis para o sudo

Question

Eu tenho um servidor FreeBSD com SSH baseado em senha ativado. Gostaria de ativar sudo , mas não quero que um invasor potencial seja uma senha de acesso root. Minha solução atual é fazer login como root usando uma chave pública (a autenticação de senha remota está desativada para root) e meu usuário normal não está em roda e o sudo não está instalado.

No passado, eu usava senhas de uso único para acesso ao sudo (eu podia colocar chaves públicas no sistema, mas o sudo precisava de um OTP e tinha um tempo limite de 30 minutos para permitir que eu realmente trabalhasse sem autenticando o tempo todo). Esta é uma quantidade razoável de problemas, no entanto, pelo menos com OPIE / S / Key. Com um token de hardware, pode ser OK, mas eu não tenho um neste momento.

Estou procurando algo que me permita autenticar no sudo com uma chave pública SSH por meio do encaminhamento de agentes. pam_ssh incluído com o FreeBSD não parece fazer isso - ele só autentica verificando se o usuário pode descriptografar uma chave privada no servidor. Eu encontrei pam_ssh_agent_auth , mas eu acho muito poucas referências a ele em outro lugar. Está em 0.9 agora, mas estou um pouco hesitante em confiar no gateway para fazer o root em um programa. Não consigo encontrar muitas evidências de pessoas realmente usando.

Então, minhas perguntas são basicamente 2:

1. O pam_ssh_agent_auth é usado em estado selvagem e confiável?
2. Existe outra boa solução para habilitar o sudo enquanto ainda tem uma barreira além da senha de login? Eu pensei em ter uma segunda conta com acesso sudo e sem autenticação de senha, mas isso também parece um pouco complicado.

Answer 1

Você já resolveu isso via OTPs (mais segurança = mais aros) e não posso comentar em pam_ssh_agent_auth. Mas parece que a sua preocupação real não é com o sudo, mas com acesso em nível de rede. Em outras palavras, você parece preocupado com os privilégios concedidos aos usuários de um determinado host ou hosts, em vez de uma conta específica do sistema. Se for o caso, considere a implementação de um esquema de porta bloqueada na frente do seu daemon SSH, de modo que o SSH seja acessível somente a partir de IPs específicos e por alguém que conheça o ataque secreto. Depois disso, a autenticação regular de chave pública antiga de hosts conhecidos deve ser suficiente. Se um invasor ainda pode obter acesso ao shell nesse ponto, provavelmente você será superado de qualquer maneira.

O único outro cenário que posso imaginar é usar um proxy ssh em um host confiável para o qual você pode rejeitar suas conexões quando estiver em uma rede não confiável (e já que você está no bsdworld, você pode até usar uma cadeia no seu host que faz exatamente isso). Tanto quanto eu estou preocupado, qualquer caixa que um atacante tem acesso shell está completamente comprometida, ponto final. Se eles, em seguida, obter créditos de raiz ou não é totalmente discutível. Seu esforço pode ser melhor gasto evitando essa primeira incursão bem-sucedida.

Felicidades, -G

    

Answer 2

Michael,

O que você deseja alcançar pode ser executado de duas maneiras:

Uma das que você encontrou é usar pam_ssh_agent_auth ou talvez queira use seu "primo pobre" :

ssh para localhost aliado ao encaminhamento de chaves SSH. Instruções passo a passo aqui apontam para um servidor Ubuntu, mas todos os comandos devem estar ok com o seu FreeBSD, já que são características do próprio OpenSSH.

1. adicione a chave ao ssh-agent:

user@workstation:~$ ssh-add
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

2. Copie a chave para a conta do usuário no servidor de destino

user@workstation:~$ ssh-copy-id destination-server
user@destination-server's password: 
Now try logging into the machine, with "ssh 'destination-server'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

3. Teste o login baseado em chave:

user@workstation:~$ ssh -A destination-server
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)

 * Documentation:  http://www.ubuntu.com/server/doc

Last login: Mon Aug  8 20:38:48 2011 from 192.168.123.123
user@destination-server:~$ 

4. Agora copiamos as chaves SSH para: /root/.ssh /

user@destination-server:~$ sudo cp ~/.ssh/authorized_keys /root/.ssh/
[sudo] password for user:
user@destination-server:~$ sudo ls -l /root/.ssh/au*
total 4
-rw------- 1 root root 392 2011-08-08 20:44 authorized_keys

5. Voltando à vida normal do usuário, verificamos a existência de um soquete de autenticação do SSH:

$ echo $SSH_AUTH_SOCK 
/tmp/ssh-bUhwiw3004/agent.3004

6. Tempo divertido! Nota: tenha em mente que o seu SSHd pode ser configurado para negar acesso root. Lembre-se de ativá-lo

user@destination-server:~$ ssh root@localhost
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)

 * Documentation:  http://www.ubuntu.com/server/doc

Last login: Mon Aug  8 21:07:29 2011 from eedev.local
root@destination-server:~# id
uid=0(root) gid=0(root) groups=0(root)

7. A festa ainda não acabou ... Você pode relaxar e brincar com a configuração usando um pseudônimo:

Nota: tem em mente que o relacionamento SSH e tty tende a ser problemático

user@destination-server:~$ alias sshudo='ssh -4 -t root@localhost'
user@destination-server:~$ sshudo id
uid=0(root) gid=0(root) groups=0(root)
Connection to localhost closed.
user@destination-server:~$ sshudo vi /etc/sudoers

E voilà!

Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)

 * Documentation:  http://www.ubuntu.com/server/doc

~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
"/etc/motd" 4 lines, 114 characters

8. Antes de você ir ... Ajuste-o:

user@destination-server:~$ sshudo vi /root/.ssh/authorized_keys

Adicione o from="localhost" à frente da chave SSH que você está usando. isso restringirá o acesso de usuários remotos usando essa chave e testará:

user@destination-server:~$ sshudo id
user@destination-server:~$ uid=0(root) gid=0(root) groups=0(root)
user@destination-server:~$ Connection to localhost closed.

Faça o logout e teste a restrição

user@destination-server:~$ exit
Connection to destination-server closed.

user@workstation:~$ ssh root@destination-server
root@destination-server's password:

Espero que isso ajude.