Capsula segura

O Secure Shell Protocol (SSH) é um protocolo de rede criptográfico para operar serviços de rede com segurança em uma rede não segura. Suas aplicações mais notáveis são login remoto e execução de linha de comando.

As aplicações SSH são baseadas em uma arquitetura cliente-servidor, conectando uma instância de cliente SSH a um servidor SSH. O SSH opera como um conjunto de protocolos em camadas que compreende três componentes hierárquicos principais: a camada de transporte fornece autenticação, confidencialidade e integridade do servidor; o protocolo de autenticação do usuário valida o usuário no servidor; e o protocolo de conexão multiplexa o túnel criptografado em vários canais de comunicação lógica.

O SSH foi projetado em sistemas operacionais do tipo Unix, como um substituto para o Telnet e para protocolos de shell Unix remotos inseguros, como o Berkeley Remote Shell (rsh) e os protocolos rlogin e rexec relacionados, que usam transmissão de texto simples e insegura. de tokens de autenticação.

O SSH foi projetado pela primeira vez em 1995 pelo cientista da computação finlandês Tatu Ylönen. O desenvolvimento subsequente do conjunto de protocolos ocorreu em vários grupos de desenvolvedores, produzindo diversas variantes de implementação. A especificação do protocolo distingue duas versões principais, denominadas SSH-1 e SSH-2. A pilha de software mais comumente implementada é o OpenSSH, lançado em 1999 como software de código aberto pelos desenvolvedores do OpenBSD. As implementações são distribuídas para todos os tipos de sistemas operacionais de uso comum, incluindo sistemas embarcados.

Definição

SSH usa criptografia de chave pública para autenticar o computador remoto e permitir que ele autentique o usuário, se necessário.

SSH pode ser usado em diversas metodologias. Da maneira mais simples, ambas as extremidades de um canal de comunicação usam pares de chaves pública-privada gerados automaticamente para criptografar uma conexão de rede e, em seguida, usam uma senha para autenticar o usuário.

Quando o par de chaves pública-privada é gerado manualmente pelo usuário, a autenticação é essencialmente realizada quando o par de chaves é criado, e uma sessão pode então ser aberta automaticamente sem solicitação de senha. Neste cenário, a chave pública é colocada em todos os computadores que devem permitir acesso ao proprietário da chave privada correspondente, que o proprietário mantém privada. Embora a autenticação seja baseada na chave privada, a chave nunca é transferida pela rede durante a autenticação. O SSH verifica apenas se a mesma pessoa que oferece a chave pública também possui a chave privada correspondente.

Em todas as versões do SSH é importante verificar chaves públicas desconhecidas, ou seja, associar as chaves públicas a identidades, antes de aceitá-las como válidas. Aceitar a chave pública de um invasor sem validação autorizará um invasor não autorizado como um usuário válido.

Autenticação: gerenciamento de chaves OpenSSH

Em sistemas do tipo Unix, a lista de chaves públicas autorizadas normalmente é armazenada no diretório inicial do usuário que tem permissão para efetuar login remotamente, no arquivo ~/.ssh/authorized_keys. Este arquivo é respeitado pelo SSH somente se não for gravável por ninguém além do proprietário e do root. Quando a chave pública está presente na extremidade remota e a chave privada correspondente está presente na extremidade local, não é mais necessário digitar a senha. No entanto, para segurança adicional, a própria chave privada pode ser bloqueada com uma senha.

A chave privada também pode ser procurada em locais padrão, e seu caminho completo pode ser especificado como uma configuração de linha de comando (a opção -i para ssh). O utilitário ssh-keygen produz as chaves pública e privada, sempre em pares.

O SSH também oferece suporte à autenticação baseada em senha, criptografada por chaves geradas automaticamente. Nesse caso, o invasor poderia imitar o lado legítimo do servidor, solicitar a senha e obtê-la (ataque man-in-the-middle). No entanto, isso só é possível se os dois lados nunca tiverem autenticado antes, pois o SSH lembra a chave que o lado do servidor usou anteriormente. O cliente SSH gera um aviso antes de aceitar a chave de um servidor novo e anteriormente desconhecido. A autenticação por senha pode ser desabilitada no lado do servidor.

Usar

SSH normalmente é usado para fazer login em uma máquina remota e executar comandos, mas também suporta tunelamento, encaminhamento de portas TCP e conexões X11; ele pode transferir arquivos usando os protocolos associados de transferência de arquivos SSH (SFTP) ou cópia segura (SCP). SSH usa o modelo cliente-servidor.

