SSH: shell seguro

SSH significa Secure Shell. Também é conhecido como Secure Socket Shell. Um protocolo de rede criptográfico chamado Secure Shell (SSH) é usado para operar serviços de rede com segurança em redes inseguras. A arquitetura cliente-servidor é a base dos aplicativos SSH, que vinculam uma instância de cliente SSH a um servidor SSH.

Como sucessor do Telnet e de protocolos shell Unix remotos inseguros, como o Berkeley Remote Shell (rsh) e seus protocolos rlogin e rexec associados, o SSH foi criado para sistemas operacionais semelhantes ao Unix que empregam comunicação de token de autenticação de texto simples e insegura.

Definição

Podemos aplicar o SSH de diversas maneiras diferentes. A implementação mais simples criptografa dados usando pares de chaves pública-privada gerados automaticamente em ambas as extremidades de um canal de comunicação e de uma conexão de rede. Depois disso, autentica o usuário por meio de uma senha. Quando um usuário gera manualmente um par de chaves pública-privada, a autenticação é virtualmente concluída quando o par de chaves é estabelecido, permitindo que uma sessão seja iniciada instantaneamente sem solicitação de senha.

o que é check-out svn

Neste caso, o proprietário mantém em segredo a chave privada correspondente, e a chave pública é instalada em todas as máquinas que devem conceder acesso ao proprietário. Embora a chave privada sirva como base para a autenticação, a chave nunca é enviada pela rede durante a autenticação. O SSH confirma que o provedor da chave pública também possui a chave privada correspondente.

Conectar a chave pública desconhecida com uma chave privada conhecida em todas as versões do SSH é crucial antes de aceitá-las como chaves públicas legítimas com IDs. Aceitar uma chave pública de um invasor sem validá-la aceitará um invasor não confiável como usuário legítimo.

Criação

Tatu Ylönen, um cientista da computação da Finlândia, criou o SSH pela primeira vez em 1995. O desenvolvimento do conjunto de protocolos ocorreu em muitos grupos de desenvolvedores, levando a várias iterações de implementação. Existem implementações disponíveis para todos os sistemas operacionais populares, incluindo sistemas embarcados. OpenSSH, que os criadores do OpenBSD disponibilizaram como software de código aberto em 1999, é a pilha de software usada com mais frequência.

Gerenciamento de chaves OpenSSH para autenticação

A lista de chaves públicas aprovadas é comumente mantida em sistemas do tipo Unix no arquivo ~/.ssh/authorized keys no diretório inicial do usuário, que possui privilégios de login remoto. O SSH só respeita este arquivo se ele não puder ser modificado por ninguém além do proprietário e do root. A senha não é mais necessária quando a chave pública da extremidade remota e a chave privada correspondente da extremidade local estão presentes. Mas podemos usar uma senha para bloquear a chave privada e obter muito mais proteção. Também podemos pesquisar o código secreto em locais comuns e podemos usar uma opção de linha de comando para fornecer seu caminho completo (opção -i para ssh).

O SSH fornece ainda autenticação baseada em senha criptografada com geração automatizada de chaves. O invasor neste cenário pode se passar por um servidor confiável, solicitar a senha e obtê-la (ataque man-in-the-middle). No lado do servidor, podemos desligar a autenticação por senha.

Usar

SSH usa o paradigma cliente-servidor. Normalmente, o SSH é usado para registro. Ele também pode encapsular portas TCP, encaminhar conexões X11 e executar comandos em um sistema remoto. Normalmente, as conexões com um daemon SSH que permite conexões remotas são feitas usando um aplicativo cliente SSH. Ambos são frequentemente encontrados na maioria dos sistemas operacionais contemporâneos, como macOS, distribuições Linux, OpenBSD, FreeBSD, NetBSD, Solaris e OpenVMS. Algumas versões são proprietárias, freeware e de código aberto com vários graus de complexidade e abrangência (como PuTTY e a versão do OpenSSH incluída no Cygwin e OpenSSH). Notavelmente, o SSH não está incluído por padrão nas versões do Windows até o Windows 10 versão 1709.

