ANSIBLE SERIES: YML … /etc/ssh/sshd_config
Oi (de novo), quando foi a última vez que esteve na sala-cofre do datacenter? Melhor dizendo, quando se levantou da cadeira para acessar a console do servidor fisicamente? Não se lembra? 🤔 Faz tanto tempo assim? 🤔 Bem, agradeça ao SSH e outros protocolos de acesso remoto … É mais do que normal somente precisarmos fazê-lo em casos de manutenção, ataques ou sinistros. Além do que, você não quer seus servidores fritando de calor não é mesmo? Isso porque se a sala-cofre fosse acessível a todo momento, e por qualquer um, o entra e sai de pessoas, o abre e fecha de portas tiraria o ar frio proveniente dos condicionares e escaparia para fora deixando aquele bafo quente na sala e consequentemente aspirado para dentro das máquinas. Essa mesma lógica é aplicada no que diz respeito ao acesso virtual (remoto). Da maneira análoga, você não vai querer pessoas entrando e saindo de suas instâncias … mexendo, olhando e bagunçando arquivos, pastas, serviços e aplicações. Proteja-se de acessos não-autorizados editando o principal arquivo de configuração do daemon SSH: o sshd_config.
Então já sabe … senta que lá vem um novo artigo do BLOG 😐
Ligando as máquinas e testando a rede local
Como é de praxe, abra o virtualbox e inicie os três servidores. Se for o caso de possuir muitos sistemas já instalados e não saber mais quem é quem, talvez eu possa ajudá-lo a relembrar. Ou eles estarão nomeados como: controlA (ansible), nodeA (centos7), nodeB (centos7). Ou como: centos7_default (awx), centos8_default (primeiro nó), ubuntu-2104_default (segundo nó). Reforçando sempre a importância de no mínimo três vms para compor nossa rede local/virtual, esta que servirá de laboratório prático e de testes. Ok?
Para saber se está tudo configurado conforme o esperado, utilize o bom e velho comando ping. O êxito só é válido se ambos os sentidos forem alcançados, ou seja, do controlador para os alvos e dos alvos para o controlador. Observe se não há nenhuma perda de pacote no meio do caminho. Em casos de indisponibilidade (msg: “host is unreachable”) revise as regras de firewall, estado do SELinux, modo da placa de rede, etc.
Escrevendo e pontuando o playbook
A seguir, linha por linha, explicando o cada uma faz e a ideia por trás disso. E ao final o YAML completo, formatado para rodar no AWX.
---
Um arquivo .yaml pode conter várias, o que chamamos de, seções de documentos. Para cada novo documento, dentro da mesma sessão, é preciso sinalizar tanto o início quanto o fim deste. Convencionalmente, o início será caracterizado por três hífens (traços) seguidos, não havendo nenhum espaço entre eles. Em contrapartida, o final é sempre caracterizado por três pontos igualmente seguidos e sem espaço entre si. Por questões práticas, dificilmente veremos um playbook .yml com mais de uma sessão de documento. Tudo se resume entre um único — e …
hosts: all
O ansible é capaz de executar tarefas de N formas: (a) localmente; (b) unicamente; (c) amplamente; (d) especificamente. Na prática, o equivalente seria: (a) localhost; (b) host; (c) all; (d) grupo.
become: yes
Informe aqui se pretende usar algum método de escalonamento pré-existente na máquina alvo. Trocando em miúdos, estamos falando dos privilégios, ex: su, sudo, runas, e afins. O padrão become: yes implicitamente quer dizer que o usuário utilizado será root.
tasks:
Conjunto de tarefas a serem executadas logo abaixo desta linha e sinalizadas individualmente por um hífen (-) + espaço ( ) + nome da tarefa (string).
- name: SSH-sshd <> Update configuration file ...
Nome dado a tarefa específica a seguir. Parênteses: como eu (Victor) gosto de padronizar as coisas, sempre nomeio assim: serviço/comando/aplicação < > Fazendo_determinada_ação …
blockinfile:
Exemplar de um módulo nativo presente no ansible-core, responsável por inserir/alterar/remover conjunto(s) de linhas delimitado(s) por marcadores específicos e tão somente alheios ao próprio blockinfile. Aceita parâmetros e certos atributos como entrada de dados. Graças a ele torna-se muito fácil manipular arquivos de configuração e correlatos pois adiciona a possibilidade de anexar trechos de texto mais complexos no código.
path: /etc/ssh/sshd_config
Nome completo do arquivo, ou seja, caminho + diretório + nome. Apenas o nome não irá funcionar, portanto, atenção!
insertbefore: BOF # Beginning of the file
Marcador para deixar bem claro o seguinte: conteúdo que será apresentado em breve, na forma de bloco, deve ser inserido no começo do arquivo, e não no final.
marker: "# {mark} ANSIBLE MANAGED BLOCK BY LINUX-ADMIN"
Comentário a ser acrescentado na hora de gerar o novo arquivo. Disse “novo” pois sim, exatamente o que pensou, armazenaremos uma cópia (backup) do original. E melhor ainda, sem gambiarras, já que o próprio módulo prevê tal coisa e fornece esse recurso nativamente caso queira usá-lo. Adiantando que (spoiler alert!) não é obrigatório guardar o antigo, você pode muito bem editar o atual e salvá-lo assim com as modificações.
block: |
Palavra-chave reservada para sinalizar que, abaixo desta linha, o início do bloco já está valendo e dessa forma considere tudo como tipo texto (string).
PermitRootLogin yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication yes
Cada linha acima é considerada exatamente de acordo: uma linha individual e de natureza singular, então, traduzindo cada uma em termos práticos temos o equivalente:
- Permita o acesso remoto do usuário ROOT. - Está prevista a autenticação por chave pública. - As únicas chaves autorizadas são as que estão presentes em authorized_keys (sendo este um arquivo oculto). - Fica igualmente autorizado o uso de senhas locais para se autenticar remotamente.
backup: yes
O já “adiantado” recurso nativo para cópias e preservação de originais, onde esses estarão devidamente identificados pelo final data+hora
validate: /usr/sbin/sshd -T -f %s
Rode o comando para validar se está tudo OK com a sintaxe, antes de copiar para o destino final com todas as mudanças propostas.
- name: SSH-sshd <> Restart SSHD ...
Título “padronizado” da tarefa subsequente, que é reiniciar o serviço para que as alterações tomem efeito imediato.
service:
Módulo ansible, também nativo, que faz a chamada do serviço a ser especificado adiante.
name: sshd
Parâmetro que recebe o argumento “nome”, neste caso “sshd” (d de daemon).
state: restarted
Parâmetro que diz para qual estado o serviço em questão tornar-se-ei, logo após a sua chamada (iniciado, parado, ou reiniciado).
...
Fim da seção de um documento prévio, localizado dentro do arquivo .YAML corrente, iniciado com – – –
Lançando o template no AWX 🚀
Promessa é dívida, então aqui vai o código do playbook completo e tabulado. Está última é importante porque sem a endentação correta, o mesmo será ignorado apresentando diversos erros de sintaxe. Copie e cole no seu editor favorito (vi, vim, nano, gedit) ou execute o clone a partir do meu repositório GITHUB para o SCM da empresa (git, github, gitlab, bitbuckett, sourceforge).
---
- hosts: all
become: yes
##gather_facts: no
tasks:
- name: SSH-sshd <> Update configuration file ...
blockinfile:
path: /etc/ssh/sshd_config
insertbefore: BOF # Beginning of the file
marker: "# {mark} ANSIBLE MANAGED BLOCK BY LINUX-ADMIN"
block: |
PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
backup: yes
validate: /usr/sbin/sshd -T -f %s
- name: SSH-sshd <> Restart SSHD ...
service:
name: sshd
state: restarted
...
git clone https://github.com/vicrlda/awx-tower.git
https://github.com/vicrlda/awx-tower/blob/main/playbooks/remote-login-sshd-config.yml
Se você é novo por aqui quero que saiba que já fiz inúmeros posts sobre ansible, desde a teoria, passando pelo devops, sua história, curiosidades, automação na TI, ferramentas similares, e muito mais … Chegamos ao ponto de abordar a prática em duas faces: a do modo texto (bash, comandos, teclado) e a do modo gráfico (web, menus, botões, mouse). A cada novo post, é um costume meu sempre retomar de alguma forma o laboratório anterior. O intuito é nivelar a nossa audiência pensando sempre nos eventuais “paraquedistas”, “turistas”, e “recém-nascidos” que chegam a cada artigo novo (sei que na esmagadora maioria das vezes é o próprio Google que vos traz). Mas a partir de agora, pretendo focar no que realmente importa pra nós: destrinchar cada linha do código de um playbook, explanando a ideia e os bastidores por trás da mesma. Sendo assim, aquelas bizuradas, revisões e capturas de tela que normalmente faço no começo mostrando o que foi feito no artigo passado, serão bem mais esporádicas agora.
Para todas as perguntas, as respostas estarão aqui:
https://machinesbecomeservices.com/category/ansible/
Desvio de rota efetuado com sucesso, voltando ao trajeto principal … rsrs!
Uma vez montada todas as peças do quebra-cabeça (inventário, credencial, projeto, e template) no AWX, é hora do lançamento em PRODUCAO. Jargão específico para o que chamamos de deploy. Observe a figura abaixo:
Demonstrando que acabei de criar um usuário totalmente do zero, usando o playbook do último post. Agora, tendo em mãos dois usuários distintos, vamos liberar o acesso para um e negá-lo para o outro. Para tal, acrescente a seguinte linha no seu código, posicionada imediatamente após PasswordAuthentication yes
AllowUsers "{{ survey }}"
O que ela faz é simplesmente permitir o acesso para o(s) usuário(s) informado(s) durante o recurso “SURVEY” do awx/tower. Este também j´á foi explicado em datas anteriores.
Vale destacar que o fator que distingue um login específico de outro completamente diferente é a separação por espaço em branco e não vírgulas ou pontos. Então, na hora de digitar fique atento a isso!!!
Chegando ao final, teste sua nova configuração fazendo ambos. A tentativa de ANA espera-se sucesso, ao contrário de JOAO, que espera-se erro/falha:
