Quando se trata de computação remota, SSH é um dos protocolos mais populares e seguros. O SSH é um protocolo de rede criptográfico que estabelece uma conexão segura com dispositivos remotos. Ao se conectar a um dispositivo remoto, o usuário pode executar comandos no shell remoto. O SSH é mais comum entre administradores de rede e de sistemas.
Este guia em estilo de folha de dicas (cheat sheet) demonstra uma visão geral do SSH, algumas formas comuns de conexão com o SSH e várias configurações do SSH.
Visão geral do SSH
SSH é uma sigla para Secure Shell. Alguns também se referem ao SSH como Secure Socket Shell. O SSH é a forma mais comum de acessar um servidor remoto. Ao se conectar a um sistema remoto usando SSH, você se conecta a uma conta existente. Quando conectado, você terá acesso a uma sessão de shell. Todos os comandos executados serão rodados na máquina remota e a saída será exibida no seu terminal local.
A conexão SSH segue um modelo cliente-servidor. O sistema remoto deve estar executando o daemon SSH para aceitar conexões SSH remotas. O daemon SSH escuta portas específicas, autentica solicitações de conexão e gera o ambiente apropriado quando as condições são atendidas.
Para este guia, nós configuramos dois servidores Ubuntu. O servidor primário será configurado para se conectar ao servidor secundário. O servidor secundário será configurado para aceitar conexões SSH do servidor primário. Os endereços IP desses servidores serão usados ao longo do guia:
-
Primário: 31.171.250.121
-
Secundário: 31.171.250.130
Para começar, você pode dar uma olhada em nossos guias detalhados sobre como usar o SSH para se conectar a um servidor remoto no Ubuntu e como configurar seu servidor Linux para usar autenticação baseada em chave SSH. Agora, vamos começar!
Autenticação SSH
Existem dois tipos principais de autenticação SSH. O método tradicional é usando uma senha. É menos seguro e fortemente não recomendado. O segundo método são as chaves SSH. As chaves SSH oferecem uma segurança muito forte e são altamente recomendadas.
Embora a autenticação por senha seja mais simples de entender e configurar, ela é facilmente explorada. Por exemplo, bots automatizados podem usar força bruta para invadir um sistema. As chaves SSH são chaves criptográficas. Cada chave tem duas partes – uma chave privada e uma chave pública. A chave pública pode ser compartilhada em qualquer lugar sem qualquer preocupação. No entanto, a chave privada deve permanecer protegida.
Para usar as chaves SSH como método de autenticação, o sistema remoto deve ter uma cópia da chave pública instalada. Cópias das chaves privada e pública também devem ser instaladas no sistema local. Por padrão, as chaves públicas são listadas no seguinte arquivo. Cada usuário único tem uma cópia exclusiva deste arquivo:
|
1 |
~/.ssh/authorized_keys |
Veja como funciona o processo de autenticação:
-
O sistema cliente envia uma solicitação de conexão para o sistema remoto. Ele também envia qual chave SSH usar.
-
O sistema remoto verifica se a chave pública está listada em authorized_keys.
-
Se a chave existir, uma string aleatória é gerada e criptografada usando a chave pública. A mensagem criptografada só pode ser descriptografada usando a chave privada.
-
Ao receber a string, o cliente irá descriptografá-la.
-
Combinando a string e o ID de sessão previamente negociado, um hash MD5 é gerado. O cliente envia o hash MD5 para o sistema remoto.
-
O sistema remoto conhece a string aleatória e o ID da sessão. Se o hash MD5 corresponder, a conexão é permitida.
Chaves SSH
Neste guia, a chave SSH será o foco principal da autenticação. Portanto, esta seção se concentrará em como trabalhar com chaves SSH.
-
Gerando um par de chaves SSH
Por padrão, um sistema Linux não possui uma chave SSH instalada. No entanto, o sistema pode conter chaves SSH geradas/instaladas anteriormente. Assumindo que não há nenhuma chave SSH anterior, precisamos gerar um novo par de chaves SSH pública e privada. O SSH suporta muitos algoritmos criptográficos para gerar chaves SSH, por exemplo, RSA, DSA, ECDSA e EdDSA. O RSA é o algoritmo padrão e preferido.
-
Gerando um par de chaves RSA normal
Para gerar um par de chaves SSH, execute o seguinte comando:
|
1 |
ssh-keygen |
O prompt perguntará onde você deseja armazenar o par de chaves. Como mencionado, será um par de chaves RSA. Se nenhum valor for inserido, o SSH o salvará no local padrão /home/demo/.ssh/id_rsa.
O próximo passo é inserir uma senha. Recomenda-se o uso de uma senha. O comprimento da senha é arbitrário. Ela adiciona uma camada de segurança. No entanto, o SSH permite gerar chaves sem nenhuma senha. Basta pressionar Enter se quiser chaves sem senha.
A saída final fornece as seguintes informações da chave:
-
A localização da chave privada ( /root/.ssh/id_rsa). Ela nunca deve ser compartilhada.
-
A localização da chave pública ( /root/.ssh/id_rsa.pub). É seguro compartilhá-la com qualquer pessoa.
-
A impressão digital da chave.
-
Uma imagem aleatória da chave. A ideia é que, se houver um comprometimento das chaves, você provavelmente poderá notar ao perceber qualquer alteração na imagem da chave.
-
Gerando um par de chaves RSA com bits diferentes
Por padrão, as chaves SSH são de 2048 bits. Para segurança, isso é considerado bom o suficiente. No entanto, podemos especificar manualmente o uso de um número diferente de bits. Quanto maior o valor do bit, mais forte é a chave.
Execute o seguinte comando para gerar um par de chaves SSH de 4096 bits. A maioria dos servidores suporta chaves SSH de 4096 bits. Se a chave for muito grande, ela pode não ser aceita para fins de proteção contra DDoS:
|
1 |
ssh-keygen -b 4096 |
Como já havíamos gerado um par de chaves, o SSH perguntará se deseja sobrescrever o anterior. O restante do processo é o mesmo que gerar um par de chaves normal.
-
Alterando a senha da chave privada
Podemos alterar a senha da chave privada. O processo exige que você conheça a senha atual. Para alterar a senha, execute o seguinte comando:
|
1 |
ssh-keygen -p |

