OpenSSH

Contents
The SSH Protocol
Why Use SSH?
Main Features
Protocol Versions
Event Sequence of an SSH Connection
Configuring OpenSSH
Configuration Files
Starting an OpenSSH Server
Requiring SSH for Remote Connections
Using Key-based Authentication
Using OpenSSH Certificate Authentication
Introduction to SSH Certificates
Support for SSH Certificates
Creating SSH CA Certificate Signing Keys
Distributing and Trusting SSH CA Public Keys
Creating SSH Certificates
Signing an SSH Certificate Using a PKCS#11 Token
Viewing an SSH CA Certificate
Revoking an SSH CA Certificate
OpenSSH Clients
Using the ssh Utility
Using the scp Utility
Using the sftp Utility
More Than a Secure Shell
X11 Forwarding
Port Forwarding
Additional Resources

SSH (Secure Shell) é um protocolo que facilita comunicações seguras entre

dois sistemas usando uma arquitetura cliente-servidor e permite que os
usuários façam login em sistemas host de servidor remotamente. Ao contrário
de outros protocolos de comunicação remota, como FTP , Telnet ou rlogin , o
SSH criptografa a sessão de login, dificultando a conexão para que invasores
coletem senhas não criptografadas.

O programa ssh foi projetado para substituir aplicativos de terminal mais

antigos e menos seguros usados ​para efetuar login em hosts remotos,
como telnet ou rsh . Um programa relacionado chamado scp substitui
programas mais antigos projetados para copiar arquivos entre hosts, como
o rcp . Como esses aplicativos mais antigos não criptografam as senhas
transmitidas entre o cliente e o servidor, evite-os sempre que possível. Usar
métodos seguros para fazer login em sistemas remotos diminui os riscos
tanto para o sistema cliente quanto para o host remoto.

O Fedora inclui o pacote OpenSSH geral, openssh , bem como os pacotes

OpenSSH server, openssh-server e client, openssh-clients . Observe que
os pacotes OpenSSH requerem o pacote OpenSSL openssl-libs , que instala
várias bibliotecas criptográficas importantes, permitindo que o OpenSSH
forneça comunicações criptografadas.

O protocolo SSH
Por que usar SSH?
Os possíveis invasores têm à sua disposição uma variedade de ferramentas
que lhes permitem interromper, interceptar e redirecionar o tráfego de rede
em um esforço para obter acesso a um sistema. Em termos gerais, essas
ameaças podem ser categorizadas da seguinte forma:

Interceptação de comunicação entre dois sistemas

O invasor pode estar em algum lugar da rede entre as partes em
comunicação, copiando qualquer informação passada entre elas. Ele pode
interceptar e manter as informações ou alterá-las e enviá-las ao
destinatário pretendido.

Esse ataque geralmente é realizado usando um sniffer de pacotes , um

utilitário de rede bastante comum que captura cada pacote que flui pela
rede e analisa seu conteúdo.
Representação de um host específico
O sistema do invasor é configurado para se passar por destinatário
pretendido de uma transmissão. Se esta estratégia funcionar, o sistema do
usuário permanece inconsciente de que está se comunicando com o host
errado.

Este ataque pode ser realizado usando uma técnica conhecida

como envenenamento de DNS ou por meio do chamado spoofing de IP . No
primeiro caso, o invasor usa um servidor DNS crackeado para apontar os
sistemas clientes para um host duplicado maliciosamente. No segundo
caso, o intruso envia pacotes de rede falsificados que parecem ser de um
host confiável.

Ambas as técnicas interceptam informações potencialmente sensíveis e, se a

interceptação for feita por motivos hostis, os resultados podem ser
desastrosos. Se o SSH for usado para login remoto no shell e cópia de
arquivos, essas ameaças à segurança poderão ser bastante reduzidas. Isso
ocorre porque o cliente e o servidor SSH usam assinaturas digitais para
verificar sua identidade. Além disso, toda a comunicação entre os sistemas
cliente e servidor é criptografada. As tentativas de falsificar a identidade de
qualquer um dos lados de uma comunicação não funcionam, pois cada
pacote é criptografado usando uma chave conhecida apenas pelos sistemas
locais e remotos.

Principais características
O protocolo SSH fornece as seguintes salvaguardas:

Ninguém pode se passar por servidor pretendido

Após uma conexão inicial, o cliente pode verificar se está se conectando
ao mesmo servidor ao qual se conectou anteriormente.
Ninguém pode capturar as informações de autenticação
O cliente transmite suas informações de autenticação ao servidor usando
criptografia forte.
Ninguém pode interceptar a comunicação
Todos os dados enviados e recebidos durante uma sessão são
transferidos usando criptografia forte, tornando as transmissões
interceptadas extremamente difíceis de descriptografar e ler.

Além disso, também oferece as seguintes opções:

Ele fornece meios seguros para usar aplicativos gráficos em uma

rede
Usando uma técnica chamada encaminhamento X11 , o cliente pode
encaminhar aplicativos X11 ( X Window System ) do servidor. Observe que
se você definir a ForwardX11Trusted opção yes ou usar SSH com a -
Y opção, você ignorará os controles de extensão X11 SECURITY, o que pode
resultar em uma ameaça à segurança.
Ele fornece uma maneira de proteger protocolos que de outra
forma seriam inseguros
O protocolo SSH criptografa tudo o que envia e recebe. Usando uma
técnica chamada encaminhamento de porta , um servidor SSH pode se
tornar um canal para proteger protocolos que de outra forma seriam
inseguros, como POP , e aumentar a segurança geral do sistema e dos
dados.
Pode ser usado para criar um canal seguro
O servidor e cliente OpenSSH podem ser configurados para criar um
túnel semelhante a uma rede privada virtual para tráfego entre máquinas
servidor e cliente.
Suporta autenticação Kerberos
Servidores e clientes OpenSSH podem ser configurados para
autenticação usando a implementação GSSAPI (Generic Security Services
Application Program Interface) do protocolo de autenticação de rede
Kerberos.

Versões do protocolo
Existem atualmente duas variedades de SSH: versão 1 e versão 2. O pacote
OpenSSH no Fedora usa SSH versão 2, que possui um algoritmo de troca de
chaves aprimorado não vulnerável à exploração conhecida na versão 1. A
versão 1 do protocolo foi removida do pacote OpenSSH e é Não mais
suportado.

Sequência de eventos de uma conexão SSH

A série de eventos a seguir ajuda a proteger a integridade da comunicação
SSH entre dois hosts.

Um handshake criptográfico é feito para que o cliente possa verificar se

está se comunicando com o servidor correto.
A camada de transporte da conexão entre o cliente e o host remoto é
criptografada usando uma cifra simétrica.
O cliente se autentica no servidor.
O cliente interage com o host remoto pela conexão criptografada.

Camada de transporte
A função principal da camada de transporte é facilitar a comunicação segura
entre os dois hosts no momento da autenticação e durante a comunicação
subsequente. A camada de transporte realiza isso manipulando a criptografia
e descriptografia de dados e fornecendo proteção de integridade aos pacotes
de dados à medida que são enviados e recebidos. A camada de transporte
também fornece compactação, agilizando a transferência de informações.

Assim que um cliente SSH entra em contato com um servidor, informações

importantes são trocadas para que os dois sistemas possam construir
corretamente a camada de transporte. As seguintes etapas ocorrem durante
essa troca:

O algoritmo de troca de chaves é determinado

O algoritmo de assinatura de chave pública é determinado
O algoritmo de criptografia simétrica é determinado
O algoritmo de autenticação de mensagem é determinado
As chaves são trocadas

Durante a troca de chaves, o servidor se identifica para o cliente com

uma chave de host exclusiva . Se o cliente nunca se comunicou com esse
servidor específico antes, a chave do host do servidor será desconhecida para
o cliente e ele não se conectará. OpenSSH notifica o usuário de que a
autenticidade do host não pode ser estabelecida e solicita que o usuário
aceite ou rejeite. Espera-se que o usuário verifique de forma independente a
nova chave de host antes de aceitá-la. Nas conexões subsequentes, a chave
do host do servidor é verificada em relação à versão salva no cliente,
proporcionando confiança de que o cliente está realmente se comunicando
com o servidor pretendido. Se, no futuro, a chave do host não corresponder
mais, o usuário deverá remover a versão salva do cliente antes que uma
conexão possa ocorrer.
 Sempre verifique a integridade de um novo servidor SSH
