O que é SSH e como ele funciona?

Secure ShO ell (SSH) é um protocolo de segurança comumente implementado com uma variedade de usos diferentes. Sua aplicação mais renomada permite que os usuários acessar com segurança computadores e servidores remotos, mas também pode ser usado para encapsulamento, encaminhamento de porta, transferência segura de arquivos e muito mais.

Neste guia, abordaremos o que é SSH, para que é usado, a história do protocolo, seus detalhes técnicos, assim como o problemas de segurança que precisam ser levados em consideração.

O SSH é composto de três protocolos separados: a camada de transporte, a camada de autenticação e a camada de conexão. Juntos, eles servem para autenticar a outra parte na conexão, fornecer confidencialidade por meio de criptografia e verificar a integridade dos dados. Agora, o SSH é mais comumente implementado como o SSH-2 proprietário ou como a iteração de código aberto, OpenSSH.

Os usos do SSH

SSH é um protocolo versátil. Seus recursos de estrutura e segurança permitem que ele seja usado de várias maneiras, como acesso remoto, encaminhamento de porta, encapsulamento e transferência segura de arquivos.

Acesso remoto

O acesso remoto oferece aos usuários uma maneira de faça login em outro computador ou servidor a partir de sua própria máquina. É usado para acessar os arquivos locais da máquina de destino ou executar serviços nele, tudo sem precisar estar fisicamente lá.

Programas como Telnet e rlogin também possuem essa funcionalidade, mas eles não possuem os recursos de segurança do SSH. As medidas de criptografia e autenticação envolvidas no SSH permitem que os usuários se conectem a outro servidor ou computador de maneira protegida, mesmo em uma rede intermediária potencialmente perigosa.

O acesso remoto com SSH é geralmente implementado para que os funcionários possam trabalhar remotamente ou para permitir que o departamento de TI realize tarefas sem precisar ir fisicamente à máquina. Pode ser usado para administração remota, gerenciamento de infraestrutura de rede, para configurar automação, criar backups e muito mais.

Encaminhamento de porta

O encaminhamento de porta é usado para transferir solicitações de um endereço e número de porta para outro conjunto. Aplica a conversão de endereços de rede (NAT) para redirecionar portas entre uma rede local e um computador remoto, permitindo acessar um dispositivo de fora da rede.

O encaminhamento de porta pode ser feito de três maneiras diferentes:

• Local encaminhamento de porta – O encaminhamento de porta local permite conectar seu cliente local e uma rede externa. Pode ser eficaz para acessar sites bloqueados localmente ou para conectar-se a um banco de dados protegido por um firewall..
• Encaminhamento de porta remota – Esse tipo de encaminhamento permite que aplicativos do servidor acessem serviços no lado do cliente. O encaminhamento de porta remota do SSH permite que os usuários se conectem com segurança a servidores remotos por meio do PC local, redirecionando uma porta local para um servidor SSH remoto.
• Dinâmico encaminhamento de porta – Isso permite que os usuários enviem seus dados através de uma porta específica para um computador ou servidor remoto usando vários servidores SSH que atuam como proxies.

Tunelamento

Os protocolos de encapsulamento usam encapsulamento para mover dados entre redes. Os túneis podem ser implantados para permitir que protocolos não nativos sejam executados em redes que normalmente não os suportariam. Outro uso comum é para fornecendo segurança através de uma rede não segura.

Os protocolos de encapsulamento envolvem pacotes críticos dentro da carga útil de outro pacote. O encapsulamento SSH permite que os usuários contornem a segurança da rede, vinculem dispositivos usando um protocolo de rede não nativo e protejam os dados que estão sendo transmitidos. Eles são freqüentemente usados ​​para conectar usuários remotos aos recursos on-line da organização de maneira segura.

SFTP

O Protocolo de transferência de arquivos SSH (FTP), às vezes conhecido como Protocolo de transferência segura de arquivos, fornece uma maneira segura de acessar, transferir e gerenciar arquivos. É uma alternativa segura ao FTP e utiliza o protocolo SSH para enviar, receber e administrar arquivos com segurança.

SCP

O Protocolo de cópia segura (SCP) é semelhante ao SFTP, mas mais limitado em seu escopo. Ele permite apenas transferências seguras de arquivos, em vez do conjunto completo de recursos que permitem que o SFTP atue como um protocolo de sistema de arquivos remoto.

