Secure Shell

Pilha de protocolos TCP/IP
Camada de aplicação
Camada de transporte
Camada de rede
Camada de enlace de dados

Secure Shell (SSH) é um protocolo de rede criptográfico para operação de serviços de rede de forma segura sobre uma rede insegura.[1] O melhor exemplo de aplicação conhecido é para login remoto de utilizadores a sistemas de computadores.

O SSH fornece um canal seguro sobre uma rede insegura em uma arquitetura cliente-servidor, conectando uma aplicação cliente SSH com um servidor SSH.[2] Aplicações comuns incluem login em linha de comando remoto e execução remota de comandos, mas qualquer serviço de rede pode ser protegido com SSH. A especificação do protocolo distingue entre duas versões maiores, referidas como SSH-1 e SSH-2.

A aplicação mais visível do protocolo é para acesso a shells remotos em sistemas operacionais do tipo Unix, mas também verifica-se algum uso limitado no Windows. Em 2015, a Microsoft anunciou que incluiriam suporte nativo para SSH em uma liberação futura.[3]

O SSH foi projetado como um substituto para o Telnet e para protocolos de shell remotos inseguros como os protocolos Berkeley rlogin, rsh e rexec. Estes protocolos enviam informações, especialmente senhas, em texto simples, tornando-os suscetíveis à interceptação e divulgação usando análise de pacotes.[4] A criptografia usada pelo SSH objetiva fornecer confidencialidade e integridade de dados sobre uma rede insegura, como a Internet, apesar dos arquivos vazados por Edward Snowden indicarem que a Agência de Segurança Nacional pode algumas vezes descriptografar o SSH, permitindo-os ler o conteúdo de sessões SSH.[5]

Definição[editar | editar código-fonte]

O SSH usa criptografia de chave pública para autenticar o computador remoto e permiti-lo autenticar o utilizador, se necessário.[2] Há várias maneiras de usar o SSH, uma é usar pares de chave pública-privada geradas automaticamente para simplesmente encriptar uma conexão de rede e então usar autenticação por senha para logar.

Outra maneira é usar um par de chaves pública-privada geradas manualmente para realizar a autenticação, permitindo que usuários ou programas loguem sem ter que especificar uma senha. Neste cenário, qualquer um pode produzir um par correspondente de chaves diferentes (pública e privada). A chave pública é colocada em todos os computadores que devem permitir o acesso ao proprietário da chave privada correspondente (o proprietário mantem o segredo da chave privada). Uma vez que a autenticação é baseada na chave privada, a chave em si nunca é transferida por meio da rede durante a autenticação. O SSH apenas verifica 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, isto é, associar as chaves públicas com as identidades, antes de aceitá-las como válidas. Aceitar a chave pública de um atacante sem validação autorizará o atacante como um usuário válido.

Gerenciamento de chaves[editar | editar código-fonte]

Em sistemas do tipo Unix, a lista de chaves públicas autorizadas é normalmente armazenada no diretório home do usuário que está permitido logar remotamente, no arquivo ~/.ssh/authorized_keys.[6] Este arquivo é considerado pelo SSH apenas se ele não puder ser alterado por nada além do proprietário e do root. Quando a chave pública está presente no terminal remoto e a chave privada correspondente está presente no terminal local, a digitação da senha não é mais necessária (alguns softwares como a pilha Message Passing Interface (MPI) pode precisar deste acesso sem senha para rodar adequadamente). Entretanto, para segurança adicional a chave privada em si pode ser bloqueada com uma senha.

A chave privada também pode ser procurada em locais padrões e seu caminho completo pode ser especificado como uma definiçã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 suporta autenticação baseada em senha que é criptografada por chaves geradas automaticamente. Neste caso o atacante pode imitar o lado servidor legítimo, solicitar a senha e obtê-la (ataque homem-no-meio). Entretanto, isto é possível apenas se os dois lado nunca tiverem se autenticado antes, uma vez que o SSH lembra a chave que o lado servidor usou anteriormente. O cliente SSH lança um aviso antes de aceitar a chave de um novo servidor desconhecido previamente. A autenticação por senha pode ser desabilitada.

Uso[editar | editar código-fonte]

O SSH é normalmente usado para login em uma máquina remota e execução de comandos, mas também suporta tunelamento, redirecionamento de portas TCP e conexões X11. Ele pode transferir arquivos usando os protocolos SSH file transfer (SFTP) ou secure copy (SCP).[2] O SSH utiliza o modelo cliente-servidor. A porta TCP padrão 22 tem sido usada para contatar servidores SSH.[7]