É possível que um invasor se disfarce de servidor SSH durante o contato
inicial, pois o sistema local não sabe a diferença entre o servidor pretendido
e um servidor falso configurado por um invasor. Para ajudar a evitar isso,
verifique a integridade de um novo servidor SSH entrando em contato com
o administrador do servidor antes de conectar-se pela primeira vez ou no
caso de incompatibilidade de chave de host.

O SSH foi projetado para funcionar com quase qualquer tipo de algoritmo de
chave pública ou formato de codificação. Depois que uma troca inicial de
chaves cria um valor hash usado para trocas e um valor secreto
compartilhado, os dois sistemas começam imediatamente a calcular novas
chaves e algoritmos para proteger a autenticação e os dados futuros
enviados pela conexão.

Após uma certa quantidade de dados ter sido transmitida usando uma
determinada chave e algoritmo (a quantidade exata depende da
implementação do SSH, do algoritmo de criptografia e da configuração),
ocorre outra troca de chaves, gerando outro conjunto de valores de hash e
um novo valor secreto compartilhado. Mesmo que um invasor consiga
determinar o valor do hash e do segredo compartilhado, essas informações
serão úteis apenas por um período limitado de tempo.

Autenticação
Uma vez que a camada de transporte tenha construído um túnel seguro para
passar informações entre os dois sistemas, o servidor informa ao cliente os
diferentes métodos de autenticação suportados, como o uso de uma
assinatura codificada por chave privada ou a digitação de uma senha. O
cliente então tenta se autenticar no servidor usando um destes métodos
suportados.

Servidores e clientes SSH podem ser configurados para permitir diferentes

tipos de autenticação, o que dá a cada lado a quantidade ideal de controle. O
servidor pode decidir quais métodos de criptografia ele suporta com base em
seu modelo de segurança, e o cliente pode escolher a ordem dos métodos de
autenticação a serem tentados dentre as opções disponíveis.

Canais
Após uma autenticação bem-sucedida na camada de transporte SSH, vários
canais são abertos por meio de uma técnica
chamada multiplexação [ 1 ] . Cada um desses canais lida com a comunicação
para diferentes sessões de terminal e para sessões X11 encaminhadas.

Tanto clientes quanto servidores podem criar um novo canal. Cada canal
recebe então um número diferente em cada extremidade da
conexão. Quando o cliente tenta abrir um novo canal, o cliente envia o
número do canal junto com a solicitação. Essas informações são armazenadas
pelo servidor e usadas para direcionar a comunicação para esse canal. Isso é
feito para que diferentes tipos de sessões não afetem uns aos outros e para
que, quando uma determinada sessão terminar, seu canal possa ser fechado
sem interromper a conexão SSH primária.

Os canais também suportam controle de fluxo , o que lhes permite enviar e

receber dados de maneira ordenada. Dessa forma, os dados não são enviados
pelo canal até que o cliente receba uma mensagem informando que o canal
está aberto.

O cliente e o servidor negociam as características de cada canal

automaticamente, dependendo do tipo de serviço que o cliente solicita e da
forma como o usuário está conectado à rede. Isto permite grande flexibilidade
no tratamento de diferentes tipos de conexões remotas sem a necessidade
de alterar a infraestrutura básica do protocolo.

Configurando OpenSSH
Para executar as tarefas descritas nesta seção, você deve ter privilégios de
superusuário. Para obtê-los, faça login root digitando:

su-

Arquivos de configuração
Existem dois conjuntos diferentes de arquivos de configuração: aqueles para
programas clientes (ou seja, ssh , scp e sftp ) e aqueles para o servidor (o
daemon sshd ). As informações de configuração SSH de todo o sistema são
armazenadas no /etc/ssh/ diretório conforme descrito em Arquivos de
configuração de todo o sistema . As informações de configuração SSH
específicas do usuário são armazenadas no ~/.ssh/ diretório inicial do
usuário, conforme descrito em Arquivos de configuração específicos do
usuário .

Tabela 1. Arquivos de configuração de todo o sistema

Arquivo Descrição

/etc/ssh/moduli Contém grupos Diffie-Hellman usados ​para

o método de troca de chaves “Diffie-
Hellman group exchange”, que é crítico
para a construção de uma camada de
transporte segura. Quando as chaves são
trocadas no início de uma sessão SSH, é
criado um valor secreto compartilhado que
não pode ser determinado apenas por
nenhuma das partes. Caso o arquivo não
esteja disponível, serão utilizados grupos
fixos. Outros métodos de troca de chaves
não precisam deste arquivo.

/etc/ssh/ssh_config O arquivo de configuração do cliente SSH

padrão. Observe que ele é substituído
Arquivo Descrição
por ~/.ssh/config se existir.

/etc/ssh/sshd_config O arquivo de configuração do

daemon sshd .

/etc/ssh/ssh_host_ecdsa_key A chave privada ECDSA usada

pelo daemon sshd .

/etc/ssh/ssh_host_ecdsa_key.pub A chave pública ECDSA usada

pelo daemon sshd .

/etc/ssh/ssh_host_rsa_key A chave privada RSA usada pelo

daemon sshd .

/etc/ssh/ssh_host_rsa_key.pub A chave pública RSA usada pelo

daemon sshd .

/etc/ssh/ssh_host_ed25519_key A chave privada EdDSA usada pelo

daemon sshd .

/etc/ssh/ssh_host_ed25519_key.pub A chave pública EdDSA usada

pelo daemon sshd .

/etc/pam.d/sshd O arquivo de configuração PAM para

o daemon sshd .

/etc/sysconfig/sshd Arquivo de configuração do sshd serviço.

Tabela 2. Arquivos de configuração específicos do usuário

Arquivo Descrição

~/.ssh/authorized_keys Contém uma lista de chaves públicas

autorizadas para servidores. Quando o
cliente se conecta a um servidor, o servidor
autentica o cliente verificando sua chave
pública assinada armazenada neste
arquivo.

~/.ssh/id_ecdsa Contém a chave privada ECDSA do usuário.

~/.ssh/id_ecdsa.pub A chave pública ECDSA do usuário.

~/.ssh/id_rsa A chave privada RSA usada por ssh .

~/.ssh/id_rsa.pub A chave pública RSA usada por ssh .

~/.ssh/id_ed25519 A chave privada EdDSA usada por ssh .

~/.ssh/id_ed25519.pub A chave pública EdDSA usada por ssh .

~/.ssh/known_hosts Contém chaves de host de servidores SSH

acessados ​pelo usuário. Este arquivo é
muito importante para garantir que o
cliente SSH esteja se conectando ao
servidor SSH correto.

Para obter informações sobre várias diretivas que podem ser usadas nos
arquivos de configuração SSH, consulte as páginas de manual ssh_config (5)
e (5). sshd_config
Iniciando um servidor OpenSSH

Certifique-se de ter pacotes relevantes instalados

Para executar um servidor OpenSSH, você deve ter o pacote openssh-
server instalado. Veja Instalando Pacotes para mais informações sobre
como instalar novos pacotes no Fedora 38.

Para iniciar o daemon sshd na sessão atual, digite o seguinte em um prompt

do shell como root :

~]# systemctl iniciar sshd.service

Para interromper a execução do daemon sshd na sessão atual, use o seguinte

comando como root :

~]# systemctl parar sshd.service

Se você deseja que o daemon inicie automaticamente no momento da

inicialização, digite como root :

~]# systemctl ativar sshd.service

ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.targ

Veja Serviços e Daemons para mais informações sobre como configurar

serviços no Fedora.

Observe que se você reinstalar o sistema, um novo conjunto de chaves de

identificação será criado. Como resultado, os clientes que se conectaram ao
sistema com qualquer uma das ferramentas OpenSSH antes da reinstalação
verão a seguinte mensagem:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ AVISO: A IDENTIFICAÇÃO DO HOST REMOTO MUDOU! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
É POSSÍVEL QUE ALGUÉM ESTEJA FAZENDO ALGO DESAGRADÁVEL!
Alguém pode estar espionando você agora mesmo (ataque man-in-the-middle)!
Também é possível que a chave do host RSA tenha acabado de ser alterada.