Funcionalidade semelhante de gerenciamento de arquivos (sincronização, cópia e exclusão remota) é oferecida pelo aplicativo Windows gratuito e de código aberto WinSCP, que usa PuTTY como back-end. Sem a necessidade de instalação no computador cliente, o WinSCP e o PuTTY estão disponíveis embalados para operar diretamente em uma unidade USB. Muitas vezes é necessário ativar um recurso no aplicativo de configurações para configurar um servidor SSH no Windows.

Para lidar com questões de conexão e evitar os riscos de segurança da exposição direta de uma máquina virtual baseada em nuvem à Internet, o SSH é crucial na computação em nuvem. Uma conexão segura pela Internet pode ser possível através de um computador virtual de túnel SSH por meio de um firewall. Para este protocolo, a IANA designou a porta TCP 22, a porta UDP 22 e a porta SCTP 22.

Já em 2001, a IANA classificou a porta TCP 22 padrão para servidores SSH como uma das portas mais conhecidas. O protocolo da camada de transporte orientado à conexão SCTP pode ser usado para executar SSH em vez de TCP.

Progressão Histórica

Iteração 1

Um ataque de detecção de senha na rede de sua instituição inspirou Tatu Ylönen, pesquisador da Universidade de Tecnologia de Helsinque, na Finlândia, a criar a iteração inicial do protocolo (hoje conhecido como SSH-1) em 1995.

O SSH foi projetado para assumir o papel dos protocolos anteriores, incluindo rlogin, TELNET, FTP e rsh, que careciam de autenticação robusta e garantias de sigilo. Ylönen disponibilizou seu aplicativo como freeware. Em julho de 1995, o dispositivo rapidamente se tornou popular. No final de 1995, havia 20 mil usuários de SSH espalhados por 50 países diferentes.

quantos 0 em um bilhão

Para promover e avançar o SSH, Ylönen estabeleceu o SSH Communications Security em dezembro de 1995. Vários componentes de software livre, incluindo GNU libgmp, foram utilizados no primeiro lançamento do programa SSH, mas as iterações posteriores fornecidas pelo SSH Communications Security tornaram-se software cada vez mais proprietário. Segundo estimativas, havia 2 milhões de usuários no ano 2000.

Iteração 2

A Internet Engineering Task Force (IETF) designou o grupo de trabalho encarregado de criar o protocolo SSH versão 2 como 'Secsh' em sua documentação oficial.

SSH-2, uma iteração de protocolo aprimorada, tornou-se um padrão em 2006. SSH-1 não é compatível com esta versão. SSH-2 oferece funcionalidades e atualizações de segurança em relação ao SSH-1. Por exemplo, a troca de chaves Diffie-Hellman e a verificação robusta de integridade por meio de códigos de autenticação de mensagens proporcionam maior segurança. A capacidade de operar um número ilimitado de sessões shell em uma única conexão SSH é um dos novos recursos do SSH-2. Como o SSH-2 é mais avançado e amplamente utilizado que o SSH-1, certas implementações, como libssh (v0.8.0+), Lsh e Dropbear, suportam apenas SSH-2.

Iteração 1.99

A RFC 4253 exigia que um servidor SSH com suporte a 2.0, bem como versões anteriores, indicasse sua versão de protocolo como 1.99 em janeiro de 2006, bem depois do desenvolvimento da versão 2.1. Este número de versão é usado para indicar compatibilidade com versões anteriores, em vez de representar uma revisão anterior do software.

OSSH e OpenSSH

Desde que a última versão do programa SSH original, versão 1.2.12, foi distribuída sob licença de código aberto em 1999, os desenvolvedores têm trabalhado em uma versão de software livre. Isto foi usado como base para o programa OSSH de Björn Grönvall. Logo depois, a equipe do OpenBSD clonou o trabalho de Grönvall para produzir o OpenSSH, que foi incluído na versão 2.6 do OpenBSD. Eles criaram um ramo de ‘portabilidade’ a partir desta versão para transferir OpenSSH para diferentes sistemas operacionais.