O comando solicitará que você insira a localização da chave privada. Pressione Enter se a chave estiver armazenada no local padrão. Insira a senha atual. Se aceita, você poderá definir uma nova.
-
Exibindo a impressão digital de uma chave SSH
Cada par de chaves SSH compartilha uma impressão digital criptográfica. Essa impressão digital pode ser usada para identificar chaves exclusivas. Pode ser útil em várias situações. Execute o seguinte comando para verificar a impressão digital de uma chave SSH:
|
1 |
ssh-keygen -l |

Insira a localização da chave. Pressione Enter se a chave estiver armazenada no local padrão.
Copiando a Chave Pública
O par de chaves SSH está pronto para proteger conexões remotas. Para que o sistema remoto aceite a chave SSH para autenticação, ele precisa ter uma cópia da chave pública. Existem várias maneiras de copiar a chave pública para o servidor remoto.
-
Usando o ssh-copy-id
O ssh-copy-id vem como parte do pacote OpenSSH. É a forma padrão de copiar a chave pública SSH. É simples e fácil de usar. Execute o seguinte comando para transferir uma cópia da chave pública:
|
1 |
ssh-copy-id <username>@<secondary_server_ip> |

Você precisa da senha da conta do usuário remoto para concluir o processo. Se for bem-sucedido, haverá uma mensagem de sucesso.
-
Usando conexão SSH
Se o uso do ssh-copy-id utilitário não estiver disponível, mas o servidor primário puder se conectar ao servidor secundário usando SSH, podemos usar um truque diferente para copiar a chave. Trata-se de direcionar o conteúdo da chave pública via comando SSH para o lado remoto. Observe que se o diretório ~/.ssh não existir no sistema remoto, pode não funcionar:
|
1 |
cat ~/.ssh/id_rsa.pub | ssh <username>@<secondary_server_ip> "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" |
-
Copiando manualmente
Se uma conexão remota não for uma opção, o único processo restante é adicionar manualmente a chave pública ao servidor remoto. Primeiro, obtenha o conteúdo da chave pública:
|
1 |
cat ~/.ssh/id_rsa.pub |
No servidor remoto, coloque a chave no local apropriado:
|
1 2 3 |
mkdir -pv ~/.ssh echo <public_key> >> ~/.ssh/authorized_keys |
Using SSH
Agora que a chave pública está configurada, estamos prontos para usar o SSH para nos conectarmos remotamente.
-
Conectando a um sistema remoto
O primeiro passo é aprender como se conectar ao sistema remoto usando SSH. Isso pressupõe que tanto o sistema local quanto o remoto permitam o tráfego SSH. Para se conectar ao sistema remoto, digite o seguinte:
|
1 |
ssh <secondary_server_ip> |

