Guia prático: Autenticação via SSH com a ferramenta Vault da HashiCorp

Guia prático: Autenticação via SSH com a ferramenta Vault da HashiCorp

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 4Linux e a revolução da Infraestrutura Ágil na Cultura DevOps
Próxima Tiago Assunção revela segredos de Python na manutenção de embarcados

About author

Alisson Machado
Alisson Machado 22 posts

Alisson Menezes, atua como Gerente de T.I, 9 anos de experiência em projetos FOSS (Free and Open Source Software) e Python. Formação em Análise de Sistemas pela FMU e cursando MBA em BigData pela FIA, possui certificações LPI1, LPI2 e SUSE CLA, LPI DevOps e Exim - DevOps Professional. Autor dos cursos Python Fundamentals, Python for Sysadmins, MongoDB for Developers/DBAs, DevSecOps, Co-Autor do Infraestrutura Ágil e Docker da 4Linux e palestrantes em eventos como FISL, TDC e Python Brasil. É entusiasta das mais diversas áreas em T.I como Segurança, Bancos de dados NoSQL, DataScience mas tem como foco DevOps e Automação.

View all posts by this author →

Você pode gostar também

DevOps

Automatizando Tarefas com Shell Script

Já se aventurou pela linha de comando de sistemas Unix ou Linux? Se sua resposta for sim, então provavelmente já ouviu falar de Shell Script. Mas o que seria exatamente

Infraestrutura TI

Reduza custos na AWS com a análise e automação da 4Linux

Acabe com desperdícios com instâncias ligadas sem uso. Projeto de análise e automação da 4Linux permite reduzir gastos com serviços da nuvem AWS Certamente sua empresa possui instâncias na AWS

DevOps

Gerenciando entradas de DNS com Terraform e Protocolo TSIG

Terraform é uma ferramenta da Hashicorp focada em Bootstrapping e inicialização de recursos. Em comparação com Puppet , este é responsável por gerenciar a configuração de uma infraestrutura existente, já o