A implementação SSH mais utilizada em 2005 foi o OpenSSH, a versão padrão em muitas distribuições de sistemas operacionais. Depois de remover o suporte SSH-1 da base de código na versão OpenSSH 7.6, o OpenSSH ainda está sendo atualizado e oferece suporte ao protocolo SSH-2. Entretanto, o OSSH já não é relevante.

Usos

O usuário 'josh' 'SSHed' do computador local 'foo lutador' para a máquina distante 'tengwar' para executar xeyes como um exemplo de tunelamento de um programa X11 através de SSH. As pessoas utilizam o cliente SSH do Windows PuTTY para acessar o OpenWrt.

SSH é um protocolo que funciona com muitos sistemas, incluindo Microsoft Windows e a maioria das variações do Unix (Linux, BSDs, incluindo macOS da Apple e Solaris). Os aplicativos a seguir podem precisar de recursos exclusivos ou compatíveis com clientes ou servidores SSH específicos. Por exemplo, atualmente só é viável usar o servidor OpenSSH e a implementação do cliente do protocolo SSH para construir uma VPN.

• Para acessar um shell em um host distante (substituindo Telnet e rlogin)
• Para executar um comando solitário em um host distante (substituindo rsh)
• Para configurar o login automatizado (sem senha) de um servidor distante (por exemplo, usando OpenSSH)
• Como uma VPN criptografada totalmente funcional, lembre-se de que apenas o cliente e o servidor OpenSSH suportam esse recurso.
• Para transmitir X de um host distante (possível através de vários hosts intermediários)
• Para usar clientes SSH que suportam o protocolo SOCKS para navegar na Internet por meio de uma conexão proxy criptografada.
• Para montar com segurança um diretório de servidor remoto como um sistema de arquivos em uma máquina local utilizando SSHFS.
• Através de uma ou mais das tecnologias mencionadas acima para monitoramento e administração remota automática de servidores.
• Para desenvolvimento de dispositivos móveis ou incorporados compatíveis com SSH.
• Para proteger mecanismos de transferência de arquivos.

Métodos de transferência de arquivos

Vários sistemas de transferência de arquivos empregam protocolos Secure Shell, como

• Sobre SSH, Secure Copy (SCP) é desenvolvido a partir do protocolo RCP.
• O rsync, que supostamente é mais eficaz que o SCP, geralmente é operado por meio de uma conexão SSH.
• Uma alternativa segura ao FTP é o SSH File Transfer Protocol (SFTP) (não deve ser confundido com FTP sobre SSH ou FTPS)
• FISH, ou arquivos transferidos pelo protocolo shell, foi introduzido em 1998 e desenvolvido a partir de instruções SSH sobre shell Unix.
• O Aspera, também conhecido como Protocolo Rápido e Seguro (FASP), emprega SSH para comando e transporte de dados, portas UDP.

Arquitetura

Três componentes distintos constituem a arquitetura em camadas do protocolo SSH:

java estático

• O Transmission Control Protocol (TCP) do TCP/IP é comumente usado pela camada de transporte (RFC 4253), com a porta número 22 reservada como porta de escuta do servidor. Esta camada implementa criptografia, compactação, verificação de integridade, troca inicial de chaves e autenticação de servidor. Embora cada implementação possa permitir mais, ela expõe à camada superior uma interface para transmitir e receber pacotes de texto simples de até 32.768 bytes cada. Normalmente, após 1 GB de dados ter sido transportado ou após uma hora, o que ocorrer primeiro, a camada de transporte organiza a retroca de chaves.
  
• A autenticação do cliente é feita através da camada de autenticação do usuário (RFC 4252), que também oferece diversas técnicas de autenticação. A autenticação orientada pelo cliente significa que o cliente SSH, e não o servidor, pode solicitar uma senha ao usuário. Somente as solicitações de autenticação do cliente recebem uma resposta do servidor. As seguintes técnicas de autenticação de usuário são frequentemente usadas:
  Senha, uma técnica simples de autenticação de senha que inclui a capacidade de modificar a senha. Nem todos os softwares usam essa técnica.