Um programa cliente SSH normalmente é usado para estabelecer conexões com um daemon SSH, como sshd, aceitando conexões remotas. Ambos estão comumente presentes na maioria dos sistemas operacionais modernos, incluindo macOS, a maioria das distribuições de Linux, OpenBSD, FreeBSD, NetBSD, Solaris e OpenVMS. Notavelmente, as versões do Windows anteriores ao Windows 10 versão 1709 não incluem SSH por padrão. Existem versões proprietárias, freeware e de código aberto (por exemplo, PuTTY e a versão do OpenSSH que faz parte do Cygwin) de vários níveis de complexidade e integridade. Os gerenciadores de arquivos para sistemas do tipo UNIX (por exemplo, Konqueror) podem usar o protocolo FISH para fornecer uma GUI de painel dividido com arrastar e soltar. O programa de código aberto do Windows WinSCP fornece capacidade semelhante de gerenciamento de arquivos (sincronização, cópia, exclusão remota) usando PuTTY como back-end. Tanto o WinSCP quanto o PuTTY estão disponíveis em pacotes para serem executados diretamente em uma unidade USB, sem exigir instalação na máquina cliente. A extensão de shell seguro para o navegador Chrome também permite conexões SSH sem qualquer instalação de software e até permite SSH de um computador Chromebook. A configuração de um servidor SSH no Windows normalmente envolve a ativação de um recurso no aplicativo Configurações. No Windows 10 versão 1709, uma porta Win32 oficial do OpenSSH está disponível.

O SSH é importante na computação em nuvem para resolver problemas de conectividade, evitando os problemas de segurança de expor uma máquina virtual baseada em nuvem diretamente na Internet. Um túnel SSH pode fornecer um caminho seguro pela Internet, através de um firewall, para uma máquina virtual.

A IANA atribuiu a porta TCP 22, a porta UDP 22 e a porta SCTP 22 para este protocolo. A IANA listou a porta TCP 22 padrão para servidores SSH como uma das portas mais conhecidas já em 2001. O SSH também pode ser executado usando SCTP em vez de TCP como protocolo da camada de transporte orientado à conexão.

Desenvolvimento histórico

Versão 1

Em 1995, Tatu Ylönen, pesquisador da Universidade de Tecnologia de Helsinque, na Finlândia, projetou a primeira versão do protocolo (agora chamado de SSH-1) solicitado por um ataque de detecção de senha em sua rede universitária. O objetivo do SSH era substituir os protocolos anteriores rlogin, TELNET, FTP e rsh, que não forneciam autenticação forte nem garantiam confidencialidade. Ylönen lançou sua implementação como freeware em julho de 1995, e a ferramenta rapidamente ganhou popularidade. No final de 1995, a base de usuários SSH cresceu para 20000 usuários em cinquenta países.

Em dezembro de 1995, Ylönen fundou a SSH Communications Security para comercializar e desenvolver o SSH. A versão original do software SSH usava vários softwares livres, como GNU libgmp, mas versões posteriores lançadas pela SSH Communications Security evoluíram para software cada vez mais proprietário.

Estimava-se que em 2000 o número de usuários havia crescido para 2 milhões.

Versão 2

"Secsh" era o nome oficial da Internet Engineering Task Force (IETF) para o grupo de trabalho da IETF responsável pela versão 2 do protocolo SSH. Em 2006, uma versão revisada do protocolo, SSH-2, foi adotada como padrão. Esta versão é incompatível com SSH-1. O SSH-2 apresenta melhorias de segurança e recursos em relação ao SSH-1. Melhor segurança, por exemplo, vem através da troca de chaves Diffie-Hellman e da forte verificação de integridade por meio de códigos de autenticação de mensagens. Os novos recursos do SSH-2 incluem a capacidade de executar qualquer número de sessões de shell em uma única conexão SSH. Devido à superioridade e popularidade do SSH-2 sobre o SSH-1, algumas implementações como libssh (v0.8.0+), Lsh e Dropbear suportam apenas o protocolo SSH-2.

Versão 1.99

Em janeiro de 2006, bem depois da versão 2.1 ter sido estabelecida, a RFC 4253 especificou que um servidor SSH que suportasse 2.0, bem como versões anteriores, deveria identificar sua versão de protocolo como 1.99. Este número de versão não reflete uma revisão histórica do software, mas um método para identificar a compatibilidade com versões anteriores.

OpenSSH e OSSH