Para se conectar a um usuário específico no servidor remoto, use a seguinte estrutura:
|
1 |
ssh <username>@<secondary_server_ip> |

Se for a primeira vez que se conecta ao servidor, o SSH poderá exibir um aviso. Digite yes para continuar a conexão. Se a conta remota for protegida por senha, você terá que digitar a senha. Se a chave SSH for protegida por frase secreta, você também terá que digitar a frase secreta.
-
Conectando a uma porta diferente
Por padrão, o SSH roda na porta 22. O cliente SSH assumirá o valor padrão da porta ao se conectar ao sistema remoto. No entanto, se o sistema remoto escutar em uma porta diferente para o tráfego SSH, isso não funcionará. Em tal situação, precisamos declarar manualmente o número da porta. Para declarar a porta específica, use a -p flag:
|
1 |
ssh -p <port> <username>@<secondary_server_ip> |
Declarar a porta manualmente o tempo todo é contraproducente. Podemos alterar o valor padrão da porta permanentemente. Para fazer isso, abra o arquivo de configuração do SSH. Se o arquivo não existir, o seguinte comando irá criá-lo:
|
1 |
nano ~/.ssh/config |
Em seguida, adicione as seguintes linhas:
|
1 2 3 4 5 |
Host <remote_alias> HostName <remote_hostname> Port <port_value> |
-
Executando comandos no servidor remoto
Agora que a conexão foi estabelecida, qualquer comando que você executar no terminal local irá para o servidor remoto. Qualquer saída gerada será enviada para o terminal local.
Se for apenas um único comando a ser executado, podemos executá-lo sem realizar um login SSH completo. Podemos simplesmente declarar o comando após a instrução de conexão SSH:
|
1 |
ssh <username>@<secondary_server_ip> <command_to_run> |
-
Adicionando uma chave a um agente SSH
Se a chave SSH tiver uma frase secreta, toda vez que você se conectar ao sistema remoto, terá que digitar a frase secreta. Fazer isso repetidamente é contraproducente. Podemos deixar que um agente SSH cuide disso. É um pequeno utilitário que armazena a chave privada depois que você insere a frase secreta. A chave privada estará disponível durante a sessão do terminal. Para iniciar o agente SSH, execute o seguinte comando:
|
1 |
eval $(ssh-agent) |

O programa está rodando em segundo plano. Tudo o que você precisa fazer é adicionar sua chave privada ao agente. Execute o seguinte comando:
|
1 |
ssh-add |

