13.8. OpenSSH

Contribuído por Chern Lee.

O OpenSSH é um conjunto de ferramentas de conectividade de rede usadas para fornecer acesso seguro a máquinas remotas. Além disso, as conexões TCP/IP podem ser encapsuladas ou encaminhadas com segurança através de conexões SSH. O OpenSSH criptografa todo o tráfego para eliminar efetivamente a interceptação, o sequestro de conexão e outros ataques no nível da rede.

O OpenSSH é mantido pelo projeto OpenBSD e é instalado por padrão no FreeBSD. É compatível com os protocolos de versão 1 e 2 do SSH.

Quando os dados são enviados pela rede em um formato não criptografado, sniffers de rede posicionados em qualquer lugar entre o cliente e o servidor podem roubar as informações do usuário/senha ou os dados transferidos durante a sessão. O OpenSSH oferece uma variedade de métodos de autenticação e criptografia para evitar que isso aconteça. Mais informações sobre o OpenSSH estão disponíveis em http://www.openssh.com/.

Esta seção fornece uma visão geral dos utilitários embutidos de cliente para acessar com segurança outros sistemas e transferir arquivos com segurança de um sistema FreeBSD. Em seguida, descreve como configurar um servidor SSH em um sistema FreeBSD. Maiores informações estão disponíveis nas páginas man mencionadas neste capítulo.

13.8.1. Usando os Utilitários de Cliente SSH

Para logar em um servidor SSH, use ssh e especifique um nome de usuário que exista naquele servidor e o endereço IP ou nome de host do servidor. Se esta for a primeira vez que uma conexão foi feita ao servidor especificado, o usuário será solicitado a primeiro verificar a impressão digital do servidor:

# ssh user@example.com
The authenticity of host 'example.com (10.0.0.1)' can't be established.
ECDSA key fingerprint is 25:cc:73:b5:b3:96:75:3d:56:19:49:d2:5c:1f:91:3b.
Are you sure you want to continue connecting (yes/no)? yes
Permanently added 'example.com' (ECDSA) to the list of known hosts.
Password for user@example.com: user_password

O SSH utiliza um sistema de impressão digital de chaves para verificar a autenticidade do servidor quando o cliente se conecta. Quando o usuário aceita a impressão digital da chave digitando yes ao conectar-se pela primeira vez, uma cópia da chave é salva em .ssh/known_hosts no diretório pessoal do usuário. Futuras tentativas de login são verificadas em relação à chave salva e o ssh exibirá um alerta se a chave do servidor não corresponder à chave salva. Se isso ocorrer, o usuário deve primeiro verificar por que a chave foi alterada antes de continuar com a conexão.

Por padrão, versões recentes do OpenSSH aceitam apenas conexões SSH v2. Por padrão, o cliente usará a versão 2 se possível e voltará para a versão 1 se o servidor não suportar a versão 2. Para forçar o ssh a usar somente o protocolo especificado, inclua -1 ou -2. Opções adicionais são descritas em ssh(1).

Use o scp(1) para copiar com segurança um arquivo para ou de uma máquina remota. Este exemplo copia o arquivo COPYRIGHT do sistema remoto para um arquivo com o mesmo nome no diretório atual do sistema local:

# scp user@example.com:/COPYRIGHT COPYRIGHT
Password for user@example.com: *******
COPYRIGHT            100% |*****************************|  4735
00:00
#

Como a impressão digital já foi verificada para esse host, a chave do servidor é verificada automaticamente antes de solicitar a senha do usuário.

Os argumentos passados para o scp são semelhantes ao comando cp. O arquivo ou arquivos para copiar é o primeiro argumento e o destino para copiar é o segundo. Como o arquivo é buscado pela rede, um ou mais dos argumentos do arquivo assumem o formato user@host:<path_to_remote_file>. Esteja ciente ao copiar recursivamente diretórios que o scp usa a opção -r, enquanto cp usa a -R.

Para abrir uma sessão interativa para copiar arquivos, use o sftp. Consulte sftp(1) para obter uma lista de comandos disponíveis enquanto estiver em uma sessão sftp.

13.8.1.1. Autenticação Baseada em Chave

Em vez de usar senhas, um cliente pode ser configurado para se conectar à máquina remota usando chaves. Para gerar chaves de autenticação RSA, use o ssh-keygen. Para gerar um par de chaves pública e privada, especifique o tipo de chave e siga os prompts. Recomenda-se proteger as chaves com uma senha memorável, mas difícil de se adivinhar.

% ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):  1
Enter same passphrase again:                 2
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:54Xm9Uvtv6H4NOo6yjP/YCfODryvUU7yWHzMqeXwhq8 user@host.example.com
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|                 |
|                 |
|        . o..    |
|       .S*+*o    |
|      . O=Oo . . |
|       = Oo= oo..|
|      .oB.* +.oo.|
|       =OE**.o..=|
+----[SHA256]-----+

1

Digite uma senha aqui. Pode conter espaços e símbolos.

2

Digite novamente a senha para verificá-la.

A chave privada é armazenada no arquivo ~/.ssh/id_rsa e a chave pública é armazenada no arquivo ~/.ssh/id_rsa.pub. A chave publica deve ser copiada para ~/.ssh/ authorized_keys na máquina remota para que a autenticação baseada em chave funcione.

Atenção:

Muitos usuários acreditam que as chaves são seguras por design e usarão uma chave sem uma senha. Este é um comportamento perigoso. Um administrador pode verificar se um par de chaves está protegido por uma senha, visualizando a chave privada manualmente. Se o arquivo de chave privada contiver a palavra ENCRYPTED, o dono da chave está usando uma senha. Além disso, para proteger melhor os usuários finais, o termo from pode ser colocado no arquivo de chave pública. Por exemplo, adicionar from "192.168.10.5" na frente do prefixo ssh-rsa só permitirá que esse usuário específico efetue login a partir desse endereço IP.

As opções e arquivos variam de acordo com as diferentes versões do OpenSSH. Para evitar problemas, consulte ssh-keygen(1).

Se uma senha for usada, o usuário será solicitado a inserir a senha toda vez que uma conexão for feita ao servidor. Para carregar as chaves de SSH na memória e remover a necessidade de digitar a senha toda vez, use o ssh-agent(1) e o ssh-add(1).

A autenticação é feita pelo ssh-agent, usando as chaves privadas que estão carregadas nele. O ssh-agent pode ser usado para iniciar outro aplicativo como um shell ou um gerenciador de janelas.

Para usar o ssh-agent em um shell, inicie-o com um shell como um argumento. Adicione a identidade executando ssh-add e inserindo a senha para a chave privada. O usuário então poderá executar o ssh para se conectar em qualquer host que tenha a chave pública correspondente instalada. Por exemplo:

% ssh-agent csh
% ssh-add
Enter passphrase for key '/usr/home/user/.ssh/id_rsa':  1
Identity added: /usr/home/user/.ssh/id_rsa (/usr/home/user/.ssh/id_rsa)
%

1

Digite a senha para a chave.

Para usar o ssh-agent no Xorg, adicione uma entrada para ele em ~/.xinitrc. Isso fornece os serviços do ssh-agent para todos os programas iniciados no Xorg. Um exemplo do arquivo ~/.xinitrc pode ter esta aparência:

exec ssh-agent startxfce4

Isso inicia o ssh-agent, que, por sua vez, ativa o XFCE, sempre que o Xorg é iniciado. Uma vez que o Xorg tenha sido reiniciado para que as mudanças entrem em vigor, execute ssh-add para carregar todas as chaves SSH.

13.8.1.2. Tunelamento SSH

O OpenSSH tem a capacidade de criar um tunel para encapsular outro protocolo em uma sessão criptografada.

O comando a seguir informa ao ssh para criar um túnel para o telnet:

% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
%

Este exemplo usa as seguintes opções:

-2

Força o comando ssh a usar a versão 2 para conectar-se ao servidor.

-N

Indica nenhum comando ou apenas túnel. Se omitido, o ssh inicia uma sessão normal.

-f

Força o comando ssh a ser executado em segundo plano.

-L

Indica um túnel local no formato localport:remotehost:remoteport.

user@foo.example.com

O nome de login para usar no servidor SSH remoto especificado.

Um túnel SSH funciona criando um socket de escuta em localhost na localport especificada. Em seguida, ele encaminha quaisquer conexões recebidas em localport por meio da conexão SSH com o remotehost:remoteport especificado. No exemplo, a porta 5023 no cliente é encaminhada para a porta 23 na máquina remota. Como a porta 23 é usada pelo telnet, isso cria uma sessão telnet criptografada através de um túnel SSH.

Esse método pode ser usado para agrupar qualquer número de protocolos TCP inseguros, como SMTP, POP3 e FTP, como visto nos exemplos a seguir.

Exemplo 13.1. Criar um Túnel Seguro para SMTP
% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com's password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP

Isso pode ser usado em conjunto com ssh-keygen e contas de usuário adicionais para criar um ambiente de encapsulamento SSH mais uniforme. As chaves podem ser usadas no lugar de digitar uma senha e os túneis podem ser executados como um usuário separado.


Exemplo 13.2. Acesso Seguro de um Servidor POP3

Neste exemplo, há um servidor SSH que aceita conexões de fora. Na mesma rede, existe um servidor de email que executa um servidor POP3. Para verificar o e-mail de maneira segura, crie uma conexão SSH com o servidor SSH e encaminhe para o servidor de e-mail:

% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
user@ssh-server.example.com's password: ******

Quando o túnel estiver ativo e em execução, aponte o cliente de e-mail para enviar solicitações POP3 para localhost na porta 2110. Essa conexão será encaminhada com segurança pelo encapsulamento para mail.example.com.


Exemplo 13.3. Ignorando um Firewall

Alguns firewalls filtram as conexões de entrada e saída. Por exemplo, um firewall pode limitar o acesso de máquinas remotas às portas 22 e 80 para permitir apenas o SSH e navegação na web. Isso impede o acesso a qualquer outro serviço que use uma porta diferente de 22 ou 80.

A solução é criar uma conexão SSH com uma máquina fora do firewall da rede e usá-la para encapsular o serviço desejado:

% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
user@unfirewalled-system.example.org's password: *******

Neste exemplo, um cliente Ogg Vorbis de streaming pode agora ser apontado para localhost na porta 8888, que será encaminhado para music.example.com na porta 8000, ignorando com êxito o firewall.


13.8.2. Ativando o Servidor SSH

Além de fornecer utilitários de cliente SSH embutidos, um sistema FreeBSD pode ser configurado como um servidor SSH, aceitando conexões de outros clientes SSH.

Para ver se o sshd está operando, use o comando service(8):

# service sshd status

Se o serviço não estiver em execução, adicione a seguinte linha ao arquivo /etc/rc.conf.

sshd_enable="YES"

Isso iniciará o sshd, o programa daemon para o OpenSSH, na próxima vez que o sistema for inicializado. Para iniciá-lo agora:

# service sshd start

A primeira vez que o sshd inicia em um sistema FreeBSD, as chaves de host do sistema serão criadas automaticamente e a impressão digital será exibida no console. Forneça aos usuários a impressão digital para que eles possam verificá-la na primeira vez que se conectarem ao servidor.

Consulte o sshd(8) para obter a lista de opções disponíveis ao iniciar o sshd e uma discussão mais completa sobre autenticação, processo de login e os vários arquivos de configuração.

Neste ponto, o sshd deve estar disponível para todos os usuários com um nome de usuário e senha no sistema.

13.8.3. Segurança do Servidor SSH

Enquanto o sshd é o recurso de administração remota mais usado para o FreeBSD, a força bruta e o drive por ataques são comuns a qualquer sistema exposto a redes públicas. Vários parâmetros adicionais estão disponíveis para evitar o sucesso desses ataques e serão descritos nesta seção.

É uma boa ideia limitar quais usuários podem efetuar login no servidor SSH e de onde usar a palavra-chave AllowUsers no arquivo de configuração do servidor OpenSSH. Por exemplo, para permitir que somente o root efetue login de 192.168.1.32, inclua esta linha no arquivo /etc/ssh/sshd_config:

AllowUsers root@192.168.1.32

Para permitir que o usuário admin efetue login de qualquer lugar, liste esse usuário sem especificar um endereço IP:

AllowUsers admin

Multiplos usuários devem ser listados na mesma linha, assim:

AllowUsers root@192.168.1.32 admin

Depois de fazer alterações no arquivo /etc/ssh/sshd_config, informe o sshd para recarregar seu arquivo de configuração executando:

# service sshd reload

Nota:

Quando essa palavra-chave é usada, é importante listar cada usuário que precisa efetuar login nesta máquina. Qualquer usuário que não esteja especificado nessa linha será bloqueado. Além disso, as palavras-chave usadas no arquivo de configuração do servidor OpenSSH fazem distinção entre maiúsculas e minúsculas. Se a palavra-chave não estiver escrita corretamente, incluindo esse detalhe, ela será ignorada. Sempre teste as alterações neste arquivo para garantir que as edições estejam funcionando conforme o esperado. Consulte o sshd_config(5) para verificar a ortografia e o uso das palavras-chave disponíveis.

Além disso, os usuários podem ser forçados a usar a autenticação de dois fatores por meio do uso de uma chave pública e privada. Quando necessário, o usuário pode gerar um par de chaves usando o ssh-keygen(1) e enviar ao administrador a chave pública. Este arquivo de chave será colocado no arquivo authorized_keys como descrito acima na seção cliente. Para forçar os usuários a usar apenas as chaves, a seguinte opção pode ser configurada:

AuthenticationMethods publickey

Dica:

Não confunda o arquivo /etc/ssh/sshd_config com /etc/ssh/ssh_config (observe o d extra no primeiro nome do arquivo). O primeiro arquivo configura o servidor e o segundo arquivo configura o cliente. Consulte o ssh_config(5) para obter uma listagem das configurações do cliente disponíveis.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.