Para evitar isso, você pode fazer backup dos arquivos relevantes
do /etc/ssh/ diretório (consulte Arquivos de configuração de todo o
sistema para obter uma lista completa) e restaurá-los sempre que reinstalar o
sistema.
Exigindo SSH para conexões remotas
Para que o SSH seja realmente eficaz, o uso de protocolos de conexão
inseguros deve ser proibido. Caso contrário, a senha de um usuário poderá
ser protegida usando SSH para uma sessão, apenas para ser capturada
posteriormente durante o login usando Telnet. Alguns serviços a serem
desativados incluem telnet , rsh , rlogin e vsftpd .

Esses serviços não são instalados por padrão no Fedora. Se necessário, para
garantir que esses serviços não estejam em execução, digite os seguintes
comandos em um prompt do shell:

systemctl parar telnet.service

systemctl parar rsh.service
systemctl parar rlogin.service
systemctl parar vsftpd.service

Para desabilitar a execução desses serviços na inicialização, digite:

systemctl desabilitar telnet.service

systemctl desabilitar rsh.service
systemctl desabilitar rlogin.service
systemctl desabilitar vsftpd.service

Veja Serviços e Daemons para mais informações sobre como configurar

serviços no Fedora.

Usando autenticação baseada em chave

Para melhorar ainda mais a segurança do sistema, gere pares de chaves SSH
e, em seguida, aplique a autenticação baseada em chave, desativando a
autenticação por senha. Para fazer isso, crie um arquivo de configuração
drop-in, por exemplo /etc/ssh/sshd_config.d/01-local.conf . Certifique-se de
que esteja lexicograficamente antes do 50-redhat.conf arquivo, fornecendo
os padrões do Fedora. Em um editor de texto como vi ou nano insira
a PasswordAuthentication opção da seguinte forma:

SenhaAutenticação não

Se você estiver trabalhando em um sistema diferente de uma nova instalação

padrão, verifique se PubkeyAuthentication no não foi definido em
nenhum /etc/ssh/sshd_config arquivo incluído no diretório drop-in. Se
conectado remotamente, sem usar console ou acesso fora de banda, é
aconselhável testar o processo de login baseado em chave antes de
desabilitar a autenticação por senha.

Para poder usar ssh , scp ou sftp para conectar-se ao servidor a partir de uma
máquina cliente, gere um par de chaves de autorização seguindo as etapas
abaixo. Observe que as chaves devem ser geradas para cada usuário
separadamente.

O Fedora 38 usa o Protocolo SSH 2 e chaves RSA por padrão (veja Versões do
Protocolo para mais informações).

Não gere pares de chaves como root

Se você concluir as etapas conforme root , somente root poderá usar as
chaves.

Faça backup do seu diretório ~/.ssh/

Se você reinstalar o sistema e quiser manter os pares de chaves gerados
anteriormente, faça backup do ~/.ssh/ diretório. Após reinstalar, copie-o de
volta para seu diretório inicial. Este processo pode ser feito para todos os
usuários do seu sistema, incluindo root .

Gerando Pares de Chaves

Para gerar um par de chaves RSA para a versão 2 do protocolo SSH, siga
estas etapas:

Gere um par de chaves RSA digitando o seguinte em um prompt do shell:

~]$ ssh-keygen -t rsa

Gerando par de chaves RSA pública/privada.
Insira o arquivo no qual deseja salvar a chave (/home/USER/.ssh/id_rsa):

Pressione Enter para confirmar o local padrão, ~/.ssh/id_rsa , para a

chave recém-criada.
Digite uma senha e confirme-a digitando-a novamente quando
solicitado. Por motivos de segurança, evite usar a mesma senha que você
usa para fazer login na sua conta.

Depois disso, você receberá uma mensagem semelhante a esta:

Sua identificação foi salva em /home/USER/.ssh/id_rsa.

Sua chave pública foi salva em /home/USER/.ssh/id_rsa.pub.
A impressão digital principal é:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 USER@penguin.example.com
A imagem aleatória da chave é:
+--[RSA 2048]----+
| E. |
| . . |
| ó. |
 | . .|
| S. . |
| + oh ..|
| * * +oo|
| O +..=|
| o* o.|
+-----------------+

Por padrão, as permissões do ~/.ssh/ diretório são definidas rwx------

ou 700 expressas em notação octal. Isto é para garantir que apenas
o USUÁRIO possa visualizar o conteúdo. Se necessário, isso pode ser
confirmado com o seguinte comando:

~]$ ls -ld ~/.ssh

drwx------. 2 USUÁRIO USUÁRIO 54 25 de novembro 16:56 /home/USER/.ssh/

Para copiar a chave pública para uma máquina remota, emita um

comando no seguinte formato:

ssh-copy-id usuário@nome do host

Isto copiará a ~/.ssh/id*.pub chave pública modificada mais

recentemente se ainda não estiver instalada. Alternativamente,
especifique o nome do arquivo da chave pública da seguinte forma:

ssh-copy-id -i ~/.ssh/id_rsa.pub usuário@nome do host

Isso copiará o conteúdo

para ~/.ssh/id_rsa.pub o ~/.ssh/authorized_keys arquivo na máquina à
qual você deseja se conectar. Se o arquivo já existir, as chaves serão
anexadas ao seu final.

Para gerar um par de chaves ECDSA para a versão 2 do protocolo SSH, siga
estas etapas:

Gere um par de chaves ECDSA digitando o seguinte em um prompt de

shell:

~]$ ssh-keygen -t ecdsa

Gerando par de chaves ecdsa pública/privada.
Insira o arquivo no qual deseja salvar a chave (/home/USER/.ssh/id_ecdsa):

Pressione Enter para confirmar o local padrão, ~/.ssh/id_ecdsa , para a

chave recém-criada.
Digite uma senha e confirme-a digitando-a novamente quando
solicitado. Por motivos de segurança, evite usar a mesma senha que você
usa para fazer login na sua conta.

Depois disso, você receberá uma mensagem semelhante a esta:

Sua identificação foi salva em /home/USER/.ssh/id_ecdsa.

Sua chave pública foi salva em /home/USER/.ssh/id_ecdsa.pub.
A impressão digital principal é:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 USER@penguin.example.com
A imagem aleatória da chave é:
+--[ECDSA 256]---+
| .+ +o |
| . =.o |
| oh + ..|
| + + o +|
| Então, oE.|
| +oo+.|
| +o |
| |
| |
+-----------------+

Por padrão, as permissões do ~/.ssh/ diretório são definidas rwx------

ou 700 expressas em notação octal. Isto é para garantir que apenas
o USUÁRIO possa visualizar o conteúdo. Se necessário, isso pode ser
confirmado com o seguinte comando:

~]$ ls -ld ~/.ssh

~]$ ls -ld ~/.ssh/
drx------. 2 USUÁRIO USUÁRIO 54 25 de novembro 16:56 /home/USER/.ssh/

Para copiar a chave pública para uma máquina remota, emita um

comando no seguinte formato:

ssh-copy-id USUÁRIO@nome do host

Isto copiará a ~/.ssh/id*.pub chave pública modificada mais

recentemente se ainda não estiver instalada. Alternativamente,
especifique o nome do arquivo da chave pública da seguinte forma:

ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname

Isso copiará o
conteúdo ~/.ssh/id_ecdsa.pub na ~/.ssh/authorized_keys máquina à qual
você deseja se conectar. Se o arquivo já existir, as chaves serão anexadas
ao seu final.
Consulte Configurando o ssh-agent para obter informações sobre como
configurar seu sistema para lembrar a senha.

Nunca compartilhe sua chave privada

A chave privada é apenas para seu uso pessoal e é importante que você
nunca a forneça a ninguém.

Configurando o agente ssh

Para armazenar sua senha de forma que você não precise digitá-la sempre
que iniciar uma conexão com uma máquina remota, você pode usar o agente
de autenticação ssh-agent .

Para salvar sua senha para um determinado prompt do shell, use o seguinte
comando:

~]$ ssh-adicionar
Digite a senha para /home/USER/.ssh/id_rsa:

Observe que quando você sair, sua senha será esquecida. Você deve
executar o comando sempre que fizer login em um console virtual ou janela
de terminal.

Usando autenticação de
certificado OpenSSH
Introdução aos certificados SSH
O uso da criptografia de chave pública para autenticação requer a cópia da
chave pública de cada cliente para cada servidor no qual o cliente pretende
fazer login. Este sistema não é bem dimensionável e pode ser um fardo
administrativo. Usar uma chave pública de uma autoridade de
certificação ( CA ) para autenticar certificados de cliente elimina a
necessidade de copiar chaves entre vários sistemas. Embora o sistema de
certificado de infraestrutura de chave pública X.509 forneça uma solução
para esse problema, há um processo de envio e validação, com taxas
associadas, para obter um certificado assinado. Como alternativa, o OpenSSH
suporta a criação de certificados simples e infraestrutura de CA associada.

Os certificados OpenSSH contêm uma chave pública, informações de

identidade e restrições de validade. Eles são assinados com uma chave
pública SSH padrão usando o utilitário ssh-keygen . O formato do certificado
está descrito em . /usr/share/doc/openssh-version/PROTOCOL.certkeys
O utilitário ssh-keygen oferece suporte a dois tipos de certificados: usuário e
host. Os certificados de usuário autenticam os usuários nos servidores,
enquanto os certificados de host autenticam os hosts do servidor para os
usuários. Para que os certificados sejam usados ​para autenticação de usuário
ou host, sshd eles devem ser configurados para confiar na chave pública da
CA.

Suporte para certificados SSH

O suporte para autenticação de certificados de usuários e hosts usando o
novo formato de certificado OpenSSH foi introduzido no Fedora 13,
no pacote openssh-5.4p1-1.fc13 . Se necessário, para garantir que o
pacote OpenSSH mais recente esteja instalado, digite o seguinte comando
como root :

~]#dnf instalar openssh

A última verificação de expiração de metadados foi realizada às 0:58:01 atrás, no
O pacote openssh-7.1p1-1.fc23.x86_64 já está instalado, ignorando.

Criando chaves de assinatura de certificado SSH CA

São necessários dois tipos de certificados: certificados de host e certificados
de usuário. É considerado melhor ter duas chaves separadas para assinar os
dois certificados, por exemplo ca_user_key e ca_host_key , porém é possível
usar apenas uma chave CA para assinar ambos os certificados. Também é
mais fácil seguir os procedimentos se forem usadas chaves separadas,
portanto os exemplos a seguir usarão chaves separadas.

O formato básico do comando para assinar a chave pública do usuário para

criar um certificado de usuário é o seguinte:

ssh-keygen -s ca_user_key -I certificado_ID id_rsa.pub

Onde -s indica a chave privada usada para assinar o certificado, -I indica

uma string de identidade, o Certificate_ID , que pode ser qualquer valor
alfanumérico. Ele é armazenado como uma string terminada em zero no
certificado. O certificado_ID é registrado sempre que o certificado é usado
para identificação e também é usado ao revogar um certificado. Ter um valor
longo dificultaria a leitura dos logs, portanto, usar o nome do host para
certificados de host e o nome de usuário para certificados de usuário é uma
escolha segura.

Para assinar a chave pública de um host para criar um certificado de host,

adicione a -h opção:

ssh-keygen -s ca_host_key -I certificado_ID -h ssh_host_rsa_key.pub

As chaves do host são geradas no sistema por padrão. Para listar as chaves,
insira um comando como segue:

~]#ls -l /etc/ssh/ssh_host*
-r-------. 1 raiz raiz 668 9 de julho de 2014 /etc/ssh/ssh_host_dsa_key
-rw-r--r--. 1 raiz raiz 590 9 de julho de 2014 /etc/ssh/ssh_host_dsa_key.pub
-r-------. 1 raiz raiz 963 9 de julho de 2014 /etc/ssh/ssh_host_key
-rw-r--r--. 1 raiz raiz 627 9 de julho de 2014 /etc/ssh/ssh_host_key.pub
-r-------. 1 raiz raiz 1671 9 de julho de 2014 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 raiz raiz 382 9 de julho de 2014 /etc/ssh/ssh_host_rsa_key.pub

Recomenda-se criar e armazenar chaves CA em um local seguro, assim

como qualquer outra chave privada. Nestes exemplos o root usuário será
usado. Em um ambiente de produção real, é recomendado usar um
computador off-line com uma conta de usuário administrativo. Para obter
orientação sobre comprimentos de chave, consulte a publicação especial
NIST 800-131A Revisão 1 .

Gerando chaves de assinatura de certificado SSH CA

No servidor designado como CA, gere duas chaves para uso na assinatura
de certificados. Estas são as chaves nas quais todos os outros hosts
precisam confiar. Escolha nomes adequados, por
exemplo ca_user_key e ca_host_key . Para gerar a chave de assinatura do
certificado do usuário, digite o seguinte comando como root :

~]# ssh-keygen -t rsa -f ~/.ssh/ca_user_key

Gerando par de chaves RSA pública/privada.
Diretório criado '/root/.ssh'.
Digite a senha (vazia se não houver senha):
Digite a mesma senha novamente:
Sua identificação foi salva em /root/.ssh/ca_user_key.
Sua chave pública foi salva em /root/.ssh/ca_user_key.pub.
A impressão digital principal é:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com
A imagem aleatória da chave é:
+--[RSA 2048]----+
| .+. o|
| . o +.|
| ó + . . o|
| ó + . . ..|
| S. ... *|
| . . . .*.|
| = E.. |
| . ó. |
 | . |
+-----------------+

Gere uma chave de assinatura de certificado de host, ca_host_key , da

seguinte forma:

~]# ssh-keygen -t rsa -f ~/.ssh/ca_host_key

Gerando par de chaves RSA pública/privada.
Digite a senha (vazia se não houver senha):
Digite a mesma senha novamente:
Sua identificação foi salva em /root/.ssh/ca_host_key.
Sua chave pública foi salva em /root/.ssh/ca_host_key.pub.
A impressão digital principal é:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com
A imagem aleatória da chave é:
+--[RSA 2048]----+
| .. |
| . ....|
| . . o +oo|
| ó. o *o|
| S=.|
| ó. .|
| *.E. |
| +o= |
| .oo. |
+-----------------+

Se necessário, confirme se as permissões estão corretas:

~]#ls -la ~/.ssh

total 40
drwxrwxrwx. 2 raiz raiz 4096 22 de maio 13:18 .
dr-xr-x---. 3 raiz raiz 4096 8 de maio 08:34 ..
-r-------. 1 root root 1743 22 de maio 13:15 ca_host_key
-rw-r--r--. 1 root root 420 22 de maio 13:15 ca_host_key.pub
-r-------. 1 root root 1743 22 de maio 13:14 ca_user_key
-rw-r--r--. 1 root root 420 22 de maio 13:14 ca_user_key.pub
-rw-r--r--. 1 root root 854 8 de maio 05:55known_hosts
-r--------. 1 raiz raiz 1671 6 de maio 17:13 ssh_host_rsa
-rw-r--r--. 1 root root 1370 7 de maio 14:30 ssh_host_rsa-cert.pub
-r-------. 1 root root 420 6 de maio 17:13 ssh_host_rsa.pub

Crie o próprio certificado de host do servidor CA assinando a chave

pública do host do servidor junto com uma sequência de identificação,
como o nome do host, o nome de domínio totalmente
 qualificado ( FQDN ) do servidor CA, mas sem o final . , e um período de
validade. O comando assume o seguinte formato:

ssh-keygen -s ~/.ssh/ca_host_key -I certificado_ID -h -n host_name.example.co

A -n opção restringe este certificado a um host específico dentro do

domínio. A -V opção é adicionar um período de validade; isso é altamente
recomendável. Quando o período de validade for de um ano e cinquenta e
duas semanas, considere a necessidade de tempo para alterar os
certificados e quaisquer períodos de férias próximos ao vencimento do
certificado.

Por exemplo:

~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com

Digite a senha:
Chave de host assinada /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" seria

Distribuindo e confiando em chaves públicas SSH CA

Os hosts que devem permitir o login autenticado por certificado dos usuários
devem ser configurados para confiar na chave pública da CA que foi usada
para assinar os certificados do usuário, a fim de autenticar os certificados do
usuário. Neste exemplo esse é o ca_user_key.pub .