Insira a frase secreta para concluir a operação.
-
Encaminhando credenciais SSH
Também podemos configurar o SSH para se conectar de um servidor a outro sem senha. Isso pode ser bastante eficiente, especialmente ao trabalhar com vários servidores remotos. Para conseguir isso, precisamos encaminhar as credenciais SSH. O encaminhamento de credenciais SSH exige que o servidor remoto esteja configurado para aceitar uma conexão da máquina/servidor local. Então, tudo o que você precisa fazer é se conectar ao primeiro servidor usando a -A flag. Ele encaminha suas credenciais para os servidores para a sessão atual:
|
1 |
ssh -A <username>@<secondary_server_ip> |
Configurações do servidor remoto
Esta seção contém algumas das configurações comuns do lado do servidor para ajudar você a melhorar as respostas do servidor e a segurança da conexão.
-
Desativando a autenticação por senha
Se as chaves SSH estiverem configuradas e a conexão SSH estiver funcionando como esperado, então é seguro desativar a autenticação por senha. A seguinte configuração deixará de solicitar uma senha quando qualquer usuário se conectar via SSH. No servidor remoto, abra o sshd_config arquivo com root/sudo privilégio:
|
1 |
sudo nano /etc/ssh/sshd_config |
Em seguida, procure pela entrada PasswordAuthentication. Se a linha estiver comentada, descomente-a. Altere o valor para no:
|
1 |
PasswordAuthentication no |

Salve o arquivo e feche o editor. Para que as alterações entrem em vigor, reinicie o serviço SSH:
|
1 |
sudo service ssh restart |
Se o sistema for CentOS/Fedora, use o seguinte comando em seu lugar:
|
1 |
sudo service sshd restart |
-
Alterando a porta SSH
Como mencionado anteriormente, o SSH usa a porta 22 para trocar tráfego SSH. No entanto, de acordo com alguns administradores de sistema, é melhor atribuir uma porta diferente para o SSH. Isso pode ajudar contra bots automatizados inundando a porta. Para alterar a porta em que o SSH escuta, abra o sshd_config arquivo:
|
1 |
sudo nano /etc/ssh/sshd_config |
Procure pela entrada Port. Se estiver comentada, descomente-a. Em seguida, altere o valor para um valor diferente. O valor da porta é um número inteiro de 16 bits sem sinal (0-65535):
|
1 |
Port 1024 |

Salve o arquivo e feche o editor. Para implementar a alteração, reinicie o daemon do SSH:
|
1 |
sudo service ssh restart |
No CentOS/Fedora, execute o seguinte comando em seu lugar:
|
1 |
sudo service sshd restart |
-
Limitação de usuários
Podemos configurar quais contas de usuário podem se conectar usando SSH. Isso também envolve ajustar o sshd_config arquivo. Abra o arquivo com privilégio sudo/root:
|
1 |
sudo nano /etc/ssh/sshd_config |
Procure pela entrada AllowUsers. Adicione os usuários permitidos:
|
1 |
AllowUsers <user_1> <user_2> |

Salve o arquivo e feche o editor. Reinicie o daemon do SSH para que as alterações entrem em vigor:
|
1 |
sudo service ssh restart |
No CentOS/Fedora, execute o seguinte comando em seu lugar:
|
1 |
sudo service sshd restart |
-
Limitação de grupos
Semelhante à limitação de usuários, também podemos determinar qual grupo de usuários pode se conectar ao sistema usando SSH. Abra o sshd_config arquivo:
|
1 |
sudo nano /etc/ssh/sshd_config |
Use a entrada AllowGroups para adicionar um grupo de usuários específico que pode usar o SSH:
|
1 |
AllowGroups <user_group> |

Salve o arquivo e feche o editor. Reinicie o daemon do SSH para que as alterações entrem em vigor:
|
1 |
sudo service ssh restart |
Para CentOS/Fedora, execute o seguinte comando em seu lugar:
|
1 |
sudo service sshd restart |
Observe que se houver algum usuário adicionado ou removido do grupo de usuários, o daemon do SSH precisará ser reiniciado. Caso contrário, as alterações de grupo não entrarão em vigor.
-
Desativando o login de root
Se você tiver acesso a um usuário com privilégios sudo, então é recomendado desativar o login de root via SSH. Abra o sshd_config arquivo:
|
1 |
sudo nano /etc/ssh/sshd_config |
Altere o valor da entrada PermitRootLogin para no:
|
1 |
PermitRootLogin no |