• Geralmente suportando pelo menos pares de chaves DSA, ECDSA ou RSA, o chave pública é uma técnica para autenticação baseada em chave pública. Outras implementações também aceitam certificados X.509.
Teclado interativo(RFC 4256) é uma técnica flexível na qual o servidor fornece um ou mais prompts para entrada de informações, o cliente os exibe e, em seguida, envia de volta as respostas que o cliente digitou. Usado por algumas configurações do OpenSSH para oferecer efetivamente autenticação por senha quando PAM é o provedor de autenticação de host subjacente, o que pode ocasionalmente impedir o login com um cliente que suporta apenas a técnica de autenticação de senha simples.
• A funcionalidade de logon único para sessões SSH é fornecida via GSSAPI técnicas de autenticação, que oferecem um sistema extensível para lidar com a autenticação SSH usando mecanismos externos como Kerberos 5 ou NTLM. Embora o OpenSSH tenha uma implementação funcional de GSSAPI, as implementações comerciais de SSH geralmente integram essas técnicas para uso em empresas.
• A ideia de canais que definem os serviços SSH oferecidos é definida pela camada de conexão (RFC 4254). Podemos multiplexar várias conexões SSH a partir de uma única. Ambos transmitem dados em ambas as direções. As solicitações de canal transmitem dados fora de banda específicos de um determinado canal, como o código de saída de um processo do lado do servidor ou a alteração do tamanho de uma janela de terminal. Além disso, utilizando o tamanho da janela de recepção, cada canal controla seu fluxo. O cliente SSH faz uma solicitação global para encaminhar uma porta do servidor. Os tipos de canais comuns incluem:
  • Shell para SFTP, exec e shells de terminal (incluindo transferências SCP)
  • Direct-TCPIP para conexões encaminhadas do cliente para o servidor.
  • Conexões encaminhadas de servidor para cliente usando forwarded-tcpip
  • Para confirmar a legitimidade do host, o registro DNS SSHFP (RFC 4255) oferece impressões digitais da chave do host público.

Devido ao seu design aberto, podemos utilizar o SSH para uma ampla gama de tarefas além de proteger shells, proporcionando grande versatilidade.

Vulnerabilidades

SSH-1

Devido à proteção inadequada da integridade dos dados fornecida pelo CRC-32 nesta versão do protocolo, uma vulnerabilidade no SSH 1.5 foi identificada em 1998 que permitiu a inserção não autorizada de material em um fluxo SSH criptografado. Na maioria das implementações, eles adicionaram um patch conhecido como SSH Compensation Attack Detector. Várias dessas implementações revisadas incluíram uma nova falha de estouro de número inteiro, permitindo que invasores executassem código arbitrário com root ou com os recursos do daemon SSH.

Uma falha que permite aos invasores alterar o último bloco de uma sessão criptografada por IDEA foi encontrada em janeiro de 2001. Outra falha que permitiu a um servidor não autorizado passar um login de cliente para outro servidor foi encontrada no mesmo mês.

Devido às suas vulnerabilidades inerentes, o SSH-1 é geralmente considerado desatualizado e deve ser evitado removendo explicitamente o substituto do SSH-1. A maioria dos servidores e clientes atuais oferece suporte a SSH-2.

Recuperação de texto simples para CBC

Uma vulnerabilidade teórica que permitia a recuperação de até 32 bits de texto simples de um bloco de texto cifrado criptografado usando o método de criptografia padrão da época, CBC, foi descoberta em todas as versões do SSH em novembro de 2008. A solução mais simples é mudar para CTR, contador modo, em vez do modo CBC, o que torna o SSH imune ao ataque.

NSA suspeita de descriptografia

A divulgação de documentos confidenciais por Edward Snowden à Der Spiegel em 28 de dezembro de 2014 implica que a Agência de Segurança Nacional será capaz de decodificar potencialmente certas comunicações SSH.