Plataformas & aplicativos que usam SSH

SSH ou OpenSSH proprietário pode ser usado em todos os principais sistemas operacionais. Está disponível em plataformas baseadas em Unix como OpenBSD, macOS, Linux e Solaris, enquanto os usuários do Windows podem usar SSH através do PowerShell.

A história do SSH

O SSH foi desenvolvido na Universidade de Tecnologia de Helsinque em 1995 por Tatu Ylönen em resposta a um ataque de detecção de senha na rede da universidade. O objetivo era fornecer uma alternativa a protocolos como FTP, TELNET, rsh e rlogin, que não garantiam a confidencialidade ou autenticavam os usuários de maneira segura.

O SSH foi lançado gratuitamente ao público em 1995 e foi bem recebido. Em meio à sua rápida adoção, a Ylönen fundou a SSH Communications Security até o final do mesmo ano para continuar o desenvolvimento e comercializar o SSH.

Em 1995, Ylönen também publicou um Internet Draft Internet Internet Task Force (IETF) que documentou o protocolo SSH-1. Logo, foram encontradas limitações no protocolo, e elas não puderam ser tratadas sem afetar a compatibilidade com versões anteriores. A solução era uma nova versão do protocolo e o SSH-2 foi lançado pela empresa de Ylönen em 1996.

O SSH-2 apresentou novos algoritmos, o que levou a IETF a fundar um grupo de trabalho que visava padronizar o protocolo. O grupo foi apelidado de SECSH, por Secure Shpublicou seu primeiro Internet Draft para SSH-2 em 1997.

O software para SSH-2 foi lançado em 1998, mas não foi imediatamente adotado de forma generalizada por causa de seu licenciamento mais restritivo. Em 2006, uma versão alterada do protocolo foi padronizada pela IETF. Isso era mais seguro, usando códigos de autenticação de mensagens para verificar a integridade e a troca de chaves Diffie-Hellman para autenticação.

Em 1999, o projeto OpenBSD lançou o OpenSSH. OpenSSH é uma versão gratuita do protocolo isso é baseado nas modificações que Björn Grönvall fez no SSH 1.1.12. Os desenvolvedores voltaram para esta versão mais antiga e a alteraram bastante, porque era a última versão do SSH que era completamente de código aberto. O OpenSSH agora é a opção mais amplamente usada e, desde então, foi implementado em vários sistemas operacionais, como Windows, macOS, Linux, Solaris e outros..

SSH-1 vs SSH-2 vs OpenSSH

Como observado acima, o SSH-1 é a primeira versão do protocolo, que foi originalmente lançada sob um licença de código aberto. É considerado inseguro e não deve ser implementado. Isso deixa a versão proprietária, SSH-2, e a versão disponível gratuitamente, OpenSSH, como alternativas viáveis.

SSH-2 e OpenSSH são essencialmente os mesmos quando se trata de sua arquitetura e como eles funcionam. A principal diferença é que a versão proprietária vem com várias opções de suporte, enquanto as que usam o OpenSSH precisam contar com os recursos criados livremente pela comunidade.

SSH: Os detalhes técnicos

O SSH-1 funcionava como um protocolo único, mas não vamos entrar aqui por ser obsoleto. Em vez disso, focaremos o SSH-2 e o OpenSSH, ambos compostos por três protocolos separados:

• O protocolo de transporte – Isso estabelece a conexão e fornece a segurança subjacente.
• O protocolo de autenticação – Essa camada é usada para autenticar o cliente.
• O protocolo de conexão – Este protocolo lida com os canais pelos quais os dados são transmitidos.

Cada um desses protocolos tem uma função exclusiva que trabalha para estabelecer e proteger uma conexão, autenticar a outra parte e transferir dados. A porta de conexão TCP padrão é 22 e as conexões são configuradas entre um cliente SSH e um servidor SSH ao longo do modelo cliente-servidor.

O processo de login remoto do SSH prossegue de acordo com a seguinte estrutura básica (com variações dependendo da configuração), que abordaremos com mais detalhes mais adiante:

• O cliente entra em contato com o servidor SSH para iniciar a conexão.
• O servidor envia sua chave pública ao cliente para autenticar sua identidade..
• As duas partes negociam os parâmetros para a conexão e estabelecem um canal seguro nesse sentido..
• O usuário faz logon no sistema operacional do host do servidor e agora pode administrar suas tarefas remotamente.