Publique a ca_user_key.pub chave e faça download dela em todos os hosts

necessários para permitir o login de usuários remotos. Como alternativa,
copie a chave pública do usuário CA para todos os hosts. Em um ambiente de
produção, considere primeiro copiar a chave pública para uma conta de
administrador. O comando de cópia segura pode ser usado para copiar a
chave pública para hosts remotos. O comando tem o seguinte formato:

scp ~/.ssh/ca_user_key.pub root@ host_name .example.com:/etc/ssh/

Onde host_name é o nome do host de um servidor, é necessário para

autenticar os certificados do usuário apresentados durante o processo de
login. Certifique-se de copiar a chave pública e não a chave privada. Por
exemplo, como root :

~]# scp ~/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/

A autenticidade do host 'host_name.example.com (10.34.74.56)' não pode ser estabe
A impressão digital da chave ECDSA é SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr
Tem certeza de que deseja continuar se conectando (sim/não/[impressão digital])?
Aviso: adicionado permanentemente 'host_name.example.com,10.34.74.56' (ECDSA) à l
 Senha de root@host_name.example.com:
ca_user_key.pub 100% 420 0,4 KB/s 00:00

Para autenticação de usuário remoto, as chaves CA podem ser marcadas

como confiáveis ​por usuário no ~/.ssh/authorized_keys arquivo usando a
diretiva cert-authority ou para uso global por meio da
diretiva TrustedUserCAKeys no /etc/ssh/sshd_config arquivo. Para
autenticação de host remoto, as chaves CA podem ser marcadas como
confiáveis ​globalmente no /etc/ssh/known_hosts arquivo ou por usuário
no ~/.ssh/ssh_known_hosts arquivo.

Confiando na chave de assinatura do usuário

Para certificados de usuário que possuem um ou mais princípios listados e
onde a configuração deve ter efeito global, edite
o /etc/ssh/sshd_config arquivo da seguinte forma:

TrustedUserCAKeys /etc/ssh/ca_user_key.pub

Reinicie sshd para que as alterações tenham efeito:

~]#{nbsp}systemctl reiniciar sshd.service

Para evitar receber o aviso sobre um host desconhecido, o sistema de um

usuário deve confiar na chave pública da CA que foi usada para assinar os
certificados de host. Neste exemplo é isso ca_host_key.pub .

Confiando na chave de assinatura do host

Extraia o conteúdo da chave pública usada para assinar o certificado de
host. Por exemplo, na CA:

gato ~/.ssh/ca_host_key.pub
ssh-rsa AAAAB5Wm. == root@ca-server.example.com

Para configurar sistemas clientes para confiar nos certificados de host

assinados dos servidores, adicione o conteúdo
de ca_host_key.pub no known_hosts arquivo global. Isso verificará
automaticamente o certificado anunciado pelo host do servidor em
relação à chave pública da CA para todos os usuários sempre que uma
nova máquina for conectada no domínio *.example.com . Faça login
como root e configure o /etc/ssh/ssh_known_hosts arquivo da seguinte
forma:

~]# vi /etc/ssh/ssh_known_hosts
# Uma chave CA, aceita para qualquer host em *.example.com
@cert-authority *.example.com ssh-rsa AAAAB5Wm.
 Onde está o conteúdo de . O acima configura o sistema para confiar na
chave pública do host dos servidores CA. Isto permite a autenticação
global dos certificados apresentados pelos hosts aos usuários
remotos. ssh-rsa AAAAB5Wm. ca_host_key.pub

Criando Certificados SSH

Um certificado é uma chave pública assinada. As chaves públicas do usuário
e do host devem ser copiadas para o servidor CA para assinatura pela chave
privada do servidor CA.

Copiar muitas chaves para a CA a serem assinadas pode criar confusão se

elas não tiverem nomes exclusivos. Se o nome padrão for sempre usado, a
última chave a ser copiada substituirá a chave copiada anteriormente, o que
pode ser um método aceitável para um administrador. No exemplo abaixo, o
nome padrão é usado. Em um ambiente de produção, considere usar nomes
facilmente reconhecíveis. É recomendável ter um diretório designado no
servidor CA de propriedade de um usuário administrativo para o qual as
chaves serão copiadas. Não é recomendável copiar essas chaves para o
diretório root do usuário /etc/ssh/ . Nos exemplos abaixo será usada uma
conta nomeada admin com um diretório nomeado . keys/

Crie uma conta de administrador, neste exemplo admin , e um diretório para

receber as chaves do usuário. Por exemplo:

~]$ chaves mkdir

Defina as permissões para permitir que as chaves sejam copiadas em:

~]$ chmod o+w chaves

ls -la chaves
total 8
drwxrwxrwx. 2 administrador administrador 4096 22 de maio 16:17 .
drx------. 3 administrador administrador 4096 22 de maio 16:17 ..

Criando certificados SSH para autenticar hosts

O comando para assinar um certificado de host tem o seguinte formato:

ssh-keygen -s ca_host_key -I host_name -h ssh_host_rsa_key.pub

O certificado host será nomeado ssh_host_rsa_key-cert.pub .

Gerando um certificado de host

Para autenticar um host para um usuário, uma chave pública deve ser gerada
no host, passada para o servidor CA, assinada pela CA e, em seguida,
devolvida para ser armazenada no host e apresentada a um usuário que está
tentando fazer login no host. .

As chaves de host são geradas automaticamente no sistema. Para listá-los

digite o seguinte comando:

~]#ls -l /etc/ssh/ssh_host*
-r-------. 1 root root 668 6 de maio 14:38 /etc/ssh/ssh_host_dsa_key
-rw-r--r--. 1 root root 590 6 de maio 14:38 /etc/ssh/ssh_host_dsa_key.pub
-r-------. 1 root root 963 6 de maio 14:38 /etc/ssh/ssh_host_key
-rw-r--r--. 1 root root 627 6 de maio 14:38 /etc/ssh/ssh_host_key.pub
-r-------. 1 root root 1679 6 de maio 14:38 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root 382 6 de maio 14:38 /etc/ssh/ssh_host_rsa_key.pub

Copie a chave pública escolhida para o servidor designado como CA. Por
exemplo, do host:

~]# scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_

A autenticidade do host 'ca-server.example.com (10.34.74.58)' não pode ser es
A impressão digital da chave ECDSA é SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZB
Tem certeza de que deseja continuar se conectando (sim/não/[impressão digital
Aviso: 'ca-server.example.com,10.34.74.58' (RSA) adicionado permanentemente à
Senha de admin@ca-server.example.com:
ssh_host_rsa_key.pub 100% 382 0,4 KB/s 00:00

Alternativamente, da CA:

~]$ scp root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_h

No servidor CA, assine a chave pública do host. Por exemplo, como root :

~]# ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com

Digite a senha:
Chave de host assinada /home/admin/keys/ssh_host_rsa_key-cert.pub: id "host_n

Onde host_name é o nome do host do sistema que requer o certificado.

Copie o certificado para o host. Por exemplo, da CA:

~]# scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com

Senha de root@host_name.example.com:
ssh_host_rsa_key-cert.pub 100% 1384 1,5 KB/s 00:00

Configure o host para apresentar o certificado ao sistema de um usuário

quando um usuário iniciar o processo de login. Como root , edite
 o /etc/ssh/sshd_config arquivo da seguinte maneira:

HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Reinicie sshd para que as alterações tenham efeito:

~]#{nbsp}systemctl reiniciar sshd.service

Nos sistemas do usuário, remova as chaves pertencentes aos hosts

do ~/.ssh/known_hosts arquivo se o usuário já tiver efetuado login no host
configurado acima. Quando um usuário faz login no host, ele não deve
mais receber o aviso sobre a autenticidade do host.

Para testar o certificado de host, em um sistema cliente, certifique-se de que

o cliente tenha configurado o /etc/ssh/known_hosts arquivo global, conforme
descrito em Confiando na chave de assinatura do host , e que a chave pública
do servidor não esteja no ~/.ssh/known_hosts arquivo. Em seguida, tente
fazer login no servidor por SSH como usuário remoto. Você não deverá ver um
aviso sobre a autenticidade do host. Se necessário, adicione a -v opção ao
comando SSH para ver informações de log.

