Patrick Brandão

SSH: Guia completo

Saudações.

O SSH (Secure Shell) é um protocolo para comunicação cliente servidor cheio de recursos interessantes e poderosos.

Pré-requisitos (constam em outros artigos aqui do blog):

  • Instalação do Linux (Debian);
  • Internet no servidor;

1 – Conhecendo o SSH e o OpenSSH

O SSH criado por Tatu Ylönen (1995) para substituir o telnet – protocolo simples de troca de texto entre dois softwares pela rede IP.

Sistemas antigos como “Berkeley rlogin“, “rsh” e “rexec” foram agregados juntos com o telnet e o ftp no protocolo SSH, o principal motivador da unificação era:

  • Criar um protocolo que unificasse os recursos de acesso remoto e controle remoto;
  • Implementar a criptografia para segurança e autenticação avançada pois o principal problema dos protocolos anteriores era a interceptação de senhas e dados sigilosos por captura de pacotes;

É totalmente OpenSource e gratuito, sem limitações de software, sem licença, sem custo adicional com software.

1.1 – Recursos do protocolo

O protocolo SSH trouxe como melhoria os recursos:

  • Login: autenticação por usuário/senha, usuário/chave e PAM;
  • Shell remoto (telnet criptografado);
  • Transferência de arquivos (SCP, SFTP e RSYNC);
  • Recursos TCP: VPN, Túneis TCP;
  • Pings internos: keep-Alive a nível de TCP e keep-alive SSH;
  • Compressão;
  • Política de chaves;
  • Criptografia assimétrica para chaves;
  • Criptografia simétrica para fluxos;
  • Controle de criptografia (tipos de chaves, tamanhos, escolha de algoritmos);
  • Port Forwarding: Local, remoto e dinâmico (proxy socks);
  • Login e execução de comandos remotos;
  • X11 Forwarding: transporte para acesso a interface gráfica remotamente;
  • SSH Agent: gerenciamento de chaves privadas e hosts intermediários (jumps);
  • PKI SSH: unidade certificadora emite certificados (chaves públicas) com restrições;

1.2 – Programas

O cliente SSH para Linux (openssh-client) instala os comandos:

  • ssh: usado para login remoto, execução de comandos e criação de túneis;
  • sftp: usado para transferência de arquivos (SSH File Transfer Protocol);
  • scp: usado para transferência de arquivos sobre SSH;
  • ssh-keygen: criação de chaves e gerenciamento de hosts conhecidos;
  • ssh-agent: agente de autenticação que mantém chaves privadas em memória (evita digitar senhas repetidamente);
  • ssh-add: adiciona chaves privadas no ssh-agent;
  • ssh-keyscan: usado para varredura a fim de popular o arquivo de hosts conhecidos; 
  • ssh-copy-id: Instala chave pública no servidor remoto, automatiza a configuração de autenticação por chave;

1.3 – Etapas de uma conexão SSH

O cliente negocia atributos com o servidor de forma bem parecida com o SSL/TLS.

Quando o cliente inicia uma conexão TCP com o servidor SSH, os seguintes passos são executados:

  • 1 – Estabelecimento de conexão TCP (3way);
  • 2 – Troca de versões do protocolo SSH (v1, v2) e server token;
  • 3 – KEX – Negociação de Algoritmos (Key Exchange), cada tipo com suas especificações: DH-SHA1 e DH-SHA2, ECSH-SHA2, Curve25519, Sntrup;
  • 4 – Algoritmos de Chave assimétrica do servidor (Host Key): RSA, ECDSA e ED25519;
  • 5 – Algoritmos de Criptografia simétrica (Ciphers) e suas especificações: AES e Chacha20-poly1305;
  • 6 – Algoritmos MAC (Message Authentication Code) e suas especificações: UMAC e HMAC-SHA2;
  • 7 – Algoritmos de Compressão: desativado (none) ou zlib;
  • 8 – Troca de chaves públicas (Key Exchange);
  • 9 – Método de autenticação do usuário: publickey, password, keyboard-interactive, gssapi-with-mic;
  • 10 – Processo de Autenticação: troca de valores para o método escolhido acima;
  • 11 – Abertura de Canal: estabelecimento de canal para sessão e sua finalidade, podendo a mesma sessão servir a várias finalidades, tipos de operações dentro da sessão:
    • Shell;
    • Terminal (VTY);
    • Comando remoto;
    • Transferência de arquivos;
    • Mapeamento de porta local;
    • Mapeamento de porta remota;
    • Mapeamento de sessão X11;
    • VPN TUN/TAP;
  • 12 – Rekeying durante a sessão: solicitar a negociação de novas chaves simétricas de acordo com o tempo, volume de dados já transferidos ou solicitação manual;

1.4 – Instalando softwares

Instale no cliente e no servidor os programas:

Cliente – Bash
# Cliente SSH
apt -y install openssh-client;

# Rsync
apt -y install rsync;

# Servidor SSH
apt -y install openssh-server;

# Ativando servidor
systemctl enable ssh;

Agora os comandos estarão disponíveis para uso!

1.5 – Conhecendo os recursos do cliente

Explorando os recursos disponíveis.

Cliente – Bash
# Algoritmo de troca de chaves efêmeras: 
ssh -Q kex;

# Cifras simétricas suportadas:
ssh -Q cipher;

# Algoritmos MAC (Message Authentication Code) 
ssh -Q mac;

# Tipos de assinaturas digitais:
ssh -Q sig;

# Versões SSH suportadas (v1 deve ser evitada):
ssh -Q protocol-version;

# Tipos de chaves assimétricas (host keys, client keys):
ssh -Q key;         # todos os tipos
ssh -Q key-plain;   # tipos diretos simples
ssh -Q key-cert;    # tipos com suporte a certificação

# Tipos de compressão:
ssh -Q compression;

