Vault: Autenticação SSH com OneTime Password

Vault: Autenticação SSH com OneTime Password

Vault é uma ferramenta desenvolvida pela HashiCorp, essa ferramenta tem como objetivo fazer um armazenamento inteligente de “segredos”, podem ser eles, chaves de ssh, dados de acesso a um banco e dados, api tokens e assim por diante.

Nesse post vou explicar como é possível fazer a autenticação via ssh utilizando esta ferramenta, pois foi um projeto que tive que fazer na semana passada.

Arquitetura para o Vault

Nesse projeto eu vou utilizar a seguinte arquitetura:

Vault

Como demonstrado no desenho, farei o acesso da minha máquina diretamente aos servidores DBMaster e WebSever. Esses servidores possuem uma regra no pam que executam um binário chamado vault-ssh-helper que vai até o servidor vault e valida a chave gerada para então liberar ou não o acesso a máquina.

Agora HandsOn!

Iremos utilizar 3 servidores Debian 8.

Abaixo os IPs das Máquinas:

root@debian:~# vim /etc/hosts
192.168.0.109   webserver
192.168.0.107   dbmaster
192.168.0.110   vault-server

A primeira máquina que vou fazer a instalação é o vault-server.

root@debian:~# ssh vault-server
root@vault-server:~# cd /root
root@vault-server:~# wget https://releases.hashicorp.com/vault/0.8.1/vault_0.8.1_linux_amd64.zip --no-check-certificate
root@vault-server:~# unzip vault_0.8.1_linux_amd64.zip
root@vault-server:~# rm -f vault_0.8.1_linux_amd64.zip
root@vault-server:~# ./vault server -dev -dev-listen-address="0.0.0.0:8200" &

O Vault é apenas um binário a ser executado. Caso você queria iniciá-lo junto com o boot da máquina é necessário criar um serviço, no caso deste post como a ideia é somente mostrar o seu funcionamento vamos usar o modo -dev. Nesse modo todas as configurações são armazenadas na memória e assim que o serviço parar os dados são perdidos. Em ambientes de produção ele deve ser configurado em modo H.A ( Alta Disponibilidade ) e deve-se fazer o armazenamento dos dados no Consul .

Agora que o servidor está em execução é necessário configurar uma variável de ambiente para definir qual das máquinas é o servidor:

# Definindo a variavel
root@vault-server:~#  export VAULT_ADDR="192.168.0.110:8200"

# Testando se a variável funciona
root@vault-server:~# ./vault mounts
Path        Type       Accessor            Plugin  Default TTL  Max TTL  Force No Cache  Replication Behavior  Description
cubbyhole/  cubbyhole  cubbyhole_180438f6  n/a     n/a          n/a      false           local                 per-token private secret storage
secret/     generic    generic_149303c3    n/a     system       system   false           replicated            generic secret storage
sys/        system     system_0175a619     n/a     n/a          n/a      false           replicated            system endpoints used for control, policy and debugging

O comando ./vault sabe qual é o servidor em que ele deve se comunicar devido a essa variável VAULT_ADDR que foi configurada.

Esse mounts são os backends onde as suas chaves podem ser armazenadas, em um outro post posso explicar em mais detalhes, mas nesse momento vou falar somente do ssh. Então para habilitar o backend para chaves de ssh, é só digitar o comando abaixo:

root@vault-server:~# ./vault mount ssh
2017/09/02 18:47:24.186587 [INFO ] core: successful mount: path=ssh/ type=ssh
Successfully mounted 'ssh' at 'ssh'!

Agora que temos o backend de ssh montado vamos criar uma role do tipo OTP ( OneTimePassword ).

root@vault-server:~# ./vault write ssh/roles/ssh_otp key_type=otp default_user=root cidr_list=192.168.0.0/24
Success! Data written to: ssh/roles/ssh_otp

E configuração do server basicamente acaba aqui.

As máquinas clientes

Vamos configurar agora as máquinas WebServer e DBMaster.

root@debian:~# ssh dbmaster
root@dbmaster:~#

Na configuração das duas máquinas vamos precisar fazer a instalação do vault-ssh-helper, toda a documentação oficial pode ser encontrada neste link: https://github.com/hashicorp/vault-ssh-helper .

Mas eu vou fazer um resumo aqui.

Primeiro passo é baixar o arquivo binário.

root@dbmaster:~# wget --no-check-cert https://releases.hashicorp.com/vault-ssh-helper/0.1.3/vault-ssh-helper_0.1.3_linux_amd64.zip

