110.3 Lição 1
Certificação: |
LPIC-1 |
---|---|
Versão: |
5.0 |
Tópico: |
110 Segurança |
Objetivo: |
110.3 Proteção de dados com criptografia |
Lição: |
1 de 2 |
Introdução
A proteção de dados com criptografia é uma atribuição de extrema importância na administração de sistemas — ainda mais quando se trata de acessar sistemas remotamente. Ao contrário de soluções inseguras como telnet, rlogin ou FTP, o protocolo SSH (Secure Shell) foi projetado tendo em mente a segurança. Graças à criptografia de chave pública, ele autentica hosts e usuários e criptografa todas as trocas de informações subsequentes. Além disso, o SSH pode ser usado para estabelecer túneis de porta, que — entre outras coisas — permite que um protocolo não criptografado transmita dados por meio de uma conexão SSH criptografada. A versão atual recomendada do protocolo SSH é a 2.0. O OpenSSH é uma implementação gratuita e de código aberto do protocolo SSH.
Esta lição cobrirá a configuração básica do cliente OpenSSH, bem como a função das chaves de host do servidor OpenSSH. O conceito de túneis de porta SSH também será discutido. Usaremos duas máquinas com a seguinte configuração:
Função da máquina | SO | Endereço IP | Nome do host | Usuário |
---|---|---|---|---|
Cliente |
Debian GNU/Linux 10 (buster) |
|
|
|
Servidor |
openSUSE Leap 15.1 |
|
|
|
Configuração e uso básico do cliente OpenSSH
Embora o servidor e o cliente OpenSSH venham em pacotes separados, normalmente é possível instalar um metapacote que fornece ambos ao mesmo tempo. Para estabelecer uma sessão remota com o servidor SSH, usamos o comando ssh
, especificando o usuário que desejamos conectar na máquina remota e o endereço IP ou nome de host da máquina remota. Na primeira vez que nos conectamos a um host remoto, recebemos uma mensagem como esta:
carol@debian:~$ ssh ina@192.168.1.77 The authenticity of host '192.168.1.77 (192.168.1.77)' can't be established. ECDSA key fingerprint is SHA256:5JF7anupYipByCQm2BPvDHRVFJJixeslmppi2NwATYI. Are you sure you want to continue connecting (yes/no)?
Após digitar yes
e dar Enter, será solicitada a senha do usuário remoto. Depois disso aparece uma mensagem de aviso e, em seguida, é feita a conexão ao host remoto:
Warning: Permanently added '192.168.1.77' (ECDSA) to the list of known hosts. Password: Last login: Sat Jun 20 10:52:45 2020 from 192.168.1.4 Have a lot of fun... ina@halof:~>
As mensagens são autoexplicativas: como é a primeira vez que você estabeleceu uma conexão com o servidor remoto 192.168.1.77
, sua autenticidade não pôde ser verificada em nenhum banco de dados. Assim, o servidor remoto forneceu uma ECDSA key fingerprint
(impressão digital) de sua chave pública (usando a função hash SHA256
). Depois que você aceitou a conexão, a chave pública do servidor remoto foi adicionada ao banco de dados de hosts conhecidos, permitindo assim a autenticação do servidor para conexões futuras. Esta lista de chaves públicas de hosts conhecidos é mantida no arquivo known_hosts
, que reside em ~/.ssh
:
ina@halof:~> exit logout Connection to 192.168.1.77 closed. carol@debian:~$ ls .ssh/ known_hosts
Tanto .ssh
quanto known_hosts
foram criados após a primeira conexão remota ter sido estabelecida. ~/.ssh
é o diretório padrão para configurações e informações de autenticação específicas do usuário.
Note
|
Também é possível usar |
Se você estiver usando o mesmo usuário nos hosts local e remoto, não há necessidade de especificar o nome de usuário ao estabelecer a conexão SSH. Por exemplo, se você estiver logado como a usuária carol
no debian
e quiser se conectar ao halof
também como usuária carol
, bastaria digitar ssh 192.168.1.77
ou ssh halof
(se o nome puder ser resolvido):
carol@debian:~$ ssh halof Password: Last login: Wed Jul 1 23:45:02 2020 from 192.168.1.55 Have a lot of fun... carol@halof:~>
Agora, suponha que você queira estabelecer uma nova conexão remota com um host que por acaso tem o mesmo endereço IP de halof
(o que é comum se você usa DHCP em sua LAN). Aparecerá um aviso sobre a possibilidade de um ataque man-in-the-middle:
carol@debian:~$ ssh john@192.168.1.77 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:KH4q3vP6C7e0SEjyG8Wlz9fVlf+jmWJ5139RBxBh3TY. Please contact your system administrator. Add correct host key in /home/carol/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/carol/.ssh/known_hosts:1 remove with: ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77" ECDSA host key for 192.168.1.77 has changed and you have requested strict checking. Host key verification failed.
Como não se trata de um ataque man-in-the-middle, você pode adicionar com segurança a impressão digital de chave pública do novo host a .ssh/known_hosts
. Como a mensagem indica, o comando ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77"
pode ser usado para remover a chave ofensiva (outra alternativa é usar ssh-keygen -R 192.168.1.77
para remover todas as chaves pertencentes a 192.168.1.77
de ~/.ssh/known_hosts
). Depois disso, será possível estabelecer uma conexão ao novo host.
Logins baseados em chave
Podemos configurar o cliente SSH para não fornecer nenhuma senha no login, e sim usar chaves públicas. Este é o método mais usado para a conexão a um servidor remoto via SSH, pois é muito mais seguro. A primeira coisa a fazer é criar um par de chaves na máquina cliente. Para isso, usamos ssh-keygen
com a opção -t
, especificando o tipo de criptografia desejado (Em nosso caso, Elliptic Curve Digital Signature Algorithm, ou Algoritmo de Assinatura Digital de Curvas Elípticas). Em seguida, precisamos indicar o caminho para salvar o par de chaves (~/.ssh/
é conveniente, assim como o local padrão), além de uma frase secreta. Embora a frase secreta seja opcional, é altamente recomendável usar sempre uma.
carol@debian:~/.ssh$ ssh-keygen -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/carol/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/carol/.ssh/id_ecdsa. Your public key has been saved in /home/carol/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:tlamD0SaTquPZYdNepwj8XN4xvqmHCbe8g5FKKUfMo8 carol@debian The key's randomart image is: +---[ECDSA 256]---+ | . | | o . | | = o o | | B * | | E B S o | | o & O | | @ ^ = | | *.@ @. | | o.o+B+o | +----[SHA256]-----+
Note
|
Ao criar o par de chaves, podemos passar a opção |
O comando anterior mostra mais dois arquivos em seu diretório ~/.ssh
:
carol@debian:~/.ssh$ ls id_ecdsa id_ecdsa.pub known_hosts
id_ecdsa
-
Esta é a sua chave privada.
id_ecdsa.pub
-
Esta é a sua chave pública.
Note
|
Na criptografia assimétrica (também conhecida como criptografia de chave pública), as chaves pública e privada estão matematicamente relacionadas uma com a outra de tal forma que tudo o que é criptografado por uma só pode ser descriptografado pela outra. |
A seguir, você precisa adicionar sua chave pública ao arquivo ~/.ssh/authorized_keys
do usuário que vai se logar no host remoto (se o diretório ~/.ssh
ainda não existir, é preciso criá-lo primeiro). Há várias maneiras de copiar sua chave pública para o servidor remoto: usar uma unidade flash USB, através do comando scp
— que transfere o arquivo usando SSH — ou ler (com cat) o conteúdo de sua chave pública e canalizá-lo para ssh
desta maneira:
carol@debian:~/.ssh$ cat id_ecdsa.pub |ssh ina@192.168.1.77 'cat >> .ssh/authorized_keys' Password:
Uma vez que sua chave pública tenha sido adicionada ao arquivo authorized_keys
no host remoto, podem ocorrer dois cenários ao se tentar estabelecer uma nova conexão:
-
Se você não tiver fornecido uma frase secreta ao criar o par de chaves, será conectado automaticamente. Embora conveniente, este método pode ser inseguro dependendo da situação:
carol@debian:~$ ssh ina@192.168.1.77 Last login: Thu Jun 25 20:31:03 2020 from 192.168.1.55 Have a lot of fun... ina@halof:~>
-
Se você forneceu uma frase secreta ao criar o par de chaves, terá de inseri-la em todas as conexões, como se fosse uma senha. Além da chave pública, este método adiciona uma camada extra de segurança na forma de uma frase secreta e pode — portanto — ser considerado mais seguro. No que diz respeito à conveniência, no entanto, é exatamente o mesmo que digitar uma senha sempre que se estabelecer uma conexão. Se você não usar uma frase secreta e alguém conseguir obter seu arquivo de chave SSH privada, essa pessoa terá acesso a todos os servidores em que sua chave pública estiver instalada.
carol@debian:~/.ssh$ ssh ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': Last login: Thu Jun 25 20:39:30 2020 from 192.168.1.55 Have a lot of fun... ina@halof:~>
Porém, existe uma maneira que combina segurança e conveniência: usar o agente de autenticação SSH (ssh-agent
). O agente de autenticação precisa gerar seu próprio shell e guarda na memória suas chaves privadas — para autenticação de chave pública — pelo restante da sessão. Vamos ver como ele funciona com um pouco mais de detalhes:
-
Use
ssh-agent
para iniciar um novo shell Bash:carol@debian:~/.ssh$ ssh-agent /bin/bash carol@debian:~/.ssh$
-
Use o comando
ssh-add
para adicionar sua chave privada a uma área segura da memória. Se tiver fornecido uma frase secreta ao gerar o par de chaves — o que é recomendado por razões de segurança — esse será o momento de inseri-la:carol@debian:~/.ssh$ ssh-add Enter passphrase for /home/carol/.ssh/id_ecdsa: Identity added: /home/carol/.ssh/id_ecdsa (carol@debian)
Depois de adicionar sua identidade, você pode fazer o login em qualquer servidor remoto no qual sua chave pública esteja presente sem precisar digitar sua senha novamente. Nos sistemas modernos, é comum executar este comando ao inicializar o computador, pois ele permanecerá na memória até que a máquina seja desligada (ou a chave seja descarregada manualmente).
Vamos terminar esta seção listando os quatro tipos de algoritmos de chave pública que podem ser especificados com ssh-keygen
:
RSA
-
O nome foi dado em homenagem aos criadores Ron Rivest, Adi Shamir e Leonard Adleman. Foi publicado em 1977. É considerado seguro e ainda é muito usado hoje em dia. Seu tamanho mínimo de chave é de 1024 bits (o padrão é 2048).
DSA
-
O Digital Signature Algorithm é comprovadamente inseguro e passou a ser preterido a partir do OpenSSH 7.0. As chaves DSA devem ter exatamente 1024 bits.
ecdsa
-
O Elliptic Curve Digital Signature Algorithm é um aprimoramento do DSA e — como tal — considerado mais seguro. Ele emprega a criptografia de curvas elípticas. O comprimento da chave ECDSA é determinado por um dos três tamanhos possíveis de curvas elípticas em bits: 256, 384 ou 521.
ed25519
-
É uma implementação do
EdDSA
— Edwards-curve Digital Signature Algorithm — que usa a curva 25519, mais forte. É considerado o mais seguro de todos. Todas as chaves Ed25519 têm um comprimento fixo de 256 bits.
Note
|
Quando invocado sem a especificação |
O papel das chaves de host do servidor OpenSSH
O diretório de configuração global do OpenSSH reside no diretório /etc
:
halof:~ # tree /etc/ssh /etc/ssh ├── moduli ├── ssh_config ├── ssh_host_dsa_key ├── ssh_host_dsa_key.pub ├── ssh_host_ecdsa_key ├── ssh_host_ecdsa_key.pub ├── ssh_host_ed25519_key ├── ssh_host_ed25519_key.pub ├── ssh_host_rsa_key ├── ssh_host_rsa_key.pub └── sshd_config 0 directories, 11 files
Além de moduli
e dos arquivos de configuração do cliente (ssh_config
) e do servidor (sshd_config
), quatro pares de chaves — um par de chaves para cada algoritmo suportado — são criados quando o servidor OpenSSH é instalado. Como já dissemos, o servidor usa essas chaves de host para se identificar junto aos clientes conforme necessário. Seu padrão de nome é o seguinte:
- Chaves privadas
-
ssh_host_
prefixo + algoritmo + sufixokey
(p. ex.:ssh_host_rsa_key
) - Chaves públicas (ou impressões digitais de chave pública)
-
ssh_host_
prefixo + algoritmo + sufixokey.pub
(p. ex.:ssh_host_rsa_key.pub
)
Note
|
Uma impressão digital é criada aplicando-se uma função hash criptográfica a uma chave pública. Como as impressões digitais são mais curtas do que as chaves a que se referem, elas são úteis para simplificar certas tarefas de gerenciamento de chaves. |
As permissões nos arquivos que contêm as chaves privadas são 0600
ou -rw-------
: legíveis e graváveis somente pelo proprietário (root
). Por outro lado, todos os arquivos de chave pública também são legíveis por membros do grupo do proprietário e por todos os outros (0644
ou -rw-r—r--
):
halof:~ # ls -l /etc/ssh/ssh_host_* -rw------- 1 root root 1381 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key -rw-r--r-- 1 root root 605 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key.pub -rw------- 1 root root 505 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key -rw-r--r-- 1 root root 177 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key.pub -rw------- 1 root root 411 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key -rw-r--r-- 1 root root 97 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key.pub -rw------- 1 root root 1823 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key -rw-r--r-- 1 root root 397 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key.pub
Para ver as impressões digitais das chaves, passe a opção -l
para ssh-keygen
. Também é preciso usar -f
para especificar o caminho do arquivo da chave:
halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519) halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)
Para visualizar a impressão digital da chave, bem como sua arte aleatória (randomart), basta adicionar a opção -v
:
halof:~ # ssh-keygen -lv -f /etc/ssh/ssh_host_ed25519_key.pub 256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519) +--[ED25519 256]--+ | +oo| | .+o.| | . ..E.| | + . +.o| | S + + *o| | ooo Oo=| | . . . =o+.==| | = o =oo o=o| | o.o +o+..o.+| +----[SHA256]-----+
Túneis de porta SSH
O OpenSSH apresenta um recurso de encaminhamento muito poderoso, por meio do qual o tráfego em uma porta de origem é tunelado — e criptografado — por meio de um processo SSH, que em seguida o redireciona para uma porta em um host de destino. Esse mecanismo é chamado de tunelamento de porta (port tunnelling) ou encaminhamento de porta (port forwarding) e oferece vantagens importantes, como as seguintes:
-
Permite contornar firewalls para acessar portas em hosts remotos.
-
Possibilita o acesso externo a um host em sua rede privada.
-
Fornece criptografia para todas as trocas de dados.
Grosso modo, podemos diferenciar entre o tunelamento de portas local e remoto.
Túnel de porta local
Definimos uma porta localmente para encaminhar o tráfego para o host de destino por meio do processo SSH que fica entre os dois. O processo SSH pode ser executado no host local ou em um servidor remoto. Por exemplo, se por algum motivo você quisesse fazer um túnel de conexão para www.gnu.org
por SSH usando a porta 8585
em sua máquina local, a operação seria semelhante à seguinte:
carol@debian:~$ ssh -L 8585:www.gnu.org:80 debian carol@debian's password: Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 The programs included with the Debian GNU/Linux system are free software; (...) Last login: Sun Jun 28 13:47:27 2020 from 127.0.0.1
Eis a explicação: com a opção -L
, especificamos que a porta local 8585
deve se conectar à porta http 80
em www.gnu.org
usando o processo SSH executado em debian
— nosso host local. Poderíamos ter escrito ssh -L 8585:www.gnu.org:80 localhost
com o mesmo efeito. Se agora visitássemos http://localhost:8585
com um navegador web, seríamos encaminhados a www.gnu.org
. Para fins de demonstração, usaremos o lynx
(o navegador web clássico em modo texto):
carol@debian:~$ lynx http://localhost:8585 (...) * Back to Savannah Homepage * Not Logged in * Login * New User * This Page * Language * Clean Reload * Printer Version * Search * _ (...)
Se você quisesse fazer exatamente a mesma coisa, mas se conectando por meio de um processo SSH em execução no halof
, o procedimento seria o seguinte:
carol@debian:~$ ssh -L 8585:www.gnu.org:80 -Nf ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': carol@debian:~$ carol@debian:~$ lynx http://localhost:8585 (...) * Back to Savannah Homepage * Not Logged in * Login * New User * This Page * Language * Clean Reload * Printer Version * Search * _ (...)
É importante observar três detalhes no comando:
-
Graças à opção
-N
, não fizemos login nohalof
, mas sim o encaminhamento de porta. -
A opção
-f
disse ao SSH para rodar em segundo plano. -
Especificamos o usuário
ina
para o encaminhamento:ina@192.168.1.77
Túnel de porta remota
No túnel de porta remota (ou encaminhamento de porta reversa), o tráfego vindo de uma porta no servidor remoto é encaminhado para o processo SSH em execução em seu host local e, de lá, para a porta especificada no servidor de destino (que também pode ser a sua máquina local). Por exemplo, digamos que você queira permitir que alguém de fora de sua rede acesse o servidor web Apache em execução no seu host local através da porta 8585
do servidor SSH rodando em halof
(192.168.1.77
). Você continuaria com o seguinte comando:
carol@debian:~$ ssh -R 8585:localhost:80 -Nf ina@192.168.1.77 Enter passphrase for key '/home/carol/.ssh/id_ecdsa': carol@debian:~$
Agora, qualquer pessoa que estabelecer uma conexão com o halof
na porta 8585
verá a página inicial padrão do Apache2 do Debian
:
carol@debian:~$ lynx 192.168.1.77:8585 (...) Apache2 Debian Default Page: It works (p1 of 3) Debian Logo Apache2 Debian Default Page It works! This is the default welcome page used to test the correct operation of the Apache2 server after installation on Debian systems. If you can read this page, it means that the Apache HTTP server installed at this site is working properly. You should replace this file (located at /var/www/html/index.html) before continuing to operate your HTTP server. (...)
Note
|
Existe um terceiro tipo de encaminhamento de porta mais complexo, que está fora do escopo desta lição: o encaminhamento de porta dinâmico. Em vez de interagir com uma única porta, esse tipo de encaminhamento usa diversas comunicações TCP em uma variedade de portas. |
Túneis X11
Agora que você já conhece os túneis de portas, vamos encerrar esta lição discutindo o tunelamento X11 (também conhecido como X11forwarding). Por meio de um túnel X11, o X Window System no host remoto é encaminhado para sua máquina local. Para isso, basta passar a opção -X
ao ssh
:
carol@debian:~$ ssh -X ina@halof ...
Agora você pode iniciar um aplicativo gráfico, como o navegador firefox
, com o seguinte resultado: o aplicativo será executado no servidor remoto, mas sua exibição será encaminhada ao seu host local.
Se iniciarmos uma nova sessão SSH com a opção -x
, X11forwarding será desabilitado. Tente iniciar o firefox
agora e aparecerá um erro semelhante ao seguinte:
carol@debian:~$ ssh -x ina@halof carol@192.168.0.106's password: (...) ina@halof:~$ firefox (firefox-esr:1779): Gtk-WARNING **: 18:45:45.603: Locale not supported by C library. Using the fallback 'C' locale. Error: no DISPLAY environment variable specified
Note
|
As três diretivas de configuração relacionadas ao encaminhamento de porta local, encaminhamento de porta remota e encaminhamento de X11 são |
Exercícios Guiados
-
Conectado como a usuária
sonya
em sua máquina cliente, execute as seguintes tarefas de SSH no servidor remotohalof
:-
Execute o comando para listar o conteúdo de
~/.ssh
como a usuáriaserena
no hospedeiro remoto; em seguida, volte ao seu terminal local. -
Faça login como a usuária
serena
no host remoto. -
Faça login como a usuária
sonya
no host remoto. -
Exclua todas as chaves pertencentes a
halof
de seu arquivo local~/.ssh/known_hosts
. -
Em sua máquina cliente, crie um par de chaves
ecdsa
de 256 bits. -
Em sua máquina cliente, crie um par de chaves
ed25519
de 256 bits.
-
-
Coloque as seguintes etapas na ordem certa para estabelecer uma conexão SSH usando o agente de autenticação SSH:
-
No cliente, inicie um novo shell Bash para o agente de autenticação com
ssh-agent /bin/bash
. -
No cliente, crie um par de chaves usando
ssh-keygen
. -
No cliente, adicione sua chave privada a uma área segura da memória com
ssh-add
. -
Adicione a chave pública do seu cliente ao arquivo
~/.ssh/authorized_keys
do usuário com o qual será feito o login no host remoto. -
Se ainda não existir, crie
~/.ssh
para o usuário com o qual será feito o login no servidor. -
Conecte-se ao servidor remoto.
A ordem correta é:
Passo 1:
Passo 2:
Passo 3:
Passo 4:
Passo 5:
Passo 6:
-
-
Com relação ao encaminhamento de portas, qual opção e diretiva é usada para os seguintes tipos de túneis:
Tipo de túnel Opção Diretiva Local
Remoto ou Reverso
X
-
Suponha que você digita o comando
ssh -L 8888:localhost:80 -Nf ina@halof
no terminal de sua máquina cliente. Ainda nessa máquina, você aponta um navegador parahttp://localhost:8888
. O que aparece?
Exercícios Exploratórios
-
Com relação às diretivas de segurança do SSH:
-
Qual diretiva é usada em
/etc/ssh/sshd_config
para permitir logins deroot
: -
Qual diretiva seria usada em
/etc/ssh/sshd_config
para especificar que somente uma conta local pode aceitar conexões SSH:
-
-
Ao definir o mesmo usuário no cliente e no servidor, qual comando
ssh
podemos usar para transferir a chave pública do cliente para o servidor, sendo possível fazer o login através da autenticação de chave pública? -
Crie dois túneis de portas locais em um único comando, encaminhando as portas locais sem privilégios 8080 e 8585, através do servidor remoto
halof
, para os websiteswww.gnu.org
ewww.melpa.org
, respectivamente. Use o usuárioina
no servidor remoto e não se esqueça das opções-Nf
:
Resumo
Nesta lição, discutimos o OpenSSH 2, que usa o protocolo Secure Shell para criptografar as comunicações entre o servidor e o cliente. Você aprendeu:
-
como fazer login em um servidor remoto.
-
como executar comandos remotamente.
-
como criar pares de chaves.
-
como estabelecer logins baseados em chaves.
-
como usar o agente de autenticação para garantir maior segurança e conveniência.
-
os algoritmos de chave pública suportados pelo OpenSSH:
RSA
,DSA
,ecdsa
,ed25519
. -
a função das chaves de host OpenSSH.
-
como criar túneis de portas: local, remoto e X.
Os seguintes comandos foram discutidos nesta lição:
ssh
-
Fazer login ou executar comandos em uma máquina remota
ssh-keygen
-
Gerar, gerenciar e converter chaves de autenticação.
ssh-agent
-
Agente de autenticação do OpenSSH.
ssh-add
-
Adiciona identidades de chave privada ao agente de autenticação.
Respostas aos Exercícios Guiados
-
Conectado como a usuária
sonya
em sua máquina cliente, execute as seguintes tarefas de SSH no servidor remotohalof
:-
Execute o comando para listar o conteúdo de
~/.ssh
como a usuáriaserena
no hospedeiro remoto; em seguida, volte ao seu terminal local.ssh serena@halof ls .ssh
-
Faça login como a usuária
serena
no host remoto.ssh serena@halof
-
Faça login como a usuária
sonya
no host remoto.ssh halof
-
Exclua todas as chaves pertencentes a
halof
de seu arquivo local~/.ssh/known_hosts
.ssh-keygen -R halof
-
Em sua máquina cliente, crie um par de chaves
ecdsa
de 256 bits.ssh-keygen -t ecdsa -b 256
-
Em sua máquina cliente, crie um par de chaves
ed25519
de 256 bits.ssh-keygen -t ed25519
-
-
Coloque as seguintes etapas na ordem certa para estabelecer uma conexão SSH usando o agente de autenticação SSH:
-
No cliente, inicie um novo shell Bash para o agente de autenticação com
ssh-agent /bin/bash
. -
No cliente, crie um par de chaves usando
ssh-keygen
. -
No cliente, adicione sua chave privada a uma área segura da memória com
ssh-add
. -
Adicione a chave pública do seu cliente ao arquivo
~/.ssh/authorized_keys
do usuário com o qual será feito o login no host remoto. -
Se ainda não existir, crie
~/.ssh
para o usuário com o qual será feito o login no servidor. -
Conecte-se ao servidor remoto.
A ordem correta é:
Passo 1:
No cliente, crie um par de chaves usando
ssh-keygen
.Passo 2:
Se ainda não existir, crie
~/.ssh
para o usuário com o qual será feito o login no servidor.Passo 3:
Adicione a chave pública do seu cliente ao arquivo
~/.ssh/authorized_keys
do usuário com o qual será feito o login no host remoto.Passo 4:
No cliente, inicie um novo shell Bash para o agente de autenticação com
ssh-agent /bin/bash
.Passo 5:
No cliente, adicione sua chave privada a uma área segura da memória com
ssh-add
.Passo 6:
Conecte-se ao servidor remoto.
-
-
Com relação ao encaminhamento de portas, qual opção e diretiva é usada para os seguintes tipos de túneis:
Tipo de túnel Opção Diretiva Local
-L
AllowTcpForwarding
Remoto ou Reverso
-R
GatewayPorts
X
-X
X11Forwarding
-
Suponha que você digita o comando
ssh -L 8888:localhost:80 -Nf ina@halof
no terminal de sua máquina cliente. Ainda nessa máquina, você aponta um navegador parahttp://localhost:8888
. O que aparece?A página inicial de
halof
do servidor web, que é comolocalhost
é entendido da perspectiva do servidor.
Respostas aos Exercícios Exploratórios
-
Com relação às diretivas de segurança do SSH:
-
Qual diretiva é usada em
/etc/ssh/sshd_config
para permitir logins deroot
:PermitRootLogin
-
Qual diretiva seria usada em
/etc/ssh/sshd_config
para especificar que somente uma conta local pode aceitar conexões SSH:AllowUsers
-
-
Ao definir o mesmo usuário no cliente e no servidor, qual comando
ssh
podemos usar para transferir a chave pública do cliente para o servidor, sendo possível fazer o login através da autenticação de chave pública?ssh-copy-id
-
Crie dois túneis de portas locais em um único comando, encaminhando as portas locais sem privilégios 8080 e 8585, através do servidor remoto
halof
, para os websiteswww.gnu.org
ewww.melpa.org
, respectivamente. Use o usuárioina
no servidor remoto e não se esqueça das opções-Nf
:ssh -L 8080:www.gnu.org:80 -L 8585:www.melpa.org:80 -Nf ina@halof