Salve o arquivo e feche o editor. Reinicie o daemon do SSH para que a alteração entre em vigor:
|
1 |
sudo service ssh restart |
No CentOS/Fedora, execute o seguinte comando em seu lugar:
|
1 |
sudo service sshd restart |
-
Encaminhamento de exibições de aplicativos X
O daemon do SSH também pode encaminhar a exibição dos aplicativos X do servidor para o cliente. Para que isso funcione, no entanto, o sistema remoto deve ter um sistema de janelas X configurado. O recurso também precisa ser ativado na configuração do SSH. Abra o arquivo de configuração do SSH:
|
1 |
sudo nano /etc/ssh/sshd_config |
Altere o valor da diretiva X11Forwarding para yes:
|
1 |
X11Forwarding yes |

Salve o arquivo e feche o editor. Reinicie o daemon SSH para que a alteração entre em vigor:
|
1 |
sudo service ssh restart |
No CentOS/Fedora, execute o seguinte comando em seu lugar:
|
1 |
sudo service sshd restart |
Configurações do Cliente
Nesta seção, confira algumas das configurações comuns no cliente SSH.
-
Informações de conexão específicas do servidor
No sistema local, podemos definir as especificidades de uma conexão remota. Todas as informações são armazenadas no arquivo de configuração localizado em ~/.ssh/config:
|
1 |
nano ~/.ssh/config |
Cada bloco de sistema remoto é indicado pela palavra-chave Host seguida por um alias. Todas as diretivas específicas do sistema vão aqui. Ao se conectar ao sistema remoto, o SSH as aplicará automaticamente. Para uma explicação completa e detalhada da configuração, confira a página de manual:
|
1 |
man ssh_config |

A entrada para uma conexão remota seguirá a seguinte estrutura:
|
1 2 3 |
Host <remote_hostname> <directive> <value> |
-
Tempo limite de conexão
Você pode se ver desconectado de sessões SSH antes de estar pronto para realizar qualquer ação. Se o cliente não estiver enviando nenhum pacote para o servidor remoto, após algum tempo, a conexão expira. Para evitar tais circunstâncias, podemos configurar o cliente local para enviar um pacote de vez em quando para manter a conexão ativa.
Abra o arquivo de configuração local:
|
1 |
nano ~/.ssh/config |
Sob a entrada de conexão remota, adicione a diretiva ServerAliveInterval seguida pelo intervalo de pacotes em segundos:
|
1 |
ServerAliveInterval 120 |

Salve o arquivo e feche o editor.
-
Desativando a verificação de host
Por padrão, sempre que tentar se conectar a um novo servidor, o cliente SSH informará a impressão digital do daemon SSH remoto. É um recurso útil para verificar a autenticidade do host. Se um agente malicioso estiver tentando falsificar o host remoto, ele aparecerá como um novo servidor.
Desativar esse recurso pode ser um grande risco de segurança. Geralmente, recomenda-se manter essa opção ativada. Em certas situações, no entanto, desativar a verificação de host pode ser conveniente. Abra o arquivo de configuração:
|
1 |
nano ~/.ssh/config |
Sob a seção do host remoto, adicione as seguintes diretivas:

|
1 2 3 |
StrictHostKeyChecking no UserKnownHostsFile /dev/null |
A primeira diretiva desativará a adição automática de novos hosts à lista de hosts conhecidos, armazenada no arquivo known_hosts. A segunda diretiva serve para não alertar sobre quaisquer alterações. Salve o arquivo e feche o editor.
-
Multiplexação de SSH sobre uma única conexão TCP
Às vezes, estabelecer uma conexão TCP pode exigir bastante tempo. Se for necessário fazer várias conexões com a mesma máquina, a multiplexação é um ótimo recurso do qual você pode tirar proveito. A multiplexação SSH permite usar a mesma conexão TCP para várias sessões SSH. Isso reduz parte da carga de trabalho necessária para estabelecer novas sessões. Limitar o número de conexões também pode ajudar.
Podemos definir manualmente uma conexão multiplexada ou deixar que o SSH a use sempre que estiver disponível. Aqui, configuraremos o SSH para seguir o segundo caminho. Abra o arquivo de configuração do SSH:
|
1 |
nano ~/.ssh/config |
Adicione uma definição de host curinga no topo do arquivo. Isso garante que o próximo conjunto de diretivas será aplicado a todas as conexões remotas. Adicione as seguintes diretivas:
|
1 2 3 4 5 |
ControlMaster auto ControlPath ~/.ssh/multiplex/%r@%h:%p ControlPersist 1 |

