Comando ssh no Linux (secure shell) [Guia Básico]
O pacote OpenSSH oferece serviço de acesso remoto a computadores com o Linux de forma segura com conexão criptografada ponta a ponta através do comando ssh no Linux.
Ele utiliza o protocolo ssh (secure shell) para permitir a transferência de arquivos e shell seguro.
Ele foi criado para substituir os servidores de conexão que trafegam dados sem criptografia como o telnet, rsh e rlogin. A versão de código aberto gratuito pode ser obtida no site http://www.openssh.org ou no instalada diretamente como pacote na maioria das distribuições.
O OpenSSH conta com portabilidade para diversos sistemas como Linux, Solaris, FreeBSD, NetBSD, AIX, IRIX, HP-UX e OpenBSD.
A instalação do OpenSSH é simples e pode ser feita através de pacotes com o apt-get no Debian ou yum no Redhat.
A criptografia do OpenSSH utiliza o conceito de par de chaves públicas e privadas.
Algoritmos de Criptografia
OpenSSH suporta vários algoritmos de assinatura para chaves de autenticação que podem ser divididos em dois grupos, dependendo das propriedades matemáticas que exploram:
- DSA e RSA, que dependem da dificuldade prática de fatorar o produto de dois grandes números primos;
- ECDSA e Ed25519, que dependem do problema do logaritmo discreto da curva elíptica.
Algoritmos de criptografia de curva elíptica (ECC) são uma adição mais recente aos sistemas de criptografia de chave pública. Uma de suas principais vantagens é a capacidade de fornecer o mesmo nível de segurança com chaves menores, o que torna operações menos computacionalmente intensivas (ou seja, criação de chaves mais rápidas, criptografia e descriptografia também.
Configuração do cliente OpenSSH 2
Para cada usuário, o ssh também cria os seus pares de chaves, que residem no subdiretório “.ssh” do diretório HOME do usuário. A qualquer momento, o usuário pode criar seus pares de chave com o comando ssh-keygen:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/uiraribeiro/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/uiraribeiro/.ssh/id_rsa.
Your public key has been saved in /home/uiraribeiro/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:7p177xnRUY0HDcrdUbDCQg uiraribeiro@Notebook-do-Uira
The key's randomart image is:
+---[RSA 2048]----+
| E==o=+=o .. |
| =+ =o.=.oo|
| = +o oo |
+----[SHA256]-----+
O ssh-keygen pode criar os seguintes pares de chaves com diferentes algoritmos de criptografia:
- Chave privada DSA: ~/.ssh/id_dsa (DSA);
- Chave pública DSA: ~/.ssh/id_dsa.pub (DSA);
- Chave privada ECDSA: ~/.ssh/id_ecdsa (ECDSA);
- Chave pública ECDSA: ~/.ssh/id_ecdsa.pub (ECDSA);
- Chave privada Ed25519: ~/.ssh/id_ed25519 (Ed25519);
- Chave pública Ed25519: ~/.ssh/id_ed25519.pub (Ed25519);
- Chave privada RSA: ~/.ssh/id_rsa (RSA);
- Chave pública RSA: ~/.ssh/id_rsa.pub (RSA)
Autenticação sem senha
O usuário pode se desejar copiar sua chave pública para o diretório HOME do usuário que usa para conectar em na máquina remota no arquivo ~/.ssh/authorized_keys. Assim, ele não necessitará mais de fornecer a senha para uma conexão remota com o esse determinado host e usuário.
Arquivo /etc/ssh_config
O cliente ssh mantém um arquivo /etc/ssh/ssh_config para as configurações do cliente SSH. Dentre elas destacam-se:
Protocol 2 # permite que somente o SSH2 seja usado
Port 22 # altera a porta padrão do SSH de 22 para outra
ForwardX11Trusted no # não permite login remote via X11
Conexão Remota usando o SSH
Quando uma conexão a um servidor SSH é feita, há uma troca de chaves públicas entre o cliente ssh e o servidor sshd.
Então quando o servidor deseja enviar algo para o cliente, ele utiliza a chave pública do cliente para criptografar os dados para ele. Somente a chave privada do cliente é capaz de descriptografar aquilo que foi criptografado com a sua chave pública.
O mesmo acontece quando o cliente quer enviar algo para o servidor. Ele utiliza a chave pública do servidor para criptografar algo para ele. Desta forma somente a chave privada do servidor é capaz de ler o seu conteúdo.
Para se conectar em um host usando o ssh, o comando segue o padrão:
$ ssh nomedousuario@enderecodohost
E para fazer conexão com protocolo X11, usa-se a opção “-X” ou “-Y”:
$ ssh -X [email protected]
O ssh troca automaticamente as chaves públicas do usuário local com as chaves do usuário remoto, de forma transparente.
Também é possível executar remotamente um comando no host de destino usando o ssh:
$ ssh [email protected] svn /var/www/html
Neste exemplo, o ssh fará a autenticação, e executará o comando “svn /var/www/html” no servidor remoto.
O ssh permite especificar uma porta de conexão, quando a porta 22 não é a porta padrão do servidor remoto:
$ ssh -p 2222 [email protected]
A opção “-p” permite especificar a porta.
ssh_know_hosts
O arquivo /etc/ssh/ssh_known_hosts ou ~/.ssh/known_hosts é consultado quando o método de acesso utilizado é baseado na autenticação RSA. Este arquivo contém as chaves públicas de uma máquina para que a conexão seja bem-sucedida.
Assim que uma conexão é estabelecida pela primeira vez, o ssh grava um hash do servidor no arquivo ~/.ssh/know_hosts. Nas próximas conexões esse hash é comparado com o recebido pelo servidor e do arquivo know_hosts.
Se por algum motivo o servidor for alterado, a comparação irá falhar, o SSH não irá conectar e vai emitir um alerta, dizendo que o servidor é possivelmente outra máquina e não aquela conhecida.
Quando há a necessidade de troca do servidor, o cliente ssh deve remover a linha correspondente ao servidor no arquivo ~/.ssh/know_hosts.
OpenSSH Server
O serviço que provê conexão remota usando o SSH do pacote OpenSSH é o sshd. Este serviço é executado geralmente através do gerenciador de serviços Systemd.
No momento da instalação do OpenSSH Server, será criada uma chave pública e uma chave privada do seu host. Na versão 2 do SSH, são criados os seguintes arquivos:
/etc/ssh/ssh_host_rsa_key (chave privada RSA)
/etc/ssh/ssh_host_rsa_key.pub (chave pública RSA)
/etc/ssh/ssh_host_dsa_key (chave privada DSA)
/etc/ssh/ssh_host_dsa_key.pub (chave pública DSA)
/etc/ssh/ssh_host_ecdsa_key (chave privada ECDSA)
/etc/ssh/ssh_host_ecdsa_key.pub (chave pública ECDSA)
/etc/ssh/ssh_host_ed25519_key (chave privada Ed25519)
/etc/ssh/ssh_host_ed25519_key.pub (chave pública Ed25519)
Estas chaves não devem ser alteradas, pois são as chaves de criptografia de seu host. Se alguma destas chaves for alterada, as máquinas que você conectou não irão mais aceitar uma conexão sua, pois entenderão que alguém está se passando por você.
sshd_config
O arquivo de configuração principal do sshd é o /etc/ssh/sshd_config. É importante que este arquivo tenha permissão de leitura e gravação somente para o super usuário, pois ele contém informações sensíveis, como permitir a entrada do root ou apenas uma lista de usuários.
O arquivo sshd_config é muito rico em possibilidades de configurações.
As seguintes informações são relevantes na configuração do sshd:
Protocol 2 # permite que somente o SSH2 seja usado
Port 4999 # altera a porta padrão do SSH de 22 para outra
ForwardX11 no # não permite login remote via X11
PermitRootLogin no # não permite que o root entre remotamente
MaxAuthTries 2 # define o número máximo de tentativas de erro
AllowUsers tom jerry # define quais logins são permitidos via ssh
Geralmente, por questões de segurança, não é comum permitir que o root faça acesso direto ao ssh, desta forma o administrador deve entrar com outra conta com privilégios normais e nos comandos que exigem o super-usuário utilizar o sudo.
Habiltar o sshd
Para iniciar o serviço de ssh servidor:
$ systemctl start sshd
Para habilitar o serviço na carga do sistema operacional:
$ systemctl enable sshd
ssh-agent e ssh-add
Os aplicativos ssh-agent e ssh-add podem ser utilizados para controlar a conexão ssh, de forma que o usuário não precise digitar sua senha de autenticação na máquina destino a cada conexão.
É necessário que a máquina destino tenha uma cópia da chave pública do usuário na pasta home/.ssh do usuário destino na máquina destino:
# scp /root/.ssh2/hostkeys/key.pub root@server:/root/.ssh
O comando “scp” faz uma cópia segura da chave pública criada com o ssh-keygen para o diretório “/root/.ssh” da máquina destino.
Feito isto, o comando “ssh-agent” mostra quais são as variáveis ambientais que precisam ser criadas e qual o PID do processo do agente SSH que irá controlar a conexão:
# ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-lqMuRR398/agent.398; export SSH_AUTH_SOCK;
SSH_AGENT_PID=399; export SSH_AGENT_PID;
Copie e cole no shell o texto que o ssh-agent mostrou:
# SSH_AUTH_SOCK=/tmp/ssh-lqMuRR398/agent.398; export SSH_AUTH_SOCK;
# SSH_AGENT_PID=399; export SSH_AGENT_PID;
Depois disso, é necessário executar o “ssh-add” e digitar a “passphrase” que foi digitada no ato da criação das chaves:
# ssh-add
Enter passphrase:
Desta forma, quando você for fazer uma conexão segura com a “maquinadestino”, o ssh não irá perguntar sua senha.
# ssh root@maquinadestino
Outra forma de fazer isso é copiar o conteúdo da chave pública id_rsa.pub da máquina cliente para o arquivo ~/.ssh/authorized_keys da máquina servidora. Desta forma quando o cliente necessitar entrar na máquina servidora, não será exigida senha.
ssh-copy-id
O programa ssh-copy-id pode ser usado para fazer a cópia da chave pública para a máquina remota de forma segura e rápida. Ele faz a cópia da chave pública do usuário para o servidor remoto em ~/.ssh.authorized_keys.
$ ssh-copy-id [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: /home/uiraribeiro/.ssh/id_rsa.pub
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
Pessoalmente, eu não gosto de usar este método de acesso sem pedir senha. Uma vez que sua máquina esteja vulnerável, todas as máquinas em que você usa regularmente o acesso ssh via chaves também estará comprometido.
Deixando o SSHD mais Seguro
Trocar a porta do SSH
Um dos truques para deixar o ssh mais seguro é trocar a porta padrão de conexão do serviço de ssh.
Isso pode ser feito alterando o arquivo /etc/ssh/sshd_config, alterando a diretiva “Port“. Geralmente esta linha estará comentada com “#”. É preciso desconmentar e alterar a porta de 22 para alguma outra acima de 1024:
Port 2323
Não permitir login com o Root
Também é interessante desabilitar o acesso do super-usuário root no ssh, permitindo assim que somente usuários comuns façam login remoto.
Isso pode ser feito alterando o arquivo /etc/ssh/sshd_config, na diretiva “PermitRootLogin”, que deverá estar descomentada e com valor igual a “no”:
PermitRootLogin no
Depois de qualquer alteração no arquivo sshd_config, é necessário reiniciar o serviço de ssh:
# systemctl restart sshd
Uso de Tcpwrapper
Uma técnica antiga no Linux para limitar o acesso a um determinado serviço é o uso do tcpwrapper.
O tcpwrapper funciona como um porteiro que intercepta uma conexão e verifica se determinado serviço pode ser acessado por um cliente. Desta forma é possível limitar quais os endereços IP de clientes que podiam acessar determinado serviço.
Os programas no Linux que fazem uso do tcpwrapper usam a biblioteca libwrap.so.
Para determinar se um programa faz uso do tcpwrapper, pode-se consultar quais bibliotecas ele utiliza com o programa ldd:
$ ldd /usr/sbin/sshd | grep wrap
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0
Neste caso, é possível constatar que o programa sshd, utiliza a biblioteca libwrap, e portanto, é capaz limitar quais são os hosts que podem acessar o shell seguro.
Para limitar quais os hosts clientes podem acessar qual serviço, o tcpwrapper consulta os arquivos /etc/hosts.allow e /etc/hosts.deny para saber quais endereços IP podem acessar qual serviço.
hosts.allow e hosts.deny
Os arquivos /etc/hosts.allow e /etc/hosts.deny são utilizados para definir regras de acesso aos serviços oferecidos pelo computador.
O conteúdo dos arquivos hosts.allow e hosts.deny seguem o seguinte formato:
nome_do_serviço: endereço_ip
Há uma lógica e uma ordem estabelecida:
Quando uma conexão é estabelecida, o tcpwrapper lê primeiro o conteúdo do arquivo /etc/hosts.allow. Se existir uma regra para esta conexão ele não checa o arquivo hosts.deny.
$ cat /etc/hosts.allow
sshd: 10.10.100.1
Se nenhuma regra for encontrada no hosts.allow, ele lê o /etc/hosts.deny à procura de uma regra. Se for encontrado algo que combine no hosts.deny, ele termina a conexão. Se nada que combine for encontrado, ele libera o acesso.
Se você quiser que apenas as conexões explicitamente liberadas no arquivo hosts.allow sejam permitidas, negando qualquer outro cliente não declarado, a regra “ALL:ALL” pode ser colocada no arquivo /etc/hosts.deny para que somente as conexões explicitamente definidas pelas regras em hosts.allow sejam aceitas.
Outra combinação possível no hosts.deny é negar tudo por serviço com a regra “sshd:all“. Algumas distribuições trocam a palavra “all” por “paranoid“.
Os endereços IP declarados nos arquivos hosts.allow e hosts.deny podem ser tanto na versã IPv4 quando em IPv6. Mais de um endereço deve ser separado por vírgulas:
sshd: 192.168.0.10, 192.168.0.15
Pode-se declarar também um endereço de uma máquina:
sshd: uira.certificacaolinux.com.br
É possível também liberar por subnet:
sshd: 192.168.0.0/255.255.255.0
O tcpwrapper também aceita uma combinação partial, se a linha terminar com um “.”:
sshd: 192.168.0.
Neste caso, todos os endereços que iniciam com “192.168.0” estarão incluídos.
A restrição de quais clientes podem conectar em um determinado serviço é uma tarefa hoje delegada ao uso de um bom Firewall. No entanto, o tcpwrappers oferece uma camada a mais de segurança, uma vez que se o firewall falhar, há ainda o tcpwrapper para garantir alguma proteção extra.
Aprenda muito mais sobre Linux em nosso curso online. Você pode efetuar a matrícula aqui. Se você já tem uma conta, ou quer criar uma, basta entrar ou criar seu usuário aqui.
Gostou? Compartilhe
Tag:/dev, bash, certificação, certificaçãolinux, code, Comptia, developer, empreendedorismo, exame, freesoftware, gnu, hack, Linux, linuxfan, linuxfun, linuxmint, lovelinux, LPI, LPIC, management, nerd, opensource, php, prova, shell, software, softwarelivre, sql, tech, ti, unix