Criação de certificados SSH para autenticação de usuários

Para assinar o certificado de um usuário, use um comando no seguinte
formato:

ssh-keygen -s ca_user_key -I nome_do_usuário -n nome_do_usuário -V -start:+end id

O certificado resultante será nomeado id_rsa-cert.pub .

O comportamento padrão do OpenSSH é que um usuário tem permissão para

efetuar login como usuário remoto se um dos principais especificados no
certificado corresponder ao nome do usuário remoto. Isso pode ser ajustado
das seguintes maneiras:

Adicione mais nomes de usuários ao certificado durante o processo de

assinatura usando a -n opção:

-n "nome1[,nome2,...]"

No sistema do usuário, adicione a chave pública da CA

no ~/.ssh/authorized_keys arquivo usando a diretiva cert-authority e liste
os nomes dos principais da seguinte forma:

~]#vi ~/.ssh/authorized_keys
# Uma chave CA, aceita para qualquer host em *.example.com
@cert-authority principais="nome1,nome2" *.example.com ssh-rsa AAAAB5Wm.
 No servidor, crie um AuthorizedPrincipalsFile arquivo, por usuário ou
globalmente, e adicione os nomes dos princípios ao arquivo para os
usuários com permissão para efetuar login. Em seguida, no
arquivo, /etc/ssh/sshd_config especifique o arquivo usando
a diretiva AuthorizedPrincipalsFile .

Gerando um certificado de usuário

Para autenticar um usuário em um host remoto, uma chave pública deve ser
gerada pelo usuário, passada ao servidor CA, assinada pela CA e, em seguida,
devolvida para ser armazenada pelo usuário para uso ao efetuar login em um
host.

Em sistemas clientes, faça login como o usuário que requer o

certificado. Verifique as chaves disponíveis da seguinte forma:

~]$ ls -l ~/.ssh/

Se não existir nenhuma chave pública adequada, gere uma e defina as

permissões do diretório se o diretório não for o diretório padrão. Por
exemplo, digite o seguinte comando:

~]$ ssh-keygen -t rsa

Gerando par de chaves RSA pública/privada.
Insira o arquivo no qual deseja salvar a chave (/home/user1/.ssh/id_rsa):
Diretório criado '/home/user1/.ssh'.
Digite a senha (vazia se não houver senha):
Digite a mesma senha novamente:
Sua identificação foi salva em /home/user1/.ssh/id_rsa.
Sua chave pública foi salva em /home/user1/.ssh/id_rsa.pub.
A impressão digital principal é:
SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 usuário1@host1.example.com
A imagem aleatória da chave é:
+--[RSA 2048]----+
| ah++. |
| ooo |
| .oo . |
| ah. o |
| . oo.S |
| o=.. |
| .Eo+ |
| .= |
| .. |
+-----------------+

Por padrão, as permissões de diretório para as chaves de um usuário

são drwx------. ou octal 0700. Se necessário, confirme se as permissões
estão corretas:
 ~]$ ls -la ~/.ssh
total 16
drx------. 2 usuário1 usuário1 4096 7 de maio 12:37 .
drx------. 3 usuário1 usuário1 4096 7 de maio 12:37 ..
-r-------. 1 usuário1 usuário1 1679 7 de maio 12:37 id_rsa
-rw-r--r--. 1 usuário1 usuário1 421 7 de maio 12:37 id_rsa.pub

Consulte Usando autenticação baseada em chave para obter mais

exemplos de geração de chaves e instruções sobre como definir as
permissões de diretório corretas.
A chave pública escolhida deve ser copiada para o servidor designado
como CA, para ser assinada. O comando de cópia segura pode ser usado
para fazer isso, o comando tem o seguinte formato:

scp ~/.ssh/id_ protocol .pub admin @ca_server.example.com:~/keys/

Onde protocol é a parte do nome do arquivo que indica o protocolo usado

para gerar a chave, por exemplo rsa , admin é uma conta no servidor CA
e /keys/ é um diretório configurado para receber as chaves a serem
assinadas.

Copie a chave pública escolhida para o servidor designado como CA. Por
exemplo:

~]$ scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/

Senha de admin@ca-server.example.com:
id_rsa.pub 100% 421 0,4 KB/s 00:00

Se você configurou o sistema cliente para confiar na chave de assinatura

do host conforme descrito em Confiando na chave de assinatura do host ,
você não deverá ver um aviso sobre a autenticidade do host remoto.
No servidor CA, assine a chave pública do usuário. Por exemplo,
como root :

~]# ssh-keygen -s ~/.ssh/ca_user_key -I usuário1 -n usuário1 -V -1d:+54w /hom

Digite a senha:
Chave de usuário assinada /home/admin/keys/id_rsa-cert.pub: id "user1" serial

Copie o certificado resultante para o diretório do usuário ~/.ssh/ no

sistema. Por exemplo:

~]# scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/

senha de user1@host_name.example.com:
id_rsa-cert.pub 100% 1498 1,5 KB/s 00:00
 Se estiver usando os nomes e locais de arquivo padrão, nenhuma
configuração adicional será necessária, pois o daemon SSH procurará
certificados de usuário que terminam em -cert.pub e os usará
automaticamente se os encontrar. Observe que o local padrão e os nomes
dos arquivos para as chaves SSH versão 2 são: ~/.ssh/id_dsa e conforme
explicado na página de manual. Se você usar esses locais e convenções
de nomenclatura, não será necessário editar os arquivos de configuração
para permitir a apresentação do certificado. Eles serão usados ​
automaticamente ao fazer login em um sistema remoto. Nesse caso, pule
para a etapa 6. ~/.ssh/id_ecdsa ~/.ssh/id_rsa ssh_config(5) sshd

Se for necessário usar um diretório ou convenção de nomenclatura de

arquivo não padrão, adicione root a seguinte linha
aos arquivos /etc/ssh/ssh_config ou : ~/.ssh/config

Arquivo de identidade ~/caminho/key_file

Observe que este deve ser o nome da chave privada, não

possui .pub ou -cert.pub . Certifique-se de que as permissões do arquivo
estejam corretas. Por exemplo:

~]$ ls -la ~/.ssh/config

-rw-rw-r--. 1 usuário1 usuário1 36 27 de maio 21:49 /home/user1/.ssh/config
chmod 700 ~/.ssh/config
~]$ ls -la ~/.ssh/config
-rwx------. 1 usuário1 usuário1 36 27 de maio 21:49 /home/user1/.ssh/config

Isso permitirá que o usuário deste sistema seja autenticado por um

certificado de usuário ao efetuar login em um sistema remoto configurado
para confiar na chave de assinatura do certificado de usuário da CA.
Para testar o certificado do usuário, tente fazer login em um servidor via
SSH a partir da conta do usuário. Você deve fazer isso como o usuário
listado como princípio no certificado, se algum for especificado. Você não
deve ser solicitado a fornecer uma senha. Se necessário, adicione a -
v opção ao comando SSH para ver informações de log.

Assinando um certificado SSH usando um token PKCS#11

É possível assinar uma chave de host usando uma chave CA armazenada em
um token PKCS#11, fornecendo a biblioteca de tokens usando e -
D identificando a chave CA, fornecendo sua metade pública como argumento
para a -s opção:

ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificado_ID host_key.pub

Em todos os casos, certificado_ID é um “identificador de chave” registrado

pelo servidor quando o certificado é usado para autenticação.
Os certificados podem ser configurados para serem válidos apenas para um
conjunto de usuários ou nomes de host, os principais. Por padrão, os
certificados gerados são válidos para todos os usuários ou hosts. Para gerar
um certificado para um conjunto especificado de principais, use uma lista
separada por vírgulas com a -n opção a seguir:

ssh-keygen -s ca_user_key.pub -D libpkcs11.so -I certificado_ID -n usuário1, usuá

e para anfitriões:

ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I certificado_ID -h -n host.domain

Limitações adicionais sobre a validade e uso de certificados de usuário