Protocolo de transporte

A camada de transporte é um protocolo de baixo nível que cuida das seguintes tarefas.

• Autenticação de host do servidor
• Troca de chaves
• Criptografia para confidencialidade dos dados
• Verificações de integridade para verificar se os dados não foram alterados
• Estabelecendo um ID de Sessão que Pode Ser Usado nos Outros Protocolos

o protocolo de transporte autentica apenas o servidor e não o cliente (a autenticação do cliente é feita no protocolo de autenticação, se necessário).

Na camada de transporte, a conexão é iniciada pelo cliente e as duas partes negociam como as chaves serão trocadas, qual algoritmo de chave pública será usado, qual cifra de chave simétrica criptografará os dados, qual algoritmo de autenticação de mensagem será usado para verificar os dados e qual método de compactação (se houver) será implementado.

Depois que a conexão começa, o servidor e o cliente precisam enviar uma cadeia de identificação, que inclui a versão do protocolo (2.0).

Negociação de algoritmos

Para configurar os parâmetros da conexão, os dois lados enviam um pacote contendo uma lista com as seguintes opções:

byte SSH_MSG_KEXINIT

cookie de byte [16] (bytes aleatórios)
lista de nomes kex_algorithms
lista de nomes server_host_key_algorithms
encryption_algorithms_client_to_server da lista de nomes
encryption_algorithms_server_to_client da lista de nomes
lista de nomes mac_algorithms_client_to_server
lista de nomes mac_algorithms_server_to_client
lista de nomespression_algorithms_client_to_server
nome-listapression_algorithms_server_to_client
lista de nomes languages_client_to_server
nome da lista languages_server_to_client
booleano first_kex_packet_follows
uint32 0 (reservado para futura extensão)

Cada lado lista os parâmetros que eles desejam aceitar na conexão, separados por vírgulas. O algoritmo preferido deve ser listado primeiro.

Para troca de chaves (kex_algorithms), o primeiro algoritmo suportado por ambas as partes será escolhido para a conexão (também pode haver outros fatores que precisam ser atendidos, dependendo do algoritmo escolhido). Se as duas partes não conseguirem encontrar um algoritmo com suporte mútuo que atenda a esses requisitos, a conexão falhará.

Algoritmos de chave do host do servidor são os algoritmos suportados para a chave do host do servidor. O servidor estabelece os algoritmos para os quais possui chaves de host, enquanto o cliente especifica os algoritmos que está preparado para aceitar. A seleção dependerá se o método de troca de chaves adotado exige uma chave de host com capacidade de criptografia ou uma assinatura digital

Ambos os lados listam os algoritmos de chave simétrica que eles estão dispostos a aceitar, com os métodos preferidos no topo. A primeira opção a aparecer na lista do cliente que também está na lista do servidor deve ser usada. Se nenhum acordo puder ser feito, a conexão falhará.

Tanto o Algoritmo MAC e a algoritmo de compressão são negociados da mesma maneira.

Troca de chaves

A troca de chaves é responsável por autenticação de servidor, e isso configura as chaves que serão usadas para proteger a conexão nas etapas a seguir. Geralmente começa com as partes enviando suas listas de algoritmos suportados entre si. Como alternativa, cada lado pode adivinhar o algoritmo preferido do outro lado e enviar um pacote que se encaixa nos parâmetros desse algoritmo no início.

Se a suposição de uma parte estiver correta, esse pacote será usado como o primeiro pacote de troca de chaves. Se nenhum dos palpites estiver certo, cada lado deverá dar um passo atrás e enviar suas listas de algoritmos preferidos. Se a mensagem de troca de chaves incluir a assinatura digital do servidor como prova da legitimidade do servidor, ela será considerada autenticação explícita do servidor. Se, em vez disso, usar o segredo compartilhado, será chamado de autenticação implícita do servidor.

A troca de chaves também é responsável por estabelecer um segredo compartilhado e um hash. O valor do hash da troca inicial de chaves se torna o identificador exclusivo da sessão e também é usado como parte das assinaturas digitais que provam que a parte é o verdadeiro proprietário de sua chave privada.

A função de hash usada dependerá do método de troca de chaves decidido na negociação. Quando a troca de chaves estiver concluída, todas as comunicações futuras usarão o novo conjunto de chaves e algoritmos.