root@dbmaster:~#  unzip vault-ssh-helper_0.1.3_linux_amd64.zip
Archive:  vault-ssh-helper_0.1.3_linux_amd64.zip
  inflating: vault-ssh-helper

root@dbmaster:~#   rm -f vault-ssh-helper_0.1.3_linux_amd64.zip

Agora crie um arquivo de configuração chamado config.hcl:

vault_addr = "http://192.168.0.10:8200"
ssh_mount_point = "ssh"
tls_skip_verify = false
allowed_roles = "*"

 

Agora é necessário fazer a configuração no arquivo /etc/pam.d/sshd nas duas máquinas.

root@dbmaster:~# vim /etc/pam.d/sshd

#@include common-auth
auth requisite pam_exec.so quiet expose_authtok log=/tmp/vaultssh.log /root/vault-ssh-helper -dev -config=/root/config.hcl

É importante colocar a opção -dev no helper também quando  estiver em modo dev, caso contrário a autenticação irá falhar e gerar uns erros genéricos que acaba sendo difícil fazer o debug,

É importante também comentar a linha @include common-auth do arquivo para não conflitar com a autenticação do vault.

Agora que o pam está configurado, vamos fazer a configuração do /etc/ssh/sshd_config .

root@dbmaster:~# vim /etc/ssh/sshd_config

# Altere as configurações abaixo

ChallengeResponseAuthentication yes
UsePAM yes
PasswordAuthentication no

root@dbmaster:~# service ssh restart

Agora os servidores já estão configurados, os mesmos passos executados na máquina dbmaster, devem ser executados na máquina webserver.

Agora como faço pra acessar?

Toda vez que for necessário o acesso há um das máquinas, deve-se gerar uma nova chave, para gerar essa chave acesse o servidor do Vault.

root@debian:~# ssh vault-server

root@vault-server:~#root@debian:~# ./vault write ssh/creds/ssh_otp ip=192.168.0.107
Key             Value
---             -----
lease_id        ssh/creds/ssh_otp/c4efbc86-6479-3a5b-ca10-455d78320e2d
lease_duration  768h0m0s
lease_renewable false
ip              192.168.0.107
key             5c42ff2a-3325-3efb-1668-5829cd26fe20
key_type        otp
port            22
username        root

Então agora foi criada uma chave para o usuário root, que irá acessar o endereço 192.168.0.107 que é o dbmaster.

Para fazer o acesso utilize o ssh normalmente e informe essa chave gerada.

root@debian:~# ssh root@192.168.0.107
Using keyboard-interactive authentication.
Password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Sep  2 18:53:45 2017 from dbmaster
root@dbmaster:~# 
username root

A senha de acesso é a do campo key na saída do comando vault write:

key             5c42ff2a-3325-3efb-1668-5829cd26fe20

Lembrando que uma vez que essa chave já foi utilizada para logar, não será mais possível usa-la, então é necessário gerar uma nova chave como é mostrado acima.

Obrigado (:

Acesse alissonmachado.com.br

Anterior Palestra 4Linux sobre Infraestrutura Ágil no TDC - The Developers Conference 2017
Próxima Evento Python Brasil - Python na Manutenção de mais de 100 mil embarcados

About author

Alisson Machado
Alisson Machado 8 posts

Desenvolvedor Python e Arquiteto DevOps 8 anos de experiência em projetos FOSS (Free and Open Source Software) e Python; Certificações LPI1, LPI2 e SUSE CLA

View all posts by this author →

Você pode gostar também

Infraestrutura 0 Comentários

Subutai: Uma nova maneira de pensar sobre nuvens

A famosa “Cloud Computing”, a ideia de que todos os tipos de tecnologias podem ser entregues totalmente pela Internet está crescendo cada vez mais e mudando tudo! Isso afeta nossas

Infraestrutura 0 Comentários

12 Metodos para prevenir-se de ataques DDOS

Muito bem… como primeiro post por aqui… eu pensei em abordar um assunto que constantemente me abordam nos treinamentos e palestras e bate papos que tenho, que e sobre ataque

Infraestrutura 0 Comentários

MongoDB: como criar um Cluster Replication Set

O MongoDB é um banco com foco em escalabilidade horizontal, sendo assim ele possui um recurso chamado ReplicatSet que serve para replicar os dados em um cluster de servidores para

0 Comentários

Ainda não há comentários!

Você pode ser o primeiro a comentar este post!

Deixe uma resposta