A primeira diretiva diz ao SSH para usar a multiplexação automaticamente sempre que estiver disponível. A segunda diretiva estabelece o caminho para o socket de controle. Este socket será criado quando a primeira sessão for estabelecida. As sessões subsequentes seguirão este socket.
A última diretiva diz ao SSH para deixar a conexão mestre inicial em segundo plano. Ela também significa que as conexões TCP terminarão automaticamente um segundo após a última sessão SSH. Em seguida, crie o diretório que declaramos no arquivo de configuração:
|
1 |
mkdir -pv ~/.ssh/multiplex |
Finalmente, a multiplexação deve estar ativa.
Códigos de escape do SSH
Após estabelecer uma conexão, existem maneiras de controlar o comportamento da conexão usando códigos de escape.
-
Forçando desconexões
Você está travado em uma sessão SSH? As sessões SSH geralmente são gerenciadas pelo servidor. Se o servidor estiver enfrentando problemas, ficar travado em uma sessão SSH inativa pode ser frustrante. Felizmente, o OpenSSH oferece controles úteis para gerenciar o estado da conexão a partir do lado do cliente.
Pressione Enter algumas vezes. Em seguida, insira o seguinte comando:
|
1 |
~. |
![]()
Aqui, ~ é o caractere de controle. Após executar este comando a partir do cliente, a conexão deve fechar imediatamente.
-
Sessão SSH em segundo plano
Também podemos colocar uma sessão SSH em segundo plano. Quando colocada em segundo plano, você retornará à sessão normal do shell. Assim que seu trabalho for concluído, você poderá retornar ao shell SSH novamente. Observe que você precisa ter uma configuração de timeout adequada para evitar a expiração do tempo limite enquanto a sessão SSH permanece em segundo plano. Para colocar uma sessão SSH em segundo plano, insira o caractere de controle seguido por Ctrl + Z:
|
1 |
~<Ctrl + Z> |

Se essa foi a sua tarefa em segundo plano mais recente, você pode reativá-la usando o seguinte comando:
|
1 |
fg |
Se houver várias tarefas em segundo plano, podemos determinar a partir da lista de tarefas:
|
1 |
jobs |

Para trazer o job de destino para o primeiro plano, anote o valor do job na primeira coluna. Em seguida, execute o seguinte comando:
|
1 |
fg %<job_value> |
-
Alterando a configuração de redirecionamento de portas
Usando o mecanismo de controle, podemos alterar as regras de redirecionamento de portas dinamicamente. Uma vez estabelecida a conexão, podemos criar ou remover regras de redirecionamento de portas. Isso faz parte da interface de linha de comando do SSH.
Para acessar a interface de linha de comando do SSH, execute o comando:
|
1 |
~C |
![]()
Para listar as opções disponíveis, insira o seguinte comando:
|
1 |
-h |
Se a saída for muito minimalista, tente aumentar o nível de detalhamento usando o seguinte comando de controle:
|
1 |
~v |
Agora, execute o comando -h novamente:
|
1 |
-h |

Como a saída explica, é bastante simples implementar qualquer um dos redirecionamentos de porta com um comando simples. Por exemplo, um túnel também pode ser destruído usando o comando kill, representado por K na lista de comandos.
Considerações Finais
O SSH é bastante comum de se encontrar. É por isso que aprender SSH é muito útil. Nossa visão geral abrangente do SSH cobre as configurações mais importantes do SSH que os usuários precisam saber para usar o SSH no dia a dia. Uma vez dominado, você deve ser capaz de trabalhar com quase todas as configurações de servidor SSH.
Boa computação!
Comentários
Nenhum comentário ainda. Seja o primeiro.