De acordo com um rascunho da Internet da Internet Engineering Task Force (IETF), os seguintes métodos de troca de chave são considerados seguros:

• curve25519-sha256
• curve448-sha512
• diffie-hellman-grupo-troca-sha256
• O que outras pessoas estão dizendo
• diffie-hellman-group15-sha512
• diffie-hellman-group16-sha512
• diffie-hellman-group17-sha512
• diffie-hellman-group18-sha512
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• gss-group14-sha256
• gss-group15-sha512
• gss-group16-sha512
• gss-group17-sha512
• gss-group18-sha512
• gss-nistp256-sha256
• gss-nistp384-sha384
• gss-nistp521-sha512
• gss-curve25519-sha256
• gss-curve448-sha512
• rsa2048-sha256

Algoritmo de chave do host do servidor

Esses algoritmos de chave pública são usados ​​para autenticação do servidor, bem como estabelecer com segurança o ID da sessão compartilhada. Eles também podem ser usados ​​opcionalmente para autenticar o host. O SSH foi projetado para funcionar com uma variedade de algoritmos de chave pública, tipos e formatos de codificação:

• Ele usa algoritmos de chave pública para criptografia e / ou assinaturas digitais.
• Uma variedade de métodos de codificação pode ser implementada, permitindo a configuração com diferentes formatos de dados, preenchimento e ordem de bytes.
• Vários formatos de chave permitem que as chaves sejam codificadas de maneiras diferentes, bem como uma variedade de representações de certificados.

Os algoritmos padrão incluem o seguinte, no entanto, existem outras variações que também podem ser implementadas:

• ssh-rsa
• ssh-rsa-sha256
• ssh-dss
• ssh-dss-sha256
• x509v3-sign-dss
• x509v3-sign-dss-sha256
• x509v3-sign-rsa
• x509v3-sign-rsa-sha256

Algoritmos de criptografia

Os algoritmos de chave simétrica são usados ​​para criptografar os dados e fornecer confidencialidade. Os parâmetros e a chave compartilhada usados ​​no processo de criptografia são estabelecidos nas fases anteriores da conexão. O algoritmo escolhido criptografa a carga útil, o comprimento do pacote, o comprimento do preenchimento e os campos do preenchimento.

Uma variedade de algoritmos de criptografia diferentes são aceitos no SSH, mas por motivos de segurança, é melhor manter o AES. As chaves devem ter no mínimo 128 bits, mas são preferidas chaves maiores.

Algoritmos MAC

O protocolo de transporte verifica a integridade dos dados adicionando um código de autenticação de mensagem (MAC) ao pacote. Este MAC é baseado no segredo compartilhado (estabelecido na troca de chaves), no número de sequência do pacote e no conteúdo do pacote. É calculado antes da criptografia.

As implementações precisam oferecer um algoritmo independente para executar em cada direção, embora seja ideal se o mesmo for usado nos dois lados. Uma grande variedade de algoritmos de autenticação de mensagens pode ser implementada; no entanto, o SHA-256 e superior devem ser usados ​​na maioria das situações para garantir um alto nível de segurança.

Compressão

A compactação não é obrigatória no protocolo SSH e suas implementações devem permitir que as conexões continuem sem compactação. A compactação só pode ser implementada como uma opção, usando esquemas como zlib. Se a compactação for usada, ela afetará apenas a carga útil. O MAC e o campo de comprimento do pacote são calculados com base na carga útil compactada.

Pacote do protocolo de transporte

O pacote do protocolo de transporte está formatado para incluir as seguintes informações (além de alguns detalhes menos pertinentes que foram deixados de fora):

• O comprimento do pacote
• O comprimento do estofamento
• A carga útil
• Preenchimento
• Um código de autenticação de mensagem (MAC)

Protocolo de autenticação

Este protocolo é usado pelo servidor para autenticar o cliente. Isso pode ser feito com uma variedade de mecanismos diferentes, muitos dos quais contam com o ID da sessão estabelecido no protocolo de transporte. Alguns usam as verificações de criptografia e integridade do protocolo de transporte em conjunto com o ID da sessão, enquanto outros usam esses algoritmos sozinhos.

O servidor usa sua política local para decidir quais métodos de autenticação ele aceita de um usuário individual. Como o servidor já foi autenticado no protocolo de transporte, não há necessidade de autenticar o servidor mais uma vez.

A segurança do protocolo de autenticação depende do protocolo de transporte em que é executado na parte superior. Se o protocolo de transporte não puder garantir a confidencialidade ou verificar a integridade dos dados, isso limitará como o protocolo de autenticação pode ser usado com segurança.

Por exemplo, se a proteção de integridade não está sendo aplicada pelo protocolo de transporte, solicitações como alterações de senha não devem ser permitidas, pois isso deixaria oportunidades para os invasores violarem os dados sem serem notados..

O protocolo de autenticação usa autenticação de chave pública sob o pressuposto de que nem a chave privada do host do servidor nem a chave do host do cliente foram comprometidas. Se o servidor tiver sido comprometido, isso poderá levar o nome de usuário e a senha do cliente a serem liberados para o invasor..

Para que a autenticação baseada em host seja segura, o cliente não deve ser comprometido. Se for possível, outros métodos de autenticação devem ser adicionados. É importante notar que o processo de autenticação é tão forte quanto o método de troca mais fraco que um servidor aceita.

O processo do protocolo de autenticação

O protocolo de autenticação começa quando o servidor envia ao cliente uma lista de seus métodos de autenticação aceitos. O cliente pode escolher entre esses métodos em qualquer ordem. Esse processo dá controle ao servidor, mas também permite flexibilidade suficiente para que o cliente possa organizar o uso do método mais conveniente.

Os métodos mais comuns de autenticação de cliente incluem:

• Chave pública – Este método usa algoritmos como RSA, DSA e ECDSA para autenticar o cliente por meio de criptografia de chave pública. Algumas implementações também usam certificados x.509. O servidor verifica a assinatura digital do cliente com sua chave pública para verificar a identidade do cliente.
• Senha – Senhas também podem ser usadas para autenticar o cliente. O cliente envia através de sua senha (que deve ser criptografada pelo protocolo de transporte). Se a senha corresponder ao valor armazenado do servidor, ela será aceita e a autenticação avançará.
• GSSAPI – Sob esse método, esquemas externos como o Kerberos podem ser usados ​​para logon único.
• Teclado interativo – Essa técnica fornece autenticação de senha única, solicitando ao servidor informações sobre o cliente.

Protocolo de conexão

O protocolo de conexão estabelece como vários canais de dados serão combinados na camada de transporte seguro. Ele também lida com os parâmetros usados ​​para acessar subsistemas seguros no host do servidor, bem como encaminhamento de proxy e acesso a shells..

O protocolo de conexão fica na parte superior da camada de transporte e dos protocolos de autenticação. Permite a execução remota de comandos, bem como as conexões X11 e TCP / IP encaminhadas. Se o servidor ou o cliente foram comprometidos, o protocolo de conexão não é seguro.

Canais

Canais são os caminhos básicos de comunicação e podem ser abertos por qualquer uma das partes. Os canais podem incluir sessões de terminal, conexões encaminhadas e outras formas de comunicação. Quando existem vários canais, eles são multiplexados em uma conexão.

Abrindo canais

Cada canal é numerado nas duas extremidades, embora os números possam ser diferentes em ambos os lados. Quando um lado solicita a abertura de um canal, ele envia o número do canal como parte da mensagem, além de informações sobre o tamanho inicial da janela e a tamanho máximo do pacote.

O tamanho inicial da janela indica quantos dados a parte que abre o canal pode receber. Se mais dados precisarem ser enviados, a janela deverá ser ajustada primeiro. Da mesma forma, o tamanho máximo do pacote especifica o tamanho do pacote que pode ser recebido.

Quando um lado solicita que um canal seja aberto, o outro lado abrirá o canal, se puder acomodá-lo. Caso contrário, ele enviará uma mensagem de falha. Os canais podem falhar ao serem abertos pelos seguintes motivos:

• Proibido pela administração
• Falha na conexão
• Tipo de canal desconhecido
• Escassez de recursos

Se um dos lados da conexão quiser enviar mais dados do que a janela atualmente permite, eles poderão enviar uma mensagem solicitando a adição de mais bytes.

Canais de fechamento

Depois que um lado de uma conexão concluir sua transmissão de dados, ele deverá enviar uma mensagem indicando que terminou de usar o canal. Apesar disso, o canal é mantido aberto e os dados ainda podem ser enviados pela outra parte. Se uma parte quiser encerrar completamente o canal, ele fará isso com uma mensagem de encerramento separada.