Em 1999, os desenvolvedores, desejando a disponibilidade de uma versão de software livre, reiniciaram o desenvolvimento de software a partir da versão 1.2.12 do programa SSH original, que foi o último lançado sob uma licença de código aberto. Isso serviu como base de código para o software OSSH de Björn Grönvall. Pouco tempo depois, os desenvolvedores do OpenBSD bifurcaram o código de Grönvall e criaram o OpenSSH, que acompanha a versão 2.6 do OpenBSD. A partir desta versão, uma "portabilidade" branch foi formada para portar o OpenSSH para outros sistemas operacionais.

Em 2005, o OpenSSH era a implementação SSH mais popular, sendo a versão padrão em um grande número de distribuições de sistemas operacionais. Enquanto isso, o OSSH tornou-se obsoleto. O OpenSSH continua a ser mantido e oferece suporte ao protocolo SSH-2, tendo eliminado o suporte SSH-1 da base de código na versão OpenSSH 7.6.

Usos

SSH é um protocolo que pode ser usado para muitos aplicativos em muitas plataformas, incluindo a maioria das variantes do Unix (Linux, os BSDs, incluindo o macOS da Apple e o Solaris), bem como o Microsoft Windows. Alguns dos aplicativos abaixo podem exigir recursos disponíveis ou compatíveis apenas com clientes ou servidores SSH específicos. Por exemplo, é possível usar o protocolo SSH para implementar uma VPN, mas atualmente apenas com a implementação de servidor e cliente OpenSSH.

• Para login em um shell em um host remoto (replacando Telnet e rlogin)
• Para executar um único comando em um host remoto (replacando rsh)
• Para configurar o login automático (passwordless) para um servidor remoto (por exemplo, usando o OpenSSH)
• Em combinação com rsync para fazer backup, copiar e espelhar arquivos de forma eficiente e segura
• Para encaminhar uma porta
• Para túneis (não confundir-se com uma VPN, que rota pacotes entre redes diferentes ou pontes dois domínios de transmissão em um).
• Para usar como uma VPN criptografada com pleno direito. Note que apenas o servidor OpenSSH e o cliente suportam este recurso.
• Para encaminhar X de um host remoto (possível através de vários hosts intermediários)
• Para navegar na web através de uma conexão proxy criptografada com clientes SSH que suportam o protocolo SOCKS.
• Para montar com segurança um diretório em um servidor remoto como um sistema de arquivos em um computador local usando SSHFS.
• Para monitoramento remoto automatizado e gerenciamento de servidores através de um ou mais dos mecanismos discutidos acima.
• Para o desenvolvimento em um dispositivo móvel ou incorporado que suporta SSH.
• Para garantir protocolos de transferência de arquivos.

Protocolos de transferência de arquivos

Os protocolos Secure Shell são usados em vários mecanismos de transferência de arquivos.

• Cópia segura (SCP), que evoluiu do protocolo RCP sobre SSH
• rsync, destinado a ser mais eficiente do que SCP. Geralmente é executado através de uma conexão SSH.
• SSH File Transfer Protocol (SFTP), uma alternativa segura para FTP (não confundir com FTP sobre SSH ou FTPS)
• Arquivos transferidos sobre protocolo shell (FISH), lançado em 1998, que evoluiu de comandos Unix shell sobre SSH
• Protocolo rápido e seguro (FASP), aka Aspera, usa SSH para controle e portas UDP para transferência de dados.

Arquitetura

O protocolo SSH possui uma arquitetura em camadas com três componentes separados:

• O camada de transporte (RFC 4253) normalmente usa o Protocolo de Controle de Transmissão (TCP) de TCP/IP, reservando a porta número 22 como uma porta de escuta do servidor. Esta camada lida com a troca de chaves inicial, bem como a autenticação do servidor e configura criptografia, compressão e verificação de integridade. Ele expõe à camada superior uma interface para enviar e receber pacotes de texto simples com um tamanho de até 32.768 bytes cada, mas mais pode ser permitido por cada implementação. A camada de transporte também providencia a troca de chaves, geralmente após 1 GB de dados ter sido transferida ou após uma hora ter passado, o que ocorrer primeiro.
• O camada de autenticação do usuário (RFC 4252) lida com a autenticação do cliente e fornece um conjunto de algoritmos de autenticação. Autenticação é orientado para o cliente: quando um é solicitado para uma senha, pode ser o cliente SSH solicitando, não o servidor. O servidor apenas responde aos pedidos de autenticação do cliente. Métodos de autenticação de usuário amplamente utilizados incluem o seguinte:
  • senha: um método para autenticação de senha simples, incluindo uma instalação que permite que uma senha seja alterada. Nem todos os programas implementam este método.
  • chave pública: um método para autenticação baseada em chave pública, geralmente suportando pelo menos DSA, ECDSA ou RSA keypairs, com outras implementações também suportando certificados X.509.
  • teclado-interativo (RFC 4256): um método versátil onde o servidor envia um ou mais prompts para inserir informações e o cliente os exibe e envia respostas de volta chaveadas pelo usuário. Usado para fornecer autenticação de senha única, como S/Key ou SecurID. Usado por algumas configurações do OpenSSH quando o PAM é o provedor de autenticação de host subjacente para fornecer efetivamente a autenticação de senha, às vezes levando à incapacidade de fazer login com um cliente que suporta apenas a planície senha método de autenticação.
  • Métodos de autenticação GSSAPI que fornecem um esquema extensível para executar a autenticação SSH usando mecanismos externos, como Kerberos 5 ou NTLM, fornecendo uma única capacidade de login para sessões SSH. Esses métodos são geralmente implementados por implementações comerciais de SSH para uso em organizações, embora o OpenSSH tenha uma implementação de GSSAPI trabalhando.
• O camada de conexão (RFC 4254) define o conceito de canais, solicitações de canais e solicitações globais, que definem os serviços SSH fornecidos. Uma única conexão SSH pode ser multiplexada em vários canais lógicos simultaneamente, cada transferência de dados bidirecionalmente. Os pedidos de canal são usados para transmitir dados específicos do canal fora de banda, como o tamanho alterado de uma janela terminal, ou o código de saída de um processo do lado do servidor. Além disso, cada canal executa seu próprio controle de fluxo usando o tamanho da janela de recebimento. O cliente SSH solicita que uma porta do lado do servidor seja encaminhada usando uma solicitação global. Tipos de canal padrão incluem:
  • shell para conchas terminais, solicitações SFTP e exec (incluindo transferências de SCP)
  • direto-tcpip para conexões encaminhadas cliente-servidor
  • encaminhado-tcpip para conexões de servidor a cliente
• O registro DNS SSHFP (RFC 4255) fornece as impressões digitais de chaves de host públicas para ajudar na verificação da autenticidade do host.

Essa arquitetura aberta oferece flexibilidade considerável, permitindo o uso de SSH para diversas finalidades além de um shell seguro. A funcionalidade da camada de transporte por si só é comparável à Transport Layer Security (TLS); a camada de autenticação do usuário é altamente extensível com métodos de autenticação personalizados; e a camada de conexão fornece a capacidade de multiplexar muitas sessões secundárias em uma única conexão SSH, um recurso comparável ao BEEP e não disponível em TLS.

Algoritmos

• EdDSA, ECDSA, RSA e DSA para criptografia de chaves públicas.
• ECDH e Diffie–Hellman para troca de chaves.
• HMAC, AEAD e UMAC para MAC.
• AES (e deprecated RC4, 3DES, DES) para criptografia simétrica.
• AES-GCM e ChaCha20-Poly1305 para criptografia AEAD.
• SHA (e deprecated MD5) para impressão digital chave.

Vulnerabilidades

SSH-1

Em 1998, foi descrita uma vulnerabilidade no SSH 1.5 que permitia a inserção não autorizada de conteúdo em um fluxo SSH criptografado devido à proteção insuficiente da integridade dos dados do CRC-32 usado nesta versão do protocolo. Uma correção conhecida como Detector de Ataque de Compensação SSH foi introduzida na maioria das implementações. Muitas dessas implementações atualizadas continham uma nova vulnerabilidade de estouro de número inteiro que permitia aos invasores executar código arbitrário com os privilégios do daemon SSH, normalmente root.

Em janeiro de 2001 foi descoberta uma vulnerabilidade que permite que invasores modifiquem o último bloco de uma sessão criptografada por IDEA. No mesmo mês, foi descoberta outra vulnerabilidade que permitia que um servidor malicioso encaminhasse a autenticação de um cliente para outro servidor.

Como o SSH-1 tem falhas de design inerentes que o tornam vulnerável, ele agora é geralmente considerado obsoleto e deve ser evitado desabilitando explicitamente o substituto para o SSH-1. A maioria dos servidores e clientes modernos oferece suporte a SSH-2.

Recuperação de texto simples CBC