Um programa cliente SSH é tipicamente utilizado para estabelecer conexões à um daemon SSH remoto. Ambos os programas são comumente encontrados na maioria dos sistemas operacionais modernos baseados em UNIX, incluindo macOS, distruibuições Linux, OpenBSD, FreeBSD e NetBSD. Notoriamente, versões do Windows anteriores ao Windows 10 Versão 1709 não incluiam clientes SSH por padrão, abrindo espaço para softwares de terceiros como o PuTTY.

SSH possui grande relevância para a Computação em Nuvem, permitindo conexões remotas à servidores através da Internet, sem comprometer a segurança dos dados, uma vez que não precisa expor a máquina virtual, sendo esta baseada em núvem, diretamente à internet. A conexão é feita então por meio de um túnel SSH, que fornece um caminho seguro através de um firewall até a máquina virtual.[8]

Vulnerabilidades[editar | editar código-fonte]

SSH-1[editar | editar código-fonte]

Em 1998, uma vulnerabilidade foi descrita no SSH 1.5, a qual permitia a inserção não autorizada de conteúdo em um fluxo SSH criptografado devido á falha na proteção de integridade de dados do CRC-32, usado nesta versão do protocolo.[9][10] Uma correção conhecida como SSH Compensation Attack Detector[11] foi introduzida em grande parte das implementações. Porém, muitas das novas implementações atualizadas continham uma outra vulnerabilidade encontrada, a de estouro de inteiro,[12] que permitia a invasores executar códigos arbitrários com privilégios do daemon SSH, normalmente o root.

Em Janeiro de 2001, foi encontrada uma vulnerabilidade que dava aos invasores a permissão de modificar o último bloco de uma sessão criptografada por IDEA.[13] Ainda no mesmo mês, outra vulnerabilidade foi descoberta, essa por sua vez permitia a um servidor malicioso encaminhar uma autenticação de um cliente para um outro servidor.[14]

Dado ao fato do SSH-1 possuir inúmeras falhas de design que o tornam vulnerável, ele é atualmente considerado obsoleto e deve ser evitado, desabilitando explicitamente o fallback para SSH-1.[14] [37] A maioria dos servidores e clientes modernos suportam SSH-2. [38]

Referências

  1. ↑ Network Working Group of the IETF, January 2006, RFC 4251, The Secure Shell (SSH) Protocol Architecture
  2. ↑ a b c Network Working Group of the IETF, January 2006, RFC 4252, The Secure Shell (SSH) Authentication Protocol
  3. ↑ Peter Bright (2 de junho de 2015). «Microsoft bringing SSH to Windows and PowerShell». Ars Technica 
  4. ↑ SSH Hardens the Secure Shell, Serverwatch.com
  5. ↑ «Prying Eyes: Inside the NSA's War on Internet Security». Spiegel Online. 28 de dezembro de 2014 
  6. ↑ SSH setup manual
  7. ↑ «Service Name and Transport Protocol Port Number Registry». iana.org 
  8. ↑ Tuneis SSH. Disponível em: <https://www.ppgia.pucpr.br/~jamhour/Pessoal/Graduacao/Ciencia/Pratica/OpenSSH/OpenSSH.html>. Acesso em: 8 mar. 2022.
  9. ↑ «Core Security Technologies». web.archive.org. 8 de julho de 2011. Consultado em 17 de março de 2021 
  10. ↑ www.kb.cert.org https://www.kb.cert.org/vuls/id/13877. Consultado em 17 de março de 2021  Em falta ou vazio |título= (ajuda)
  11. ↑ «SSH CRC-32 Compensation Attack Detector Vulnerability». web.archive.org. 25 de julho de 2008. Consultado em 17 de março de 2021 
  12. ↑ «US-CERT Vulnerability Note VU#945216». web.archive.org. 13 de outubro de 2005. Consultado em 17 de março de 2021 
  13. ↑ www.kb.cert.org https://www.kb.cert.org/vuls/id/315308. Consultado em 17 de março de 2021  Em falta ou vazio |título= (ajuda)
  14. ↑ a b «US-CERT Vulnerability Note VU#684820». web.archive.org. 1 de setembro de 2009. Consultado em 17 de março de 2021 

Ver também[editar | editar código-fonte]

Ligações externas[editar | editar código-fonte]

Obtida de "https://pt.wikipedia.org/w/index.php?title=Secure_Shell&oldid=67052451"