Segurança SSH

As várias versões do SSH tiveram seus próprios problemas de segurança, embora as configurações atuais do SSH-2 e OpenSSH são considerados muito mais seguros que SSH-1.

SSH-1

O SSH-1 é geralmente considerado defeituoso, com várias vulnerabilidades diferentes. Isso inclui um bug no SSH 1.5 que permitia que usuários não autorizados inserissem conteúdo no fluxo de dados do SSH. Esse ataque aproveitou a proteção mínima de integridade de dados do algoritmo CRC-32.

Esse ataque foi atenuado com o SSH Compensation Attack Detector, que foi integrado à maioria das implementações mais recentes. Essa correção veio com uma nova vulnerabilidade, que tinha o poder de executar código arbitrário com privilégios de root.

Há também uma vulnerabilidade que permite que os adversários alterem o último bloco em uma sessão que usa criptografia IDEA, bem como uma que permite que um servidor comprometido encaminhe o processo de autenticação do cliente para um servidor diferente.

Devido a esses problemas de segurança, o SSH-2 deve ser usado. Para manter sua implementação segura, você também deve desativar a renegociação para SSH-1, porque os ataques podem tirar proveito disso para acessar seus dados pelo nível mais baixo de proteção do SSH-1.

SSH-2

O SSH-2 é vulnerável a um ataque teórico contra seu modo padrão de criptografia, o CBC. Ele permite que o invasor recupere até 32 bits do texto sem formatação de um bloco criptografado. Isso pode ser atenuado usando o modo Contador (CTR) e transformando a cifra de bloco em uma cifra de fluxo..

No final de 2014, Der Spiegel divulgou documentos da NSA que implicavam que a NSA às vezes poderia quebrar o SSH. Este PowerPoint vazado da NSA afirma que a NSA pode “Potencialmente recuperar nomes de usuário e senhas”, Embora não sejam fornecidos mais detalhes. Não se sabe quais métodos a agência usou para fazer isso, mas parece improvável que ela mentiria sobre seus recursos em sua própria documentação interna.

No vazamento do Vault 7 de 2023, foi revelado que a CIA tinha duas ferramentas que poderiam ser usadas para interceptar e roubar logins e senhas SSH. O BothanSpy direcionou os clientes Windows Xshell, enquanto Gyrfalcon foi usado contra o cliente OpenSSH em várias distribuições Linux diferentes.

Essas ferramentas são capazes de roubar credenciais e depois transmiti-las para um servidor da CIA. Nenhum desses ataques pode quebrar o próprio protocolo; eles apenas usam outros ataques de canal lateral que podem contornar isso em certas implementações.

Apesar desses ataques, o SSH-2 é considerado seguro na maioria das situações, desde que seja implementado adequadamente. Alvos de alto valor ou aqueles que usam implementações desatualizadas ou ruins devem considerar outras opções.

OpenSSH

Na versão 2 do OpenSSH, Foi descoberto um ataque que aproveitou uma fraqueza no pacote binário SSH. O ataque permitiu que pesquisadores da Universidade de Londres recuperassem 14 bits do texto sem formatação de um bloco criptografado. Isso foi atenuado na liberação 5.2, fazendo o protocolo ler toda a extensão de um pacote inválido ou código de autenticação de mensagem, em vez de encerrar a conexão.

Nas versões 6.8 e 6.9, o Linux poderia ser usado para executar comandos arbitrários nos terminais de outros usuários. Isso foi realizado através de uma vulnerabilidade de escalonamento de privilégios que permitia que invasores injetassem caracteres com o controle de entrada / saída TIOCSTI.

SSH é seguro?

Embora possa parecer que o SSH tenha muitos problemas de segurança, é relatively normal que várias vulnerabilidades sejam encontradas nas várias implementações de um protocolo. Isso não significa que o protocolo SSH não seja seguro. Em vez disso, significa apenas que precisa ser implementado corretamente.

Contanto que você esteja usando SSH-2 ou OpenSSH e está configurado de maneira apropriada para seu uso, você deve se sentir confiante na proteção que o SSH fornece à sua conexão. É por isso que ainda é um protocolo usado com frequência, especialmente para fins de acesso remoto e encapsulamento.

Consulte também: Tipos comuns de criptografia explicados

Fundo de tecnologia de rede cibernética por TheDigitalArtist licenciado sob CC0