se precisar configurar o cliente SSH (comando ssh) para suportar novas opções ou travar nas opções desejadas, altere o arquivo /etc/ssh/ssh_config ou, se houver nesse arquivo a instrução Include /etc/ssh/ssh_config.d/*, opte por criar arquivos avulsos no diretório /etc/ssh/ssh_config.d para que eles sejam persistentes entre atualizações.

Exemplo:

Cliente – /etc/ssh/ssh_config.d/defaults
# Ativar keep-alive ssh a cada 5 segundos para evitar quebra de conexão
# ao passar por NAT
Host *
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    ServerAliveInterval 5
    ServerAliveCountMax 3
    StrictHostKeyChecking yes

# Criar configuracoes especificas para alguns servidores
# - declara dois enderecos de servidores na mesma politica
# - usa chave local especifica
# - fixa criptografia assimetrica em RSA
# - fixa criptografia simetrica em AES-256-CTR
# - fixa validacao de autetnicacao em HMAC-SHA2-512
Host pve01.ajustefino.com pve02.ajustefino.com
    IdentityFile ~/.ssh/pve-cloud-id_rsa
    IdentitiesOnly yes
    PubkeyAcceptedAlgorithms ssh-rsa
    HostKeyAlgorithms ssh-rsa
    Ciphers aes256-ctr
    MACs hmac-sha2-512

Alternativamente, especifique todos os parâmetros personalizados direto no comando ssh:

Cliente – Bash
# Cliente SSH
ssh \
    -o ServerAliveInterval=5 \
    -o ServerAliveCountMax=3 \
    -o StrictHostKeyChecking=yes \
    -o ConnectTimeout=5 \
    -o "RekeyLimit 50M 30m" \
    -o "Compression yes" \
    -o "TCPKeepAlive yes" \
    -o "UserKnownHostsFile=/dev/null" \
    \
    root@pve01.ajustefino.com;

# Outros parametros:
# -4 = Força IPv4 quando usar nome DNS (fqdn)
# -6 = Força IPv6 quando usar nome DNS (fqdn)

Aprender a controlar esses atributos é vital para se conectar em servidores velhos ou muito novos, onde a configuração padrão do cliente pode não é aceita pelo servidor.

2 – Criptografia simétrica

O SSH trabalha com criptografia simétrica para cifrar e decifrar dados trocados entre o cliente e o servidor usando a mesma chave. Ambos os lados precisam usar a mesma chave para trocar dados na sessão.

Esse algoritmos são muito seguros e extremamente rápidos, sendo acelerados por hardware (instruções AES-NI, PCLMULQDQ, SHA-NI, AVX/AVX2/AVX512, RDRAND/RDSEED) direto na CPU (processadores modernos).

Cliente – Bash
# Conferir suporte a aceleradores criptograficos na CPU:
grep -oE 'aes|avx2?|sha_ni|pclmulqdq|rdrand|rdseed' /proc/cpuinfo | sort -u;

Para que essas chaves não sejam comprometidas, o SSH usa métodos MAC/HMAC e Diffie-Helman para que as pontas possam combinar a mesma chave sem ter que transmiti-la pela rede, gerando chaves temporárias e de alta entropia. Esse conceito se chama “chaves efêmeras”.

Listar algoritmos de criptografia simétrica:

Cliente – Bash
# Listar cifras simétricas suportadas:
ssh -Q cipher;

Os tipos de criptografia simétrica mais utilizados são:

  • chacha20-poly1305@openssh.com: ChaCha20 com autenticação Poly1305 – rápida, segura, preferida em CPUs sem AES-NI;
  • aes256-gcm@openssh.com: AES 256-bit com modo GCM (autenticado);
  • aes128-gcm@openssh.com: AES 128-bit com modo GCM (autenticado);
  • aes256-ctr: AES 256-bit em modo CTR (contador);
  • aes192-ctr: AES 192-bit em modo CTR;
  • aes128-ctr: AES 128-bit em modo CTR;

Equipamentos fracos ou com CPU antiga: chacha20-poly1305@openssh.com;
Equipamentos modernos e servidores de última geração: aes256-gcm@openssh.com;

Tipos de criptografia simétrica suportados mas consideradas ultrapassadas (podem ser abandonadas no futuro):

  • aes256-cbc: AES 256-bit em modo CBC (menos seguro que CTR/GCM);
  • aes192-cbc: AES 192-bit em modo CBC;
  • aes128-cbc: AES 128-bit em modo CBC;
  • 3des-cbc: Triple DES, lento e insegudo, considerado o LIXO da criptografia.

Tipos descontinuados e extremamente velhos, uso deve ser evitado ou apenas para acessar equipamentos muito antigos e que não podem ser atualizados:

  • arcfour / arcfour128 / arcfour256: RC4 – removido no OpenSSH 7.6 (vulnerável);
  • blowfish-cbc: Removido no OpenSSH 7.6 (descontinuado);
  • cast128-cbc: Removido no OpenSSH 7.6 (descontinuado);
  • des-cbc: DES simples – removido há muito tempo (chave de 56 bits);
  • rijndael-cbc@lysator.liu.se: Versão antiga do AES-CBC (descontinuado);
  • none: Sem criptografia, desabilitado no código por padrão (inseguro, opera igual telnet).

Tipos especiais, normalmente não são suportados pelo OpenSSH mas podem se encontrados em produtos chinesses ou russos:

  • SM4 (China): Cifra de bloco de 128 bits, chave de 128, 32 rodadas, padronizado em GB/T 32907-2016. Usado no WAPI (autenticação wireless chinesa) e TLS.
  • Kuznyechik (Russia): Cifra de bloco de 128 bits, chave de 256 bits, definido no padrão GOST R 34.12-2015 e RFC 7801;
  • Magma (Russia): Cifra de bloco de 64 bits, chave de 256 bits, versão atualizada do antigo GOST 28147-89;
  • GOST 28147-89 (Russia): Cifra de bloco (legado), cifra soviética original de 1989, bloco de 64 bits, chave de 256 bits.

3 – Criptografia assimétrica

Chaves assimétricas tem princípios bem simples:

  • A chave privada é completa em sí, possui números que compõe a parte privada (sigilosa) e pública;
  • A chave pública é a parte compartilhável com todos livremente;
  • Ambas as chaves tem poderes de criptografia e descriptografia nos sentidos:
    • Privada => pública: o que a chave privada cifrar poderá ser revertido usando a chave pública. Esse sentido é chamado assinatura criptográfica, somente o dono da chave privada pode usá-la e todos que possuem a chave pública podem conferir a informação;
    • Pública => privada: todos que possuem a chave pública podem cifrar um conteúdo que somente o dono da chave privada pode decifrar;
  • Limite de bytes a serem cifrados: existe um limite no tamanho de bytes que podem compor e entrada na função de cifra, não é possível cifrar arquivos usando chaves assimétricas;
    • Assinatura: O uso mais prático é cifrar o HASH (MD5, SHA-256, SHA-512), mantendo a integridade dos dados;
    • Integridade: Cifrar o HASH permite a outra ponta conferir se o dado transmitido foi criado pela outra ponta e não foi adulterado em trânsito.

Uso das chaves:

  • Chaves do servidor (host key): usadas pelo servidor SSH para se identificar aos clientes. A chave pública do servidor é enviada a todos que se conectarem na porta do servidor;
  • Chaves do cliente (client key): são opcionais e por padrão não são inicialmente usadas. Elas podem ser criadas para identificar cada cliente como único e dar acessos e privilégios baseados na chave (autenticação sem senha e confiança SSH);

Vamos explorar melhor os tipos.

3.1 – Chaves do servidor (host keys)

São as chaves que o servidor SSH precisa para funcionar e se identificar.

Normalmente são geradas durante a instalação do servidor SSH ou durante a primeira execução e ficam armazenadas no diretório /etc/ssh/.

São fixas e perpétuas, ajudando a impedir parcialmente a possibilidade de ataque do homem no meio (MITM). Requer BACKUP e restauração para manter a coerência com os clientes.

Quando o cliente se conecta pela primeira vez no servidor a chave pública do servidor é armazenada localmente (arquivo .ssh/know_hosts) para que no futuro o cliente sempre confira se a chave pública do servidor permanece a mesma, se alguem tentar se colocar no meio do caminho o cliente se recusará a conectar por erro de chave do servidor.

Esse problema acontecerá se você reinstalar o servidor sem fazer backup das chaves!

Tipos e arquivos na pasta /etc/ssh/:

  • Tipo ECDSA: ssh_host_ecdsa_key e ssh_host_ecdsa_key.pub;
  • Tipo ED25519: ssh_host_ed25519_key e ssh_host_ed25519_key.pub;
  • Tipo RSA: ssh_host_rsa_key e ssh_host_rsa_key.pub;

Chaves assimétricas descontinuadas:

  • RSA <= 1024: RSA usando chaves com tamanho menor que 1024 bits são considerado inseguras e com risco elevado de serem quebradas;
  • DSA (DSS): Desabilitado por padrão desde o OpenSSH 7.0 e removido completamente no OpenSSH 9.8+;

Outros tipos de chaves assimétricas:

  • SM2 (China): baseado em curvas elípticas (similar a ECDSA);
  • SM9 (China): criptografia baseada em identidade (IBE);

Script para garantir existências das chaves do servidor:

Servidor – Bash
# Garantir existencia das chaves do servidor (host key):
/usr/sbin/dpkg-reconfigure -f noninteractive openssh-server;

Geração manual de chaves do servidor (não execute a menos que precise):

Servidor – Bash
# Entrar na pasta do servidor ssh /etc/ssh/
cd /etc/ssh;

# RSA (mínimo recomendado: 3072 ou 4096 bits)
ssh-keygen -t rsa   -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "";

# ECDSA (curva nistp256 por padrão)
ssh-keygen -t ecdsa -b 521  -f /etc/ssh/ssh_host_ecdsa_key -N "";

# ED25519 (tamanho fixo, não precisa de -b)
ssh-keygen -t ed25519       -f /etc/ssh/ssh_host_ed25519_key -N "";

# Parametros:
# -t = Tipo da chave (ecdsa, ed25519, rsa)
# -b = Tamanho em bits (não aplicável ao ED25519)
# -f = Caminho do arquivo de saída
# -N = Senha de protecao da chave privada, "" para deixar sem senha

# Ajustes de permissoes:
# Chaves privadas: somente root pode ler
chmod 600 /etc/ssh/ssh_host_*_key;

# Chaves públicas: todos podem ler
chmod 644 /etc/ssh/ssh_host_*_key.pub;

# Proprietário deve ser root
chown root:root /etc/ssh/ssh_host_*_key*;

3.2 – Chaves do cliente

O cliente não precisa gerar chaves, mas pode gerá-las para criar identidades para diferentes fins.

A identidade padrão “id_TIPO” é usada para dar uma identidade ao computador do cliente, exemplo:

Cliente – Bash
# Gerar chave de identidade pesssoal:

# Gerar chave tipo RSA:
ssh-keygen;
  #   Generating public/private ed25519 key pair.
  #   Enter file in which to save the key (/root/.ssh/id_ed25519): 
  #   Enter passphrase for "/root/.ssh/id_ed25519" (empty for no passphrase): 
  #   Enter same passphrase again: 
  #   Your identification has been saved in /root/.ssh/id_ed25519
  #   Your public key has been saved in /root/.ssh/id_ed25519.pub
  #   The key fingerprint is:
  #   SHA256:E5vg2qnO09zTnrHEA5qMIV5LJsZB+zFBplgfM7MTGwk root@cloud06.tmsoft.com.br
  #   The key's randomart image is:
  #   +--[ED25519 256]--+
  #   |  Eo@.           |
  #   | + =.@           |
  #   |. + B . .        |
  #   | . o = . +       |
  #   |  = * . S        |
  #   | o * B + +       |
  #   |  . +o*. .=      |
  #   |   ...o o..=     |
  #   |   .+.   o+      |
  #   +----[SHA256]-----+

No caso acima, apenas acionando o gerador de chaves ssh-keygen o padrão do comando optou pela chave do tipo ed25519 (pequena e muito segura), gerando os arquivos:

  • /root/.ssh/id_ed25519: chave privada, jamais compartilhe ou exiba na tela;
  • /root/.ssh/id_ed25519.pub: chave pública, pode ser distribuída livremente;

O cliente SSH (comando ssh) procura a chave privada local nos seguintes caminho:

  • /root/.ssh/id_rsa: para tipo RSA;
  • /root/.ssh/id_ed25519: para tipo ED25519;
  • /root/.ssh/id_ecdsa: para tipo ECDSA;

Assim, você pode ter essas 3 chaves ao mesmo tempo e suar a que for mais conveniente, comandos para gerar pontualmente as 3 chaves sem perigo de sobrescrever:

Cliente – Bash
# Entrar no diretorio $HOME do usuario logado:
cd;

# RSA de 3072 bits:
[ -s .ssh/id_rsa     ] || ssh-keygen -t rsa   -b 3072  -f .ssh/id_rsa     -N "";

# ECDSA de 521 bits:
[ -s .ssh/id_ecdsa   ] || ssh-keygen -t ecdsa -b 521   -f .ssh/id_ecdsa   -N "";

# ED25519:
[ -s .ssh/id_ed25519 ] || ssh-keygen -t ed25519        -f .ssh/id_ed25519 -N "";

# DSA (para servidores e equipamentos velhos, nao ser suportada nos novos):
#[ -s .ssh/id_dsa    ] || ssh-keygen -t dsa            -f .ssh/id_dsa -N "";

Com suas chaves de identidade local você poderá usar os recursos apresentados a seguir!

3.3 – Dilema do tamanho das chaves

Um dilema é escolher o tamanho das chaves, visando usar chaves que sejam reconhecidas por todos os sistemas modernos e recentes.

Não dá pra arrastar chaves inseguras por muito tempo, sistemas modernos tentem a exigir chaves de última geração e retirar suporte a chaves inseguras e antigas.

Tamanhos por tipo:

  • RSA: normalmente iniciando com tamanho de 1024 bits, passando por 2048 bits e atualmente aceitável em 3072 bits, em breve o mínimo será 4096 bits;
    • Dilema 1: tenho conseguido usar minha chave de 2048 bits em quase todos os sistemas, mas recentemente tenho que configurar equipamentos modernos para aceitar o tamanho 2048 visto que já migraram para o padrão 3072;
    • Dilema 2: tenho uma chave de 4096 que uso para para todos os servidores Linux, mas não consigo fazê-la funcionar em roteadores e switchs;
  • RSA extremo: você pode gerar chaves de 4096, 8192, 16384 (limite do OpenSSH), ou qualquer tamanho personalizado que desejar, basta esperar uma eternidade pela geração de números primos, raramente você conseguirá usar chaves acima de 16384 bits;
  • ED25519: o ed25519 tem tamanho fixo de 256 bits e se tornou o novo padrão de chaves para o protocolo SSH, é semelhante a segurança da chave RSA-3072. Infelizmente equipamentos antigos não reconhecem esse tipo de chave;
  • ECDSA: tem suporte a tamanhos 256, 384, and 521 bits, o problema é que usando 512 bits a segurança é semelhante a usar ED25519, não fazendo muito sentido usá-la.

Tabela comparativa:

AlgoritmoBits da ChaveEquivalênciaComparação RSA
ECDSA P-256256~128 bitsRSA-3072
ECDSA P-384384~192 bitsRSA-7680
ECDSA P-521521~256 bitsRSA-15360
ED25519256~128 bitsRSA-3072

Conclusão:

  • Tenha uma chave RSA 3072;
  • Use por padrão ed25519;

3.4 – Criando todos os tipos e tamanhos de chaves

Exemplos de como gerar todos os tipos de chaves para uso no SSH:

Cliente – Bash
# Tipo: RSA, tamanho definido em numero de bits:
ssh-keygen  -t rsa   -b  1024  -f /tmp/rsa-1024   -N "";
ssh-keygen  -t rsa   -b  2048  -f /tmp/rsa-2048   -N "";
ssh-keygen  -t rsa   -b  3072  -f /tmp/rsa-3072   -N "";
ssh-keygen  -t rsa   -b  4096  -f /tmp/rsa-4096   -N "";
ssh-keygen  -t rsa   -b  8192  -f /tmp/rsa-8192   -N ""; # pode demorar
ssh-keygen  -t rsa   -b 16384  -f /tmp/rsa-16384  -N ""; # vai demorar
ssh-keygen  -t rsa   -b 32768  -f /tmp/rsa-32768  -N ""; # vai demorar demais!
ssh-keygen  -t rsa   -b 65536  -f /tmp/rsa-65536  -N ""; # nem tente!

# Gerando chaves RSA de tamanhos personalizados:
ssh-keygen  -t rsa   -b 1025   -f /tmp/rsa-1025   -N "";
ssh-keygen  -t rsa   -b 1983   -f /tmp/rsa-1983   -N "";
ssh-keygen  -t rsa   -b 2222   -f /tmp/rsa-2222   -N "";
ssh-keygen  -t rsa   -b 3333   -f /tmp/rsa-3333   -N "";


# Tipo: DSA (descontinuado):
#ssh-keygen -t dsa      -f  /tmp/dsa -N "";


# Tipo: ECDSA, 3 tamanhos:
ssh-keygen  -t ecdsa -b 256  -f /tmp/ecdsa-256  -N ""; # nistp256
ssh-keygen  -t ecdsa -b 384  -f /tmp/ecdsa-384  -N ""; # nistp384
ssh-keygen  -t ecdsa -b 521  -f /tmp/ecdsa-521  -N ""; # nistp521


# Tipo: ed25519, tamanho unico:
ssh-keygen  -t ed25519  -f /tmp/ed25519  -N "";

3.5 – Coletando chaves públicas dos servidores

O comando ssh-keyscan serve ao cliente como método de aprender todas as chaves públicas dos servidores em uma infra (datacenter, backbone) e, opcionalmente, salvá-las no arquivo ~/.ssh/known_hosts (cadastro de chaves públicas). Exemplo de uso:

Cliente – Bash
# Aprender as chaves públicas dos servidores da infra

# Obter apenas chaves ED25519:
ssh-keyscan -p 22022 -t ed25519 vps1.meu-dominio.com;
    # vps1.meu-dominio.com:22022 SSH-2.0-OpenSSH_10.0p2 Debian-7 OpenSSH_11
    # [vps1.meu-dominio.com]:22022 ssh-ed25519 AAAAC3NzaC1...OqvtN3Tz3i28in

# Escanear em porta diferente:
ssh-keyscan -p 2222 vps2.meu-dominio.com;

# Adicionar todas as chaves do servidor ao known_hosts com hash:
ssh-keyscan -H vps3.meu-dominio.com >> ~/.ssh/known_hosts;

# Escanear múltiplos hosts de um arquivo:
ssh-keyscan -f lista-servidores.txt;

# Múltiplos tipos de chave:
ssh-keyscan -t rsa,ed25519 vps4.meu-dominio.com;

# Com timeout de 5 segundos
ssh-keyscan -T 5 vps5.meu-dominio.com;

# Verificar a chave primeiro
ssh-keyscan -t ed25519 vps6.meu-dominio.com;

# Se estiver correta, adicionar ao known_hosts
ssh-keyscan -t ed25519 -H vps7.meu-dominio.com >> ~/.ssh/known_hosts;

3.6 – Removendo chaves públicas do inventário do cliente

Pode acontecer de um servidor/VPS/VM ser reinstalado sem backup das chaves já aprendidas pelos clientes, resultando em falhas por detecção de ataque MITM.

O arquivo ~/.ssh/known_hosts é responsável por esse cadastro e pode ser editado manualmente ou manipulado pelo comando “ssh-keygen -R“.

Exemplo de como apagar as chaves aprendidas de um servidor:

Cliente – Bash
# Remover chave publica aprendida

# - Remover pelo nome do servidor:
ssh-keygen  -R  vps8.meu-domino.com;
ssh-keygen  -R  45.255.128.3;

# - Remover pelo nome do servidor com porta diferente do padrão (22):
ssh-keygen  -R  "[vps9.meu-domino.com]:22022";
ssh-keygen  -R  "[45.255.128.3]:22022";

Embora seja mais grosseiro, apagar o arquivo ~/.ssh/known_hosts é uma opção.

4 – Confiança SSH – Login por chave pública

Ao se conectar a um servidor SSH, ele exigirá algum método de autenticação, por padrão o primeiro método é “password” (informe sua senha).

Se o cliente possuir chaves de identidade padrão elas serão enviadas ao servidor se ele apresentar capacidade de “publickey” como método de autenticação.

O servidor aceitará usar a chave no lugar da senha se a chave pública apresentada pelo cliente estiver previamente cadastrada no servidor (authorized_keys).

O arquivo no servidor que contêm esse cadastro é, por padrão:

  • $HOME/.ssh/authorized_keys
    • Se você tentar logar com o usuário suporte no servidor, o arquivo lido será:
      • /home/suporte/.ssh/authorized_keys
    • Se entrar logar como root, o arquivo será:
      • /root/.ssh/authorized_keys

Lembrando que o valor de $HOME é relativo ao usuário e definido no cadastro do login no arquivo /etc/passwd.

Por padrão a maioria das pessoas opta por cadastrar sua chave no /root/.ssh/authorized_keys para entrar como “root” sem senha!

O arquivo authorized_keys deve receber o conteúdo da chave pública do cliente (exemplo .ssh/id_ed25519.pub), uma declaração por linha.

Feito isso, basta se conectar ao servidor SSH que ele lhe dará shell instantaneamente!

Meu método: armazeno um arquivo contendo minha chave pública pessoal no meu site, e quando entro em um servidor pela primeira vez eu faço o download e coloco no arquivo authorized_keys, exemplo:

Servidor – Bash
# Baixar chave publica hospedada no site:
wget -O /root/minha-chave.pub  "https://ajustefino.com/minha-chave.pub";

# Garantir existencia do authorized_keys
mkdir -p /root/.ssh;
touch /root/.ssh/authorized_keys;

# Jogar chave pública dentro do authorized_keys
# obs.: cuidado para nao violar o principio de uma chave por linha,
#       sempre coloque linhas vazias entre as chaves por seguranca.
(
    echo;
    cat /root/minha-chave.pub;
    echo;
) >> /root/.ssh/authorized_keys;

5 – Chave de acesso à VPS

Uma técnica muito comum em datacenters (Amazon por exemplo) é a geração de chaves de confiança direto no servidor para serem enviadas aos clientes por canal seguro, principalmente pelo painel da VPS.

Nesse método o datacenter não fornece senha de root nem de usuário comum, somente a chave privada que dá acesso ao servidor.

Exemplo de geração de chave confiável no servidor:

Servidor – Bash
# Procedimentos no servidor para gerar chave privada
# de acesso em ambiente sem senhas.

# Caminho da chave:
KEYFILE="/etc/ssh/vps-master-key";
PUBFILE="/etc/ssh/vps-master-key.pub";

# 1. Gerar chave privada
[ -s "$KEYFILE" ] || ssh-keygen -t ed25519 -f "$KEYFILE" -N "" -C "VPS-MASTER-KEY";

# 2. Extrair chave pública (comando acima ja faz isso, apenas garantir)
[ -s "$PUBFILE" ] || ssh-keygen -f  "$KEYFILE" -y  > "$PUBFILE";

# 3. Garantir existencia do authorized_keys
mkdir -p /root/.ssh;
touch /root/.ssh/authorized_keys;

# 4. Cadastrar chave publica no arquivo authorized_keys
# - usar comentario como identificador para impedir duplicacao
grep -q "VPS-MASTER-KEY" /root/.ssh/authorized_keys || {
    # Nao encontrado, precisa inserir
    (
        echo;
        cat "$PUBFILE";
        echo;
    ) >> /root/.ssh/authorized_keys;
};


# --------------------------------- OPCIONAL ---------------------------------

# 5. Fazer upload da chave privada para o cofre do datacenter
# - usar UUID da BIOS da VPS/VM como identificador unico
#   da VPS
# - formato da url da API:
#   https://api.meu-datacenter.com/v1/valt/masterkey/UUID-DA-VPS-AQUI
#
VALT_API_URL="https://api.meu-datacenter.com/v1/valt/masterkey";
BIOS_UUID=$(head -1 /sys/devices/virtual/dmi/id/product_uuid);
if [ -z "$BIOS_UUID" ]; then
    # nao localizou o UUID da bios virtual
    echo "# Falha, sem UUID de bios virtual";
else
    # ok, enviar
    curl \
        -X POST \
        --data-binary "@$KEYFILE" \
        "$VALT_API_URL/$BIOS_UUID";
fi;

Uma vez que o datacenter criou a VM/VPS com um UUID de BIOS, esse UUID é vinculado na conta do cliente que solicitou o serviço.

Quando o cliente acessar o painel, o sistema irá buscar as chaves vinculadas aos UUIDs dos serviços que ele contratou e as disponibilizará para download (exemplo de nome do arquivo baixado: VPS-1234-MASTER-KEY.key). O cliente fará o primeiro acesso assim:

Cliente – Bash
# Acesso usando chave privada:

# Corrigir permissao de acesso no arquivo da chave privada:
chmod 0600 VPS-1234-MASTER-KEY.key;

# Testar acesso:
# - porta padrao 22, alguns datacenters mudam para evitar estresse com bots
# - chave de acesso no arquivo baixado
ssh  -i VPS-1234-MASTER-KEY.key  root@200.216.14.25;

6 – Chaveiro e cofre (VALT) do cliente

Pense nesse problema: você tem sua chave pessoal e a utiliza para servidores privados (VPS) e para servidores de um datacenter. Você está de férias e seu chefe te pede sua chave privada para ter acesso à infra, você quer que sua chave privada vá parar no Google Driver dele?

A melhor maneira é reservar sua chave privada para suas coisas pessoais e criar uma chave por finalidade, exemplos:

  • xpto: para acessar todos os servidores do datacenter XPTO;
  • acme: para acessar a infra da empresa ACME;
  • backbone: para acessar switchs MPLS do backbone;
  • borders: para acessar roteadores BGP;
  • bgp-01: chave específica do usuário “suporte” no roteador BGP-01;

Criando uma chave por finalidade, você não corre riscos desnecessários.

Outro recurso importante é proteger a chave por senha (criptografia simétrica), assim você pode hospedar sua chave até mesmo no Google Drive, que só será possível usá-la por meio da senha solicitada em tempo de execução pelo comando ssh.

6.1 – Criando chaves

Cliente – Bash
# Gerar chaves por finalidade, com senha
# - Chave para datacenter XPTO, senha: tulipa
ssh-keygen -t ed25519 -N "tulipa" -f ~/.ssh/xpto_ed25519 -C "Datacenter-XPTO";

# - Chave para a empresa Acme, senha: javali
ssh-keygen -t ed25519 -N "javali" -f ~/.ssh/acme_ed25519 -C "Acme";

# - Chave do backbone MPLS, senha: morango
ssh-keygen -t ed25519 -N "morango"   -f ~/.ssh/backbone_ed25519 -C "Backbone MPLS";

# - Chave dos roteadores BGP, senha: 123mudar
ssh-keygen -t ed25519 -N "123mudar"  -f ~/.ssh/borders_ed25519 -C "Roteadores BGP";

# - Chave do usuario "suporte" no roteador "BGP-01", senha: madmax2025
ssh-keygen -t ed25519 -N "madmax2025" -f ~/.ssh/srv-995_ed25519 -C "SUP-BGP-01";

Os arquivos das chaves privadas agora podem ser enviadas por e-mail, whatsapp, hospedadas em URLs abertas, somente sabendo a senha será possível usá-las.

Obviamente as senhas acima são inseguras, opte por senhas inquebráveis.

6.2 – Manipulando as chaves privadas

Mudando a senha de proteção da chave:

Cliente – Bash
# Muda senha da chave xpto_ed25519 de "tulipa" para "NaoUse123Mudar"
ssh-keygen  -p  -f ~/.ssh/xpto_ed25519  -P "tulipa"  -N "NaoUse123Mudar";
    # Key has comment 'Datacenter-XPTO'
    # Your identification has been saved with the new passphrase.

Retirando senha da chave (colocando senha em branco):

Cliente – Bash
# Retirar a senha: basta mudar da senha atual para senha em branco:
ssh-keygen  -p  -f ~/.ssh/xpto_ed25519  -P "NaoUse123Mudar"  -N "";
    # Key has comment 'Datacenter-XPTO'
    # Your identification has been saved with the new passphrase.

Extrair a chave pública de dentro da chave privada:

Cliente – Bash
# Extraindo chave pública (formato OpenSSH):
ssh-keygen  -f  ~/.ssh/xpto_ed25519  -y;
    # ssh-ed25519 AAAAC3NzaC1lZD........ZU1i9v Datacenter-XPTO

# Extraindo chave pública (formato OpenSSH) e salvando no arquivo .pub:
ssh-keygen  -f  ~/.ssh/xpto_ed25519  -y  > ~/.ssh/xpto_ed25519.pub;

# Obs: se a chave possuir senha, informe -N "senha" para extracao nao-interativa.

# Exibir chave publica exraida:
cat .ssh/xpto_ed25519.pub;
  # ssh-ed25519 AAAAC3NzaC1lZDI1...WPnLZU1i9v Datacenter-XPTO

Extrair fingerprint da chave pública (bom para armazenamento em API e SQL):

Cliente – Bash
# Obtendo fingerprint (SHA256):
ssh-keygen  -f  ~/.ssh/xpto_ed25519 -l;
  # 256 SHA256:ExyTh1pk3U...BS2k0U9hUaKM Datacenter-XPTO (ED25519)

# Obtendo fingerprint (SHA256):
ssh-keygen  -f  ~/.ssh/xpto_ed25519 -l -E sha256;
  # 256 SHA256:ExyTh1pk3...U9hUaKM Datacenter-XPTO-Chave-Auxiliar (ED25519)

# Obtendo fingerprint (MD5):
ssh-keygen  -f  ~/.ssh/xpto_ed25519 -l -E md5;
  # 256 MD5:c5:04:44:25:...:95:ad:d0:d6 Datacenter-XPTO (ED25519)

# Obtendo chave publica "bubblebabble" (ASCII):
ssh-keygen  -f  ~/.ssh/xpto_ed25519 -B;
  # 256 xedir-...-nobyd-roryn-fuxox Datacenter-XPTO (ED25519)

# Obtendo chave publica formato RFC4716 (PEM):
ssh-keygen  -f  ~/.ssh/xpto_ed25519 -e -m RFC4716;
  # ---- BEGIN SSH2 PUBLIC KEY ----
  # Comment: "256-bit ED25519, converted by root@srv01.intranet.br"
  # AAAAC3NzaC1lZDI1NTE5AAAAIKa5QjU2nAPDy+RLa9d9WE00uLju0i94aAWPnLZU1i9v
  # ---- END SSH2 PUBLIC KEY ----

Alterando comentário da chave privada:

Cliente – Bash
# Colocar comentário específico na chave privada:
ssh-keygen -c -f ~/.ssh/xpto_ed25519 -C "Datacenter-XPTO-Chave-Auxiliar";
    # Old comment: Datacenter-XPTO
    # Comment 'Datacenter-XPTO-Chave-Auxiliar' applied

Exibindo detalhes da chave:

Cliente – Bash
# Exibir detalhes da chave privada:
ssh-keygen -lf ~/.ssh/xpto_ed25519;
  # 256 SHA256:ExyTh1p..k0U9hUaKM Datacenter-XPTO-Chave-Auxiliar (ED25519)

# Exibicao com quadro ASCII:  
ssh-keygen -lvf ~/.ssh/xpto_ed25519;
  # 256 SHA256:ExyTh1p..k0U9hUaKM Datacenter-XPTO-Chave-Auxiliar (ED25519)
  # +--[ED25519 256]--+
  # |       .O*+Boo++.|
  # |       +=B++**o..|
  # |       *=..o*.=  |
  # |      oE=..o * . |
  # |       +So  + = .|
  # |      .  ..  o ..|
  # |                .|
  # |                 |
  # |                 |
  # +----[SHA256]-----+

# Extraindo notacao hexadecimal da chave privada
# chave privada => extrair base64 => converter para binario => hexdump para exibir
awk '{print $2}' ~/.ssh/xpto_ed25519.pub | base64 -d | hexdump;
    # 0000000 0000 0b00 7373 2d68 6465 3532 3135 0039
    # 0000010 0000 a620 42b9 3635 039c cbc3 4be4 d76b
    # 0000020 587d 344d b8b8 d2ee 782f 0568 9c8f 54b6
    # 0000030 2fd6 006f                              
    # 0000033

7 – Servidor SSH

O servidor SSH é onde todos os serviços são prestados a pedido do cliente:

  • Shell: Abrir um shell com terminal;
  • Exec: Executar um comando remoto;
  • Forwarding: Abrir uma porta no servidor para forwarding TCP;
  • Binding: Abrir uma porta local e mapear uma porta no servidor para receber tráfego;
  • SFTP: Transferir arquivo, enviar ou copiar;
  • X11: fazer uso de interface gráfica X11 transportada por SSH;
  • Agente: usar o servidor como hospedagem de chaves para acessar outros servidores SSH;
  • VPN: criar um túnel VPN sobre TCP (performance questionável por tcp-meltdown) para transporte de quadros (tap: L2/ethernet) ou pacote (IP, tun);

7.1 – Personalizar servidor SSH

Personalizar o arquivo /etc/ssh/sshd_config não é uma boa estratégia pois os updates não gostam de diferenças nesse arquivo.

A melhor maneira é usar o diretório /etc/ssh/sshd_config.d/ para criar os arquivos avulsos com suas personalizações.

Exemplo de parametrização completas para melhor performance e recursos totais:

Servidor – Bash
# Abrir porta padrao 22:
echo "Port                    22" > /etc/ssh/sshd_config.d/inc-port-main.conf;

# Abrir porta adicional
echo "Port                 22022" > /etc/ssh/sshd_config.d/inc-port-alt.conf;

# Abrir portas em IPv4 e IPv6
echo "AddressFamily         any"  > /etc/ssh/sshd_config.d/inc-addr-family.conf;

# Endereço IPv4 de escuta, 0.0.0.0 = todos os IPv4 do servidor
echo "ListenAddress     0.0.0.0"  > /etc/ssh/sshd_config.d/inc-listen-ipv4.conf;

# Endereço IPv6 de escuta, :: = todos os IPv6 do servidor
echo "ListenAddress          ::"  > /etc/ssh/sshd_config.d/inc-listen-ipv6.conf;

# Desativar exibição do motd do OpenSSH, ainda mantem o /etc/motd do bash
echo "PrintMotd              no"  > /etc/ssh/sshd_config.d/inc-motd.conf;

# Flags de cabeçalho IP para tratamento QoS diferenciado
echo "IPQoS  lowdelay throughput" > /etc/ssh/sshd_config.d/inc-ipv4-qos.conf;

# Ativar keep-alive de TCP (camada 4)
echo "TCPKeepAlive            yes" > /etc/ssh/sshd_config.d/inc-tcp-alive.conf;

# Ativar keep-alive de SSH (camada 5)
echo "ClientAliveInterval       3" >  /etc/ssh/sshd_config.d/inc-ssh-alive.conf;
echo "ClientAliveCountMax      15" >> /etc/ssh/sshd_config.d/inc-ssh-alive.conf;

# Ativar autenticacao com uso de senha digitavel
echo "PasswordAuthentication  yes" > /etc/ssh/sshd_config.d/inc-pass-auth.conf;

# Não permitir login de usuarios sem senha
echo "PermitEmptyPasswords     no" > /etc/ssh/sshd_config.d/inc-pass-empty.conf;

# Permitir encaminhamento pelo ssh-agent
echo "AllowAgentForwarding   yes" > /etc/ssh/sshd_config.d/inc-agent-forward.conf;

# Permitir encaminhamento de porta remota
echo "AllowTcpForwarding      yes" > /etc/ssh/sshd_config.d/inc-tcp-forward.conf;

# Permitir encaminhamento de servidor X11 por meio de conexao SSH
echo "X11Forwarding           yes" > /etc/ssh/sshd_config.d/inc-x11.conf;

# Permitir que o cliente especifique ips e portas para encaminhamento
echo "GatewayPorts clientspecified" > /etc/ssh/sshd_config.d/inc-gateway-ports.conf;

# Permitir que o cliente especifique IPs a escutar em portas remotas
echo "PermitListen            any" > /etc/ssh/sshd_config.d/inc-permit-listen.conf;

# Permitir abertura de terminal (necessario para usuario conseguir um shell)
echo "PermitTTY               yes" > /etc/ssh/sshd_config.d/inc-tty.conf;

# Permitir usar o SSH para fazer VPN
echo "PermitTunnel            yes" > /etc/ssh/sshd_config.d/inc-tunnel.conf;

# Permitir variaveis do shell do usuário transferidas para o lado servidor
echo "PermitUserEnvironment    no" > /etc/ssh/sshd_config.d/inc-user-env.conf;

# Nao exibir o ultimo login do usuario ao entrar no shell via SSH
echo "PrintLastLog             no" > /etc/ssh/sshd_config.d/inc-lastlog.conf;

# Desativar compressão de dados (shell mais responsivo)
echo "Compression              no" > /etc/ssh/sshd_config.d/inc-compression.conf;

# Nao consultar DNS reverso do ip do usuário no inicio da conexão
echo "UseDNS                   no" > /etc/ssh/sshd_config.d/inc-dns.conf;

# Especificar fingerprint de versão
echo "VersionAddendum    OpenSSH_10" >> /etc/ssh/sshd_config.d/inc-version.conf;

# Permitir que o root faça login usando senha
echo "PermitRootLogin          yes" >  /etc/ssh/sshd_config.d/inc-permit-root.conf;
# -- ou: PermitRootLogin prohibit-password

# Permitir autenticação usando chave publica
echo "PubkeyAuthentication     yes" >  /etc/ssh/sshd_config.d/inc-pubkey.conf;

# Renegociar chaves simetricas a cada 1G transferido ou a cada 1h de sessão
echo "RekeyLimit              1G 1h" >  /etc/ssh/sshd_config.d/inc-rekey.conf;

# Tamanho ma­nimo da chave RSA aceita:
echo "RequiredRSASize          2048" >  /etc/ssh/sshd_config.d/inc-rsa-size.conf;

# Opcoes muito perigosas e sensiveis:
#echo "LoginGraceTime             1m" >  /etc/ssh/sshd_config.d/inc-login-time.conf
#echo "MaxAuthTries                2" >  /etc/ssh/sshd_config.d/inc-max-auth.conf
#echo "MaxSessions               128" >  /etc/ssh/sshd_config.d/inc-max-sessions.conf
#echo "MaxStartups         16:32:100" >  /etc/ssh/sshd_config.d/inc-max-startups.conf
#echo "PerSourceMaxStartups       16" >  /etc/ssh/sshd_config.d/inc-ip-startups.conf
#echo "PerSourceNetBlockSize   22:32" >  /etc/ssh/sshd_config.d/inc-net-size.conf
#echo "PermitUserRC              yes" >  /etc/ssh/sshd_config.d/inc-permit-rc.conf
#AM="publickey password";
#echo "AuthenticationMethods $AM" >/etc/ssh/sshd_config.d/inc-auths.conf
# Suportar todas as cifras (criptografia simetrica):
#echo -n > /etc/ssh/sshd_config.d/inc-ciphers.conf
#for opt in $(ssh -Q cipher); do
#    echo "Ciphers +$opt" >> /etc/ssh/sshd_config.d/inc-ciphers.conf
#done
# Suportar todos os hashes de autenticação de mensagens:
#echo -n > /etc/ssh/sshd_config.d/inc-macs.conf
#for opt in $(ssh -Q mac); do
#    echo "MACs +$opt" >> /etc/ssh/sshd_config.d/inc-macs.conf
#done
# Suportar todos os tipos de chaves efêmeras:
#echo -n > /etc/ssh/sshd_config.d/inc-kex.conf
#for opt in $(ssh -Q kex); do
#    echo "KexAlgorithms +$opt" >> /etc/ssh/sshd_config.d/inc-kex.conf
#done

Conferir se as configurações finais estão funcionando:

Servidor – Bash
# Testar configuracao:
sshd -t -f /etc/ssh/sshd_config && { echo; echo CONFIG SSHD OK; echo; }

Reiniciar servidor SSH (não afeta a conexão atual, não feche essa janela, abra outra e tente conectar, se algo der errado continue mexendo na tela conectada para arrumar)

Servidor – Bash
# Reiniciar servidor ssh para aplicar:
service ssh restart;

7.2 – Analise de logs do servidor SSH

Analisar os logs é importante para saber quem está abusando do seu servidor (bots) e tentativas de acesso indevido, alem de auditoria.

Servidor – Bash
# Visualizar todos os logs:
journalctl  -u  ssh;

# Acompanhar log em tempo real:
journalctl  -u  ssh -f;
journalctl  -u  ssh -f --full;

# Ver todos os logs sem pausa:
journalctl  -u  ssh --no-pager;

# Ver logs das últimas 24 horas, 1 minuto:
journalctl  -u  ssh --since "24 hours ago";
journalctl  -u  ssh --since "1 minute ago" --no-pager;

# Ver logs com mais detalhes:
journalctl  -u  ssh --no-pager --full;

# Ver apenas últimas 50 linhas:
journalctl  -u  ssh -n 50;

# Ver em ordem reversa (recentes primeiro)
journalctl  -u  ssh -r;

# Ver logs no período:
journalctl  -u  ssh --since "2024-01-01" --until "2024-01-03";

# Ver logs com nível de prioridade: 
journalctl  -u  ssh -p err;

# Rotação - forçar rotação e limpeza dos logs do SSH
journalctl  -u  ssh  --rotate;

# Limpar locs (vacuum) - manter apenas logs dos últimos 1 segundo:
journalctl  -u  ssh  --vacuum-time=1s;

# Limpar locs (vacuum) - limitar tamanho dos logs do SSH para 1KB
journalctl  -u  ssh  --vacuum-size=1K;

# Limpar locs (vacuum) - manter apenas 1 arquivo de log
journalctl  -u  ssh  --vacuum-files=1;

# Conferir espaço usado para logs:
journalctl --disk-usage;

# Limpar todos os logs de todos os serviços (cuidado):
## journalctl --vacuum-time=1s

8 – Usando serviços do servidor SSH

Vou mostrar vários exemplos de como usar os recursos do servidor SSH.

8.1 – Shell e terminal

Esse é o serviço mais comum e a maioria das pessoas acreditar que essa é a única utilidade do SSH.

Cliente – Bash
# Logando no servidor, várias formas de usar o SSH client:
# Com usuario comum:
ssh      suporte@45.255.128.2;
ssh      suporte@2804:cafe:fada::2;

# Como root (requer config no servidor PermitRootLogin yes):
ssh      root@45.255.128.2;
ssh      root@2804:cafe:fada::2;

# Logando especificando usuario em argumento separado:
ssh  -l  suporte  45.255.128.2;
ssh  -l  root     45.255.128.2;

# Especificando a porta do servidor SSH:
ssh  -l  suporte  45.255.128.2 -p 22022;
ssh  -l  root     45.255.128.2 -p 22022;

# Especificando uma chave privada no cliente para autenticacao publickey:
ssh  -l  suporte  45.255.128.2 -i ~/.ssh/xpto_ed25519;

# Impedir o envio da chave publica das identidades locais (chaves id_*):
ssh  -l  suporte  45.255.128.2 -o PubkeyAuthentication=no;

8.2 – Executar comando remoto (sem shell) no servidor

Nesse método o SSH é usado para enviar um comando que o servidor deve executar. O comando solicitado é executado em um processo filho do sshd (fork) e o retorno (stdno, stdout e stderr) é fornecido ao cliente como retorno.

Cliente – Bash
# Logando no servidor e rodando um programa no servidor:
# Obtendo conteudo de arquivo (comando cat):
ssh      suporte@45.255.128.2        "cat /etc/os-release";
ssh      suporte@2804:cafe:fada::2   "cat /etc/os-release";

# Comandos encadeados
ssh  -l  suporte  45.255.128.2       "cat /etc/os-release | egrep ID";
ssh  -l  suporte  45.255.128.2       "cat /etc/os-release | egrep ID";

# Especificando chave privada local, rodando remotamente como root:
ssh  -l  root  45.255.128.2  -i ~/.ssh/xpto_ed25519  "swapoff -a";
ssh  -l  root  45.255.128.2  -i ~/.ssh/xpto_ed25519  "swapon  -a";

8.3 – SFTP – Transferindo arquivos entre cliente e servidor

O modo SFTP é exercido pelo comando scp e possui algumas limitações, agindo muito próximo ao FTP (“FTP sobre SSH”).

Cliente – Bash
# Criando arquivo local
echo "O rato roeu a roupa do rei de roma" > /tmp/frase.txt;

# UPLOAD - Copiando arquivo local para o servidor:
    # - Somente informando o diretorio
    scp -P 22  /tmp/frase.txt   root@45.255.128.2:/tmp/;

    # - Com nome diferente no servidor:
    scp -P 22  /tmp/frase.txt   root@45.255.128.2:/tmp/frase-copiada.txt;

# DOWNLOAD - Copiando arquivo do servidor para o cliente:
    # - Somente informando o diretorio local
    scp -P 22  root@45.255.128.2:/tmp/frase-copiada.txt  /tmp/;

    # - Com nome local diferente no servidor:
    scp -P 22  root@45.255.128.2:/tmp/frase-copiada.txt  /tmp/frase1.dat;

8.4 – Túnel TCP sobre SSH

O túnel TCP é uma forma de transportar conexões que chegam em uma porta aberta pelo cliente ou pelo servidor e entregar ao mapeamento de transporte. Esse mapeamento pode ser local ou remoto.

O servidor deve possuir as configurações para permitir os encaminhamentos:

  • GatewayPorts
    • no: só localhost pode acessar (padrão);
    • yes: Qualquer IP pode acessar
    • clientspecified: Cliente decide o bind address no servidor;
  • AllowTcpForwarding:
    • yes: Permite encaminhamento local e remoto (padrão);
    • local: Permite apenas encaminhamento local;
    • remote: Permite apenas encaminhamento remoto;

Requerido: mudar GatewayPorts para clientspecified;

8.4.1 – Local Port Forwarding (-L)

O mapeamento local é realizado pelo cliente, que abre uma porta TCP (A) no sistema local e todas as conexões que entram nessa porta local são transportadas até o servidor SSH (B), que por sua vez faz um mapeamento em modo cliente TCP até o destino final (C).

Porta local 8001 é aberta localmente e transportada até o servidor SSH, que se conecta ao site privado http://10.249.255.10, fazendo papel de proxy-tcp.
Cliente – Bash
# Comando para fazer o mapeamento acima:
# -N: nao inicia um shell, o comando apenas serve ao túnel proxy-tcp
# -L: IP-LOCAL:PORTA-LOCAL:IP-FINAL:PORTA-FINAL
ssh -N -L 127.0.0.1:8001:10.249.255.10:80  root@45.255.128.2 -p 22;

# Outra forma: especificar apeans a porta, assim todos os IPs presentes
#              no cliente poderão ser usados para entrar no túnel
ssh -N -L           8001:10.249.255.10:80  root@45.255.128.2 -p 22;

Com o comando acima, no cliente, acesse (A) http://127.0.0.1:8001/ para abrir o site (C).

Nota: sem o argumento “-N” o comando acima abrirá um shell para o servidor, você pode usar esse shell enquanto o mapeamento funciona. Ao fechar o shell o mapeamento será encerrado junto.

Dica: Esse método é muito bom para acessar portas abertas em containers Docker!

8.4.2 – Remote Port Forwarding (-R)

Esse modo inverte o sentido do tráfego. A porta é aberta no servidor e condiz o tráfego até o cliente. É útil para publicar um sistema rodando no cliente em uma porta que será aberta em um servidor com IP público.

Servidor SSH abre a porta 9080 (A), as conexões de entrada são entregues ao cliente (B) que conduz a conexão estrangeira até a porta local 8081 (no cliente).
Cliente – Bash
# Comando para fazer o mapeamento acima:
# -N: nao inicia um shell, o comando apenas serve ao túnel proxy-tcp
# -R: IP-SERVIDOR:PORTA-REMOTA:IP-LOCAL:PORTA-LOCAL
ssh -N -R 45.255.128.2:9080:127.0.0.1:8081   root@45.255.128.2 -p 22;

# Outra forma: especificar apeans a porta remota, assim todos os IPs presentes
#              no servidor poderão ser usados para entrar no túnel
ssh -N -R              9080:127.0.0.1:8081   root@45.255.128.2 -p 22;
ssh -N -R      0.0.0.0:9080:127.0.0.1:8081   root@45.255.128.2 -p 22;

Dica: esse método é muito bom para mostrar sistemas rodando localmente para usuários na Internet.

Há quem use esse método de Remote Port Forward para publicar sites em VPS (IP público na nuvem, servidor local em qualquer lugar).

8.5 – VPN SSH

O SSH permite transportar quadros (ethernet) e pacotes (IPv4, IPv6) dentro da conexão SSH e injetá-los em buffer de interface de rede por meio dos módulos TAP e TUN do kernel Linux.

8.5.1 – Preparar servidor SSH para prover VPN

Preparativos:

Servidor – Bash
# Preparativos
# 1 - Garantir módulo de tunelamento do kernel funcional
#     tun: VPN de pacotes IP (L3)
#     tap: VPN de quadros Ethernet (L2)
modprobe tun;
modprobe tap;

# 2 - Colocar pra carregar no boot do Linux:
echo "tun" > /etc/modules-load.d/tun.conf;
echo "tap" > /etc/modules-load.d/tap.conf;

# 3 - Garantir existência do ponteiro "tun" para provi:
mkdir -p /dev/net;
[ -e /dev/net/tun ] || mknod /dev/net/tun c 10 200 && chmod 666 /dev/net/tun;

Parâmetros requeridos no servidor SSH (/etc/ssh/sshd_config.d/):

  • PermitTunnel yes: para permitir criação de túneis;
  • Compression no: opcional, compressão não ajuda a latência, se você trafega somente texto (HTTP, Javascript/CSS) isso ajuda a prover largura de banda;
  • TCPKeepAlive yes: faz a conexão SSH manter o tcp-ping para garantir que a conexão não seja descartada pelo NAT/CGNAT;
  • ClientAliveInterval 3: ativa o keep-alive do protocolo SSH, a cada 3 segundos;
  • ClientAliveCountMax 15: reinicia a conexão SSH se 15 tentativas de keep-alive SSH forem perdidas;

Conferir se o servidor está com as configurações corretas:

Servidor – Bash
sshd -T | egrep -i '(tunnel|compress|alive)';
    # clientaliveinterval 3
    # clientalivecountmax 15
    # tcpkeepalive yes
    # compression no
    # permittunnel yes

O parâmetro PermitTunnel do servidor SSH pode ser ajustados nas seguintes opções:

  • PermitTunnel:
    • no: impede que o servidor crie túneis a pedido do cliente, valor padrão;
    • yes: o servidor poderá criar túneis TAP e TUN;
    • ethernet: o servidor poderá criar somente túneis TAP (L2 Ethernet);
    • point-to-point: o servidor poderá criar somente túneis TUN (L3 IP);

O MTU é irrelevante pois a conexão é puramente TCP e cifrada. Mesmo que você calcule um MTU baixo o pacote pode acabar ficando maior que o MSS por conta dos blocos gerados pela criptografia do SSH. Um pacote ou quadro se tornarão vários segmentos TCP fim-a-fim. MTU padrão 1500 bytes.

8.5.2 – Criando túnel VPN no cliente

É importante combinar o túnel VPN com a confiança SSH, dessa forma você poderá tornar o túnel em um serviço no SystemD que rode persistente e auto-reparador.

Com o ambiente servidor preparado, precisamos criar o serviço do túnel nos dois lados (cliente e servidor):

Cliente – Bash
# Criar unit do SystemD:
(
    echo '[Unit]';
    echo 'Description=SSH TUN Tunnel 08';
    echo 'After=network.target';
    echo;
    echo '[Service]';
    echo 'Type=simple';
    echo 'ExecStart=/etc/network/ssh-tun8-connection.sh';
    echo 'Restart=always';
    echo 'RestartSec=3';
    echo;
    echo '[Install]';
    echo 'WantedBy=multi-user.target';
    echo;
) > /etc/systemd/system/ssh-tun8.service;

# Recarregar configuração do SystemD:
systemctl daemon-reload;
systemctl enable ssh-tun8;

O script /etc/network/ssh-tun8-connection.sh precisa ser criado no lado cliente para que ele levante a interface de rede e solicite ao servidor a criação da VPN:

Cliente – Bash – /etc/network/ssh-tun8-connection.sh
#!/bin/sh

# Subir conexão SSH do cliente para o servidor e solicitar o túnel
ssh -N \
    -o Tunnel=point-to-point \
    -o LocalCommand=/etc/network/tun8-setup.sh \
    -o PermitLocalCommand=yes \
    -w 8:8 \
    -p 22 \
    root@45.255.128.2;

exit 0;

Tornar executável o script de conexão no cliente:

Cliente – Bash
chmod +x /etc/network/ssh-tun8-connection.sh;

Para configurar a interface de rede as duas pontas para fazer setup dos IPs (IPv4 e IPv6) no túnel (tun8):

Lado cliente:

Cliente – Bash – /etc/network/tun8-setup.sh
#!/bin/sh

# Interface cliente
ip link set    dev tun8 mtu 2000 txqueuelen 10000;
ip -4 addr add dev tun8 10.255.8.2/30;
ip -6 addr add dev tun8 2001:db8:10:255:8::2/126;
ip link set up dev tun8;

exit 0;

Tornar executável o script de setup da interface no cliente:

Cliente – Bash
chmod +x /etc/network/tun8-setup.sh;
8.5.3 – Criando túnel VPN no servidor

Crie o script de setup da interface no lado servidor:

Servidor – /etc/network/tun8-setup.sh
#!/bin/sh

# Interface servidor
ip link set    dev tun8 mtu 2000 txqueuelen 10000;
ip -4 addr add dev tun8 10.255.8.1/30;
ip -6 addr add dev tun8 2001:db8:10:255:8::1/126;
ip link set up dev tun8;

exit 0;

Torne-o executável:

Servidor – Bash
chmod +x /etc/network/tun8-setup.sh;

Criar interface hotplug para se auto-configurar sempre que for detectada:

Servidor – Bash
(
    echo;
    echo '# VPN SSH Tunnel 8 - Servidor';
    echo 'allow-hotplug tun8';
    echo 'iface tun8 inet static';
    echo '    address 10.255.8.1/30';
    echo '    mtu 9000';
    echo '    pre-up /etc/network/tun8-setup.sh';
    echo;
) > /etc/network/interfaces.d/tun8;

Quando o cliente se conectar o servidor SSH irá criar a interface tun8 (desativada). O hotplug (udev) irá detectar o surgimento da interface tun8 e acionar o Network-Manager, que executará o ifup automaticamente.

8.5.4 – Mudando túnel para tipo TAP/Ethernet

No exemplo anterior criamos um túnel tipo TUN, que transporte pacotes IP. Para convertê-lo para tipo TAP, basta alterar o comando no cliente, mudando “point-to-point” para “ethernet“, exemplo:

Cliente – /etc/network/ssh-tun8-connection.sh
#!/bin/sh

# Subir conexão SSH do cliente para o servidor e solicitar o túnel
ssh -N \
    -o Tunnel=ethernet \
    -o LocalCommand=/etc/network/tun8-setup.sh \
    -o PermitLocalCommand=yes \
    -w 8:8 \
    -p 22 \
    root@45.255.128.2;

exit 0;

9 – SSH-CA – Unidade certificadora

O SSH-CA é um recurso especial que adiciona estrutura de certificados ao ecossistema de autenticação e controle de acesso.

Com ele, a unidade certificadora (CA) assina chaves públicas usando sua chave privada, criando certificados assinados.

A chave pública da CA pode ser usada em toda a infra pelos servidores SSH para conferir se o certificado do usuário é válido.

Problemas que o SSH-CA resolve:

  • Administradores podem, normalmente, criar chaves livremente, adicionando confiança de chaves em toda a infra, potencializando as falhas de acesso e permitindo controle indiscriminado a recursos;
  • Ao confiar em chaves públicas não é possível restringir recursos sem ter que definir manualmente as instruções no authorized_keys – muito trabalho manual;
  • Para controlar IP de origem, horário de acesso, tipos de canais que podem ser utilizados, validade da chave pública, etc… é necessário criar scripts complexos;

O SSH-CA resolve todos os problemas acima com mais elegância, centralizando na CA o poder de colocar atributos do certificado, limitando os poderes de acesso dos usuários com granularidade.

Fluxo normal: usuário gera sua chave privada, envia a respectiva chave pública para a CA (SSH-CA), que irá inserir atributos e assinar digitalmente. O Certificado SSH gerado é devolvido ao usuário.

9.1 – Criando uma SSH-CA

O processo de criação da chave privada da CA é igual a qualquer outra chave:

Servidor/CA – Bash
# Criar pasta para arquivos da CA:
mkdir -p /etc/ssh/ca-blackrock/;

# Entrar na pasta da CA:
cd       /etc/ssh/ca-blackrock/;

# Gerar chave privada da CA 
[ -f ca_masterkey  ] || \
    ssh-keygen -t ed25519 -N "" -C "BlackRock-SSH-CA-KEY" -f ca_masterkey;

# Arquivo com a chave privada da CA: /etc/ssh/ca-blackrock/ca_masterkey
# Arquivo com a chave publica da CA: /etc/ssh/ca-blackrock/ca_masterkey.pub

# Extrair informações (opcional):
ssh-keygen -l -f ca_masterkey -E sha256 > ca_masterkey.sha256; # Fingerprint SHA256
ssh-keygen -l -f ca_masterkey -E md5    > ca_masterkey.md5;    # Fingerprint MD5

9.2 – Criando certificados dos usuários

O ideal é que o usuário nos envie sua chave pública para geração do certificado. Vou criar a chave privada do usuário no servidor para fins didáticos e para você praticar o conceito mais rápido.

Criar chave privada do usuário (chave pública gerada automaticamente no arquivo .pub):

Servidor/CA – Bash
# Criar pasta para arquivos dos usuários da CA:
mkdir -p /etc/ssh/ca-blackrock/users/;

# Entra na pasta de arquivos dos usuários da CA:
cd  /etc/ssh/ca-blackrock/users/;

# Gerar chave RSA do cliente 1 (user001) - chave publica em user001.pub
[ -f user001  ] || \
    ssh-keygen -t ed25519 -N "" -C "BLACKROCK-USER:user001" -f user001;

Criar certificado usando chave pública do usuário:

Servidor/CA – Bash
# Entra na pasta de arquivos dos usuários da CA:
cd  /etc/ssh/ca-blackrock/users/;

# Gerar certificado válido por 10 min:
ssh-keygen \
    -s /etc/ssh/ca-blackrock/ca_masterkey \
    -I "user001@intranet.br" \
    -n "user001" \
    -V +300s \
    user001.pub;
        # Signed user key user001-cert.pub:
        #   id "user001@intranet.br" serial 0 for user001
        #   valid
        #      from  2025-12-19T11:28:00
        #      to    2025-12-19T11:34:24

# Arquivo do certificado gerado: user001-cert.pub
# Caminho completo.............: /etc/ssh/ca-blackrock/users/user001-cert.pub
#
# Conteudo:
#    ssh-ed25519-cert-v01@openssh.com AAAAIHNz...6OEgk= BLACKROCK-USER:user001

No exemplo acima, o arquivo “user001-cert.pub” é o certificado pronto que deve ser enviado ao usuário.

Note que criamos um limite de validade para o certificado do usuário “valid from … to …“. Esse limite está no certificado e não pode ser editado (mudaria o hash dos atributos para um hash que não confere com o hash assinado pela CA).

Como usamos “-V +300S“, o timestamp inicial é coletado para o “from” e acrescido de 300 segundos para gerar o timestamp “to”.

Você tambem pode especificar limites discretos assim:

  • -V 20260114300000:20260823590000

Exibindo detalhes do certificado:

Servidor/CA – Bash
# Exibir detalhes do certificado:
ssh-keygen -L -f /etc/ssh/ca-blackrock/users/user001-cert.pub;

#  Type: ssh-ed25519-cert-v01@openssh.com user certificate
#  Public key: ED25519-CERT SHA256:8OGQvEr0..7nGzjWUwAMB4AMdFILEYNLy2I
#  Signing CA: ED25519 SHA256:kLM8BO8PKra..zAn08mTMQ03kkRCw (using ssh-ed25519)
#  Key ID: "user001@intranet.br"
#  Serial: 0
#  Valid: from 2025-12-19T11:28:00 to 2025-12-19T11:34:24
#  Principals: 
#          user001
#  Critical Options: (none)
#  Extensions: 
#          permit-X11-forwarding
#          permit-agent-forwarding
#          permit-port-forwarding
#          permit-pty
#          permit-user-rc

Propriedades do certificado:

  • Type: tipo do certificado, algoritmo assimétrico (ed25519 no caso);
  • Public key: chave pública do usuário;
  • Signing CA: assinatura digital realizada sobre o HASH dos atributos;
  • Key ID: identificador de usuário dono da chave (login único na organização);
  • Serial: número de série do certificado, padrão 0 (zero);
  • Valid: faixa de data/hora/segundos em que o certificado é considerado válido para uso, fora dessa faixa o acesso ao recurso é negado;
  • Principals: identificador  de uma entidade de origem autenticável (semelhante a um login), pode ser um usuário, um serviço ou um host. Vários principals podem ser adicionados a um certificado, exemplo: “user001, unit-it, svc-backup”:
    • user001: identificador de usuário;
    • unit-ti: identificador de departamento;
    • svc-backup: identificador de serviço suportado;
  • Critical Options: opções críticas são atributos que limitam o uso baseado em informações externas ao protocolo SSH, como IP de origem, variável de ambiente, etc… nem todas as opções são suportadas pelo OpenSSH;
  • Extensions: define quais tipos de canais o certificado pode abrir em um servidor SSH;

Criar chave e certificado do usuário “user002” com todos os detalhes possíveis:

Servidor/CA – Bash
# Entra na pasta de arquivos dos usuários da CA:
cd  /etc/ssh/ca-blackrock/users/;

# Gerar chave RSA do cliente 2 (user002) - chave publica em user002.pub
[ -f user002  ] || \
    ssh-keygen -t ed25519 -N "" -C "BLACKROCK-USER:user002" -f user002;


# Gerar certificado válido por 10 min:
ssh-keygen \
    -s /etc/ssh/ca-blackrock/ca_masterkey \
    \
    -I "user002@intranet.br" \
    \
    -n "user002,unit-ti,group-managers,svc-backup,svc-firewall" \
    \
    -z 2025122501 \
    \
    -V +365d \
    \
    -O clear \
    -O permit-port-forwarding \
    -O source-address="192.168.1.0/24,45.255.130.91" \
    -O permit-pty \
    -O force-command="echo 'Ola mundo';" \
    -O critical:remote-bot-api-key="ak-28xnant-x99e23" \
    -O extension:remote-procedure="send-report,on-time-pwd" \
    \
    user002.pub;
        # Signed user key user002-cert.pub:
        #    id "user002@intranet.br"
        #   serial 2025122501
        #   for user002,unit-ti,group-managers,svc-backup,svc-firewall
        #   valid
        #      from 2025-12-19T11:57:00
        #      to 2026-12-19T11:58:32

# Arquivo do certificado gerado: user002-cert.pub
# Caminho completo.............: /etc/ssh/ca-blackrock/users/user002-cert.pub
#
# Conteudo:
#    ssh-ed25519-cert-v01@openssh.com AAAAI...SEwAw== BLACKROCK-USER:user002

# Exibir detalhes do certificado:
ssh-keygen -L -f /etc/ssh/ca-blackrock/users/user002-cert.pub;
#   Type: ssh-ed25519-cert-v01@openssh.com user certificate
#   Public key: ED25519-CERT SHA256:eKrpUYmgsbH4Lu...voLuXNFEybo9boUP4p26M
#   Signing CA: ED25519 SHA256:kLM8BO8PKr...n08mTMQ03kkRCw (using ssh-ed25519)
#   Key ID: "user002@intranet.br"
#   Serial: 2025122501
#   Valid: from 2025-12-19T12:01:00 to 2026-12-19T12:02:04
#   Principals: 
#      user002
#      unit-ti
#      group-managers
#      svc-backup
#      svc-firewall
#  Critical Options: 
#      force-command echo 'Ola mundo';
#      remote-bot-api-key UNKNOWN OPTION: 00000011616...783939653233 (len 21)
#      source-address 192.168.1.0/24,45.255.130.91
#  Extensions: 
#      permit-port-forwarding
#      permit-pty
#      remote-procedure UNKNOWN OPTION: 000000177365...96d652d707764 (len 27)

Detalhe: o certificado acima não é válido no OpenSSH por conta do atributo “critical:remote-bot-api-key“.

Criar chave e certificado do usuário “user003” para testes práticos:

Servidor/CA – Bash
# Criar certificado do user003
cd  /etc/ssh/ca-blackrock/users/;

# Gerar chave:
[ -f user003  ] || \
    ssh-keygen -t ed25519 -N "" -C "BLACKROCK-USER:user003" -f user003;

# Gerar certificado:
ssh-keygen \
    -s /etc/ssh/ca-blackrock/ca_masterkey \
    \
    -I "user003@intranet.br" \
    \
    -n "user003,unit-ti,group-managers" \
    \
    -z 2025122502 \
    \
    -V 20240101000000:20391231235959 \
    \
    -O clear \
    -O permit-port-forwarding \
    -O permit-pty \
    -O force-command="echo 'Ola Usuario 003';" \
    -O extension:remote-procedure="send-report,on-time-pwd" \
    \
    user003.pub;
        # Signed user key user003-cert.pub ...

O certificado acima força a execução do comando “echo ‘Ola Usuario 003’” no servidor e encerra a sessão!

9.3 – Configurando servidor SSH para validação de certificados

Os pre-requisitos foram cumpridos:

  • Unidade certificadora criada;
  • Usuários certificados;

A chave pública da CA “/etc/ssh/ca-blackrock/ca_masterkey.pub” é necessária em toda a infraestrutura pois ela confere a assinatura dos certificados apresentados aos servidores SSH.

Vamos copiá-las para o caminho /etc/ssh/ca.pub em todos os servidores SSH.

Criando configuração que vincula o servidor SSH na CA:

Servidor – Bash
# Criar o diretório de configuração (se não existir):
mkdir -p /etc/ssh/sshd_config.d/;

# Criar o arquivo de configuração da CA:
(
    echo;
    echo '# SSH-CA BlackRock - Autenticação por Certificado';
    echo '# Chave publica da CA que assina os certificados dos usuarios';
    echo 'TrustedUserCAKeys /etc/ssh/ca.pub';
    echo;
    echo '# Diretório com principals autorizados por usuario';
    echo 'AuthorizedPrincipalsFile /etc/ssh/principals/%u';
    echo;
    echo '# Arquivo de revogação de chaves/certificados';
    echo 'RevokedKeys /etc/ssh/ca-revoked-keys.dat';
    echo;
) > /etc/ssh/sshd_config.d/ssh-ca.conf;

# Criar arquivo para receber certificados revogados:
touch /etc/ssh/ca-revoked-keys.dat;

Testar configuração e reiniciar o servidor SSH:

Servidor – Bash
# Testar configuracao:
sshd -t -f /etc/ssh/sshd_config && { echo; echo CONFIG SSHD OK; echo; }

# Reiniciar servidor ssh para aplicar:
service ssh restart;

Detalhe importante:

  • O servidor SSH continua confiando em chaves públicas comuns;
  • Ele passa a aceitar certificados e conferir seus atributos;
  • A implementação de principals deve ser feito em arquivos na pasta /etc/ssh/principals/, onde cada arquivo será o nome do principal e suas configurações reativas;

O usuário “user002” tem principals limitados a “user002,unit-ti,group-managers,svc-backup,svc-firewall“, logo, se esse usuário tentar logar com o usuário “root” o servidor irá negar o acesso.

O usuário pode usar o certificado para entrar no servidor somente com usuários que conferem com os principals do certificado.

Podemos expandir isso no servidor, dando ao Principal “group-manager” poderes para logar como root:

Servidor – Bash
# Criar diretório para principals:
mkdir -p /etc/ssh/principals;

# Criar arquivo para o usuário root com principals autorizados a logar como root:
(
    echo 'group-superusers';
    echo 'group-managers';
) > /etc/ssh/principals/root;

# Ajustar permissões do arquivo para impedir edição:
chown root:root /etc/ssh/principals/root;
chmod       644 /etc/ssh/principals/root;

Continuando…

Entregue o certificado (e a chave privada, se você a gerou) para o usuário, testando certificado no usuário:

Cliente – Bash
# Ajustar permissoes dos arquivos
chmod 600 user003;             # restringir chave privada
chmod 600 user-003-cert.pub;   # restringir certificado

# Comando para usar o certificado
# -i user003 = informa a chave privada

ssh -i user003 -p 22 root@vps99.meu-dominio.com;
    # Ola Usuario 003
    # Connection to debv.tmsoft.com.br closed.

Se você praticou tudo, você é o novo mestre do SSH!

“Eu sei o que é perder, ter a absoluta certeza de que está certo, mas falhar da mesma forma. É assustador, de tremer as pernas. Mas eu pergunto, pra quê? Fuja disso, tema isso, o destino de todos sempre chega. E agora, o de vocês chegou. Ou melhor, eu cheguei.“
Autor: Thanos

Terminamos por hoje!

Patrick Brandão, patrickbrandao@gmail.com