podem ser especificadas através de opções de certificado. Uma opção de
certificado pode desabilitar recursos da sessão SSH, pode ser válida apenas
quando apresentada a partir de endereços de origem específicos ou pode
forçar o uso de um comando específico. Para obter uma lista de opções de
certificados válidos, consulte a ssh-keygen(1) página de manual da -O opção.

Os certificados podem ser definidos para serem válidos por um período de

vida específico. A -V opção permite especificar os horários de início e término
dos certificados. Por exemplo:

ssh-keygen -s ca_user_key -I certificado_ID -V "-1w:+54w5d" id_rsa.pub

Um certificado apresentado em horário fora desta faixa não será considerado

válido. Por padrão, os certificados são válidos indefinidamente a partir do
UNIX Epoch.

Visualizando um certificado SSH CA

Para visualizar um certificado, use -L para listar o conteúdo. Por exemplo,
para um certificado de usuário:

~]$ ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub

/home/user1/.ssh/id_rsa-cert.pub:
Digite: certificado de usuário ssh-rsa-cert-v01@openssh.com
Chave pública: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm
CA de assinatura: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
ID da chave: "usuário1"
Série: 0
Válido: de 2020-05-27T00:09:16 a 2021-06-09T00:09:16
Diretores:
usuário1
Opções críticas: (nenhuma)
Extensões:
 permissão-X11-encaminhamento
encaminhamento de agente de licença
permissão-encaminhamento de porta
licença-pty
permitir-usuário-rc

Para visualizar um certificado de host:

~]# ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub

/etc/ssh/ssh_host_rsa_key-cert.pub:
Digite: certificado de host ssh-rsa-cert-v01@openssh.com
Chave pública: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm
CA de assinatura: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
ID da chave: "host_name"
Série: 0
Válido: de 2020-05-26T17:19:01 a 2021-06-08T17:19:01
Diretores:
nome_do_host.exemplo.com
Opções críticas: (nenhuma)
Extensões: (nenhuma)

Revogando um certificado SSH CA

Se um certificado for roubado, ele deverá ser revogado. Embora o OpenSSH
não forneça um mecanismo para distribuir a lista de revogação, ainda é mais
fácil criar a lista de revogação e distribuí-la por outros meios do que alterar as
chaves da CA e todos os certificados de host e de usuário criados e
distribuídos anteriormente.

As chaves podem ser revogadas adicionando-as ao revoked_keys arquivo e

especificando o nome do arquivo no sshd_config arquivo da seguinte forma:

RevokedKeys /etc/ssh/revoked_keys

Observe que se este arquivo não for legível, a autenticação de chave pública
será recusada para todos os usuários.

Uma nova lista de revogação de chaves pode ser gerada da seguinte forma:

~]$ ssh-keygen -kf /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub

Para adicionar linhas à lista, use a -u opção de atualizar a lista:

ssh-keygen -ukf /etc/ssh/revoked_keys -z inteiro ~/.ssh/id_rsa.pub

onde inteiro é o número da linha.

Para testar se uma chave foi revogada, consulte a lista de revogação para
verificar a presença da chave. Use um comando como segue:

ssh-keygen -Qf /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub

Um usuário pode revogar um certificado CA alterando a diretiva cert-

authority para revogar no known_hosts arquivo.

Clientes OpenSSH

Certifique-se de ter pacotes relevantes instalados

Para conectar-se a um servidor OpenSSH a partir de uma máquina cliente,
você deve ter o pacote openssh-clients instalado. Veja Instalando
Pacotes para mais informações sobre como instalar novos pacotes no Fedora
38.

Usando o utilitário ssh

O utilitário ssh permite que você faça login em uma máquina remota e
execute comandos lá. É um substituto seguro para os
programas rlogin , rsh e telnet .

Da mesma forma que o comando telnet , faça login em uma máquina remota
usando o seguinte comando:

nome de host ssh

Por exemplo, para fazer login em uma máquina remota

chamada penguin.example.com , digite o seguinte em um prompt do shell:

~]$ ssh penguin.exemplo.com

Isso fará o login com o mesmo nome de usuário que você está usando na
máquina local. Se desejar especificar um nome de usuário diferente, use um
comando no seguinte formato:

nome de usuário ssh @ nome do host

Por exemplo, para fazer login penguin.example.com como USER , digite:

 ~]$ ssh USER@penguin.example.com

Na primeira vez que você iniciar uma conexão, será apresentada uma
mensagem semelhante a esta:

A autenticidade do host 'penguin.example.com' não pode ser estabelecida.

A impressão digital da chave ECDSA é SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr
Tem certeza de que deseja continuar se conectando (sim/não/[impressão digital])?

Os usuários devem sempre verificar se a impressão digital está correta antes

de responder à pergunta nesta caixa de diálogo. O usuário pode pedir ao
administrador do servidor para confirmar se a chave está correta. Isto deve
ser feito de forma segura e previamente acordada. Se o usuário tiver acesso
às chaves do host do servidor, a impressão digital poderá ser verificada
usando o comando ssh-keygen da seguinte maneira:

~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub

256 SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c sem comentários (ECDSA)

Digite yes para aceitar a chave e confirmar a conexão. Você verá um aviso de
que o servidor foi adicionado à lista de hosts conhecidos e um prompt
solicitando sua senha:

Aviso: ‘penguin.example.com’ (ECDSA) adicionado permanentemente à lista de hosts

Senha de USER@penguin.example.com:

Atualizando a chave de host de um servidor SSH

Se a chave de host do servidor SSH for alterada, o cliente notificará o
usuário de que a conexão não poderá prosseguir até que a chave de host do
servidor seja excluída do ~/.ssh/known_hosts arquivo. Antes de fazer isso,
entretanto, entre em contato com o administrador do sistema do servidor
SSH para verificar se o servidor não está comprometido.

Para remover uma chave do ~/.ssh/known_hosts arquivo, emita um

comando como segue:

~]# ssh-keygen -R penguin.example.com

# Host penguin.example.com encontrado: linha 15 tipo ECDSA
/home/USER/.ssh/known_hosts atualizado.
Conteúdo original retido como /home/USER/.ssh/known_hosts.old

Depois de inserir a senha, você receberá um prompt de shell para a máquina

remota.
Alternativamente, o programa ssh pode ser usado para executar um comando
na máquina remota sem fazer login em um prompt do shell:

ssh nome de usuário @ comando nome do host

Por exemplo, o /etc/redhat-release arquivo fornece informações sobre a

versão do Fedora. Para visualizar o conteúdo deste arquivo
em penguin.example.com , digite:

~]$ ssh USER@penguin.example.com cat /etc/redhat-release

USER@penguin.example.com Senha de:
Versão 31 do Fedora (trinta e um)

Depois de inserir a senha correta, o nome de usuário será exibido e você

retornará ao prompt do shell local.

Usando o utilitário scp

scp pode ser usado para transferir arquivos entre máquinas por meio de uma
conexão segura e criptografada. Em seu design, é muito semelhante ao rcp .

Para transferir um arquivo local para um sistema remoto, use um comando no

seguinte formato:

scp nome de usuário do arquivo local @ nome do host : arquivo remoto

Por exemplo, se você deseja transferir taglist.vim para uma máquina remota
chamada penguin.example.com , digite o seguinte em um prompt do shell:

~]$ scp taglist.vim USER@penguin.example.com :.vim/plugin/taglist.vim

USER@penguin.example.com Senha de:
taglist.vim 100% 144 KB 144,5 KB/s 00:00

Vários arquivos podem ser especificados de uma só vez. Para transferir o

conteúdo .vim/plugin/ para o mesmo diretório na máquina
remota penguin.example.com , digite o seguinte comando:

~]$ scp .vim/plugin/* USER@penguin.example.com:.vim/plugin/

Senha de USER@penguin.example.com:
closetag.vim 100% 13 KB 12,6 KB/s 00:00
trechosEmu.vim 100% 33 KB 33,1 KB/s 00:00
taglist.vim 100% 144 KB 144,5 KB/s 00:00

Para transferir um arquivo remoto para o sistema local, use a seguinte

sintaxe:
 nome de usuário scp @ nome do host : arquivo remoto arquivo local

Por exemplo, para baixar o .vimrc arquivo de configuração da máquina

remota, digite:

~]$ scp USER@penguin.example.com :.vimrc .vimrc

USER@penguin.example.com Senha de:
.vimrc 100% 2233 2,2 KB/s 00:00

O protocolo SCP não é bem projetado e pode causar resultados

inesperados. No passado, era fonte de vários CVEs onde servidores
maliciosos podiam substituir arquivos no sistema de arquivos local ao baixar
arquivos. Recomenda-se usar SFTP quando possível. Consulte a próxima
seção para obter mais informações.

Usando o utilitário sftp

O utilitário sftp pode ser usado para abrir uma sessão SFTP segura e
interativa. Em seu design, é semelhante ao FTP , exceto pelo fato de usar
uma conexão segura e criptografada.

Para conectar-se a um sistema remoto, use um comando no seguinte

formato:

nome de usuário sftp @ nome do host

Por exemplo, para fazer login em uma máquina remota

nomeada penguin.example.com como USER nome de usuário, digite:

~]$ sftp USER@penguin.example.com

Senha de USER@penguin.example.com :
Conectado a penguin.example.com.
sftp>

Depois de inserir a senha correta, você receberá um prompt. O

utilitário sftp aceita um conjunto de comandos semelhantes aos usados ​
pelo ftp (consulte Uma seleção de comandos sftp disponíveis ).

Tabela 3. Uma seleção de comandos sftp disponíveis

Comando Descrição

ls [ diretório ] Liste o conteúdo de um diretório remoto

. Se nenhum for fornecido, um diretório de
trabalho atual será usado por padrão.
Comando Descrição

diretório do CD Altere o diretório de trabalho remoto

para directory .

diretório mkdir Crie um diretório remoto .

diretório rmdir Remova um diretório remoto .

coloque arquivo local [ arquivo remoto ] Transfira o arquivo local para uma máquina
remota.

obter arquivo remoto [ arquivo local ] Transferir arquivo remoto de uma máquina
remota.

Para obter uma lista completa de comandos disponíveis, consulte

a sftp página de manual (1).

Mais do que um shell seguro

Uma interface de linha de comando segura é apenas o começo das muitas
maneiras pelas quais o SSH pode ser usado. Dada a quantidade adequada de
largura de banda, as sessões X11 podem ser direcionadas por um canal
SSH. Ou, usando o encaminhamento TCP/IP, conexões de portas
anteriormente inseguras entre sistemas podem ser mapeadas para canais
SSH específicos.

Encaminhamento X11
Para abrir uma sessão X11 por meio de uma conexão SSH, use um comando
no seguinte formato:

ssh -Y nome de usuário @ nome do host

Por exemplo, para fazer login em uma máquina remota

nomeada penguin.example.com como USER nome de usuário, digite:

~]$ ssh -Y USER@penguin.example.com

USER@penguin.example.com Senha de:

Quando um programa X é executado a partir do prompt do shell seguro, o

cliente e o servidor SSH criam um novo canal seguro e os dados do programa
X são enviados por esse canal para a máquina cliente de forma transparente.

Observe que o sistema X Window deve ser instalado no sistema remoto antes
que o encaminhamento X11 possa ocorrer. Digite o seguinte comando
para root instalar o grupo de pacotes X11:
 ~]# dnf grupo instalar "X Window System"

O encaminhamento X11 pode ser muito útil. Por exemplo, o encaminhamento

X11 pode ser usado para criar uma sessão interativa e segura do
utilitário Configurações de impressão . Para fazer isso, conecte-se ao
servidor usando ssh e digite:

~]$ impressora de configuração do sistema &

A ferramenta Configurações de impressão aparecerá, permitindo que o

usuário remoto configure com segurança a impressão no sistema remoto.

Encaminhamento de porta
O SSH pode proteger TCP/IP protocolos que de outra forma seriam inseguros
por meio do encaminhamento de porta. Ao usar esta técnica, o servidor SSH
se torna um canal criptografado para o cliente SSH.

O encaminhamento de porta funciona mapeando uma porta local no cliente

para uma porta remota no servidor. O SSH pode mapear qualquer porta do
servidor para qualquer porta do cliente. Os números das portas não precisam
ser iguais para que esta técnica funcione.

Usando números de porta reservados

Configurar o encaminhamento de porta para escutar portas abaixo de 1024
requer root acesso de nível.

Para criar um canal de encaminhamento de porta TCP/IP que escuta conexões

no localhost , use um comando no seguinte formato:

ssh -L porta local : nome do host remoto : nome de usuário da porta remota @ nom

Por exemplo, para verificar e-mail em um servidor

chamado mail.example.com por POP3 meio de uma conexão criptografada, use
o seguinte comando:

~]$ ssh -L 1100:mail.example.com:110 mail.example.com

Assim que o canal de encaminhamento de porta estiver instalado entre a

máquina cliente e o servidor de e-mail, direcione um cliente de e-mail POP3
para usar a porta 1100 no localhost para verificar novos e-mails. Quaisquer
solicitações enviadas para 1100 a porta do sistema cliente serão direcionadas
com segurança para o mail.example.com servidor.
Se mail.example.com não estiver executando um servidor SSH, mas outra
máquina na mesma rede estiver, o SSH ainda poderá ser usado para proteger
parte da conexão. No entanto, é necessário um comando ligeiramente
diferente:

~]$ ssh -L 1100:mail.example.com:110 other.example.com

Neste exemplo, as solicitações POP3 da porta 1100 na máquina cliente são

encaminhadas através da conexão SSH na porta 22 para o servidor
SSH other.example.com . Em seguida, conecte-
se à other.example.com porta para verificar novos e-mails. Observe que ao
usar esta técnica, apenas a conexão entre o sistema cliente e o servidor SSH
é segura. 110 mail.example.com other.example.com

O encaminhamento de porta também pode ser usado para obter informações

com segurança por meio de firewalls de rede. Se o firewall estiver
configurado para permitir tráfego SSH através de sua porta padrão (ou seja,
porta 22), mas bloquear o acesso a outras portas, uma conexão entre dois
hosts usando as portas bloqueadas ainda será possível redirecionando sua
comunicação por meio de uma conexão SSH estabelecida.

Uma conexão é tão segura quanto um sistema cliente

Usar o encaminhamento de porta para encaminhar conexões dessa maneira
permite que qualquer usuário no sistema cliente se conecte a esse
serviço. Se o sistema do cliente for comprometido, o invasor também terá
acesso aos serviços encaminhados.

Os administradores de sistema preocupados com o encaminhamento de

porta podem desabilitar esta funcionalidade no servidor especificando
um No parâmetro para a AllowTcpForwarding entrada de
linha /etc/ssh/sshd_config e reiniciando o serviço sshd .

Recursos adicionais
Para obter mais informações sobre como configurar ou conectar-se a um
servidor OpenSSH no Fedora, consulte os recursos listados abaixo.

Documentação instalada
sshd (8) — A página de manual do sshd daemon documenta as opções de
linha de comando disponíveis e fornece uma lista completa de arquivos e
diretórios de configuração suportados.
ssh (1) — A página de manual do aplicativo cliente ssh fornece uma lista
completa de opções de linha de comando disponíveis e arquivos e
diretórios de configuração suportados.
 scp (1) — A página de manual do utilitário scp fornece uma descrição mais
detalhada deste utilitário e seu uso.
sftp (1) — A página de manual do utilitário sftp .
ssh-keygen (1) — A página de manual do utilitário ssh-keygen documenta
detalhadamente como usá-lo para gerar, gerenciar e converter chaves de
autenticação usadas por ssh .
ssh_config (5) — A página de manual nomeada ssh_config documenta as
opções de configuração do cliente SSH disponíveis.
sshd_config (5) — A página de manual nomeada sshd_config fornece uma
descrição completa das opções de configuração do daemon SSH
disponíveis.

Documentação on-line
Página inicial do OpenSSH — A página inicial do OpenSSH contendo
documentação adicional, perguntas frequentes, links para listas de
discussão, relatórios de bugs e outros recursos úteis.
Página inicial do OpenSSL — A página inicial do OpenSSL contendo
documentação adicional, perguntas frequentes, links para listas de
discussão e outros recursos úteis.
1 . Uma conexão multiplexada consiste em vários sinais enviados por um
meio comum e compartilhado. Com o SSH, diferentes canais são
enviados por uma conexão segura comum.