Em novembro de 2008, foi descoberta uma vulnerabilidade teórica para todas as versões do SSH que permitia a recuperação de até 32 bits de texto simples de um bloco de texto cifrado criptografado usando o que era então o modo de criptografia padrão, CBC. A solução mais direta é usar CTR, modo contador, em vez do modo CBC, pois isso torna o SSH resistente ao ataque.

Suspeita de descriptografia pela NSA

Em 28 de dezembro de 2014, o Der Spiegel publicou informações confidenciais vazadas pelo denunciante Edward Snowden, o que sugere que a Agência de Segurança Nacional pode ser capaz de descriptografar parte do tráfego SSH. Os detalhes técnicos associados a tal processo não foram divulgados. Uma análise de 2017 das ferramentas de hacking da CIA BothanSpy e Gyrfalcon sugeriu que o protocolo SSH não foi comprometido.

Documentação de padrões

As seguintes publicações RFC da IETF "secsh" documento do grupo de trabalho SSH-2 como um padrão de Internet proposto.

• RFC 4250 – O protocolo Secure Shell (SSH) Números atribuídos
• RFC 4251 – The Secure Shell (SSH) Protocol Architecture
• RFC 4252 – O protocolo de autenticação Secure Shell (SSH)
• RFC 4253 – O Shell seguro (SSH) Protocolo de camada de transporte
• RFC 4254 – O protocolo de conexão Secure Shell (SSH)
• RFC 4255 – Usando DNS para Publicar Seguramente o Shell Seguro (SSH) Chave impressões digitais
• RFC 4256 – Autenticação de Intercâmbio de Mensagens Genéricas para o Protocolo de Shell Seguro (SSH)
• RFC 4335 – The Secure Shell (SSH) Session Channel Break Extension
• RFC 4344 – O Shell seguro (SSH) modos de criptografia de camada de transporte
• RFC 4345 – Modos Arcfour melhorados para o protocolo de camada de transporte seguro Shell (SSH)

As especificações do protocolo foram posteriormente atualizadas pelas seguintes publicações:

• RFC 4419 – Troca de Grupo Diffie-Hellman para o protocolo de camada de transporte seguro Shell (SSH) (Março de 2006)
• RFC 4432 – RSA Troca de chaves para o protocolo de camada de transporte seguro Shell (SSH) (Março de 2006)
• RFC 4462 – Interface do Programa de Aplicação de Serviço de Segurança Genérico (GSS-API) Autenticação e troca de chaves para o protocolo Secure Shell (SSH) (Maio de 2006)
• RFC 4716 – The Secure Shell (SSH) Public Formato de arquivo chave (novembro de 2006)
• RFC 4819 – Seguro Shell Public Subsistema chave (Março de 2007)
• RFC 5647 – Modo de Contador AES Galois para o Protocolo de Camada de Transporte de Shell Seguro (Agosto de 2009)
• RFC 5656 – Integração de Algoritmo de curva elíptica na camada de transporte de shell segura (Dezembro de 2009)
• RFC 6187 – Certificados X.509v3 para autenticação segura Shell (Março de 2011)
• RFC 6239 – Suíte B Criptografia Suítes para Shell Seguro (SSH) (Maio de 2011)
• RFC 6594 – Uso do Algoritmo SHA-256 com RSA, Algoritmo de Assinatura Digital (DSA) e Curva Elíptica DSA (ECDSA) na SSHFP Resource Records (Abril 2012)
• RFC 6668 – Verificação de integridade de dados SHA-2 para o protocolo de camada de transporte seguro Shell (SSH) (Julho 2012)
• RFC 7479 – Ed25519 SSHFP Registros de Recursos (Março de 2015)
• RFC 5592 – Modelo de transporte seguro Shell para o protocolo de gerenciamento de rede simples (SNMP) (Junho 2009)
• RFC 6242 – Usando o protocolo NETCONF sobre Shell seguro (SSH) (Junho de 2011)
• RFC 8332 – Uso de chaves RSA com SHA-256 e SHA-512 no protocolo Secure Shell (SSH) (Março de 2018)
• rascunho-gerhards-syslog-transport-ssh-00 – Mapeamento de transporte SSH para SYSLOG (Julho de 2006)
• draft-ietf-secsh-filexfer-13 – SSH Protocolo de Transferência de Arquivos (Julho de 2006)

Além disso, o projeto OpenSSH inclui diversas especificações/extensões de protocolo de fornecedores:

• Visão geral do OpenSSH PROTOCOL
• Visão geral do certificado/chave OpenSSH
• draft-miller-ssh-agent-04 - Protocolo do Agente SSH (Dezembro de 2019)