Secure Shell
| Pilha de protocolos TCP/IP |
|---|
| Camada de Aplicação |
| Camada de Transporte |
| Camada de Rede |
| Camada de Ligação 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 contas shell 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.
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.[8][9] Uma correção conhecida como SSH Compensation Attack Detector[10] 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[11], 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[12]. 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. [13]
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]
Como o SSH-1 tem falhas de design inerentes que o tornam vulnerável, agora ele é geralmente considerado obsoleto e deve ser evitado desabilitando explicitamente o fallback para SSH-1. [37] A maioria dos servidores e clientes modernos suportam SSH-2. [38]
Referências
- ↑ Network Working Group of the IETF, January 2006, RFC 4251, The Secure Shell (SSH) Protocol Architecture
- ↑ a b c Network Working Group of the IETF, January 2006, RFC 4252, The Secure Shell (SSH) Authentication Protocol
- ↑ Peter Bright (June 2, 2015). «Microsoft bringing SSH to Windows and PowerShell». Ars Technica Verifique data em:
|data=(ajuda) - ↑ SSH Hardens the Secure Shell, Serverwatch.com
- ↑ «Prying Eyes: Inside the NSA's War on Internet Security». Spiegel Online. December 28, 2014 Verifique data em:
|data=(ajuda) - ↑ SSH setup manual
- ↑ «Service Name and Transport Protocol Port Number Registry». iana.org
- ↑ «Core Security Technologies». web.archive.org. 8 de julho de 2011. Consultado em 17 de março de 2021
- ↑ 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) - ↑ «SSH CRC-32 Compensation Attack Detector Vulnerability». web.archive.org. 25 de julho de 2008. Consultado em 17 de março de 2021
- ↑ «US-CERT Vulnerability Note VU#945216». web.archive.org. 13 de outubro de 2005. Consultado em 17 de março de 2021
- ↑ 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) - ↑ «US-CERT Vulnerability Note VU#684820». web.archive.org. 1 de setembro de 2009. Consultado em 17 de março de 2021
- ↑ «US-CERT Vulnerability Note VU#684820». web.archive.org. 1 de setembro de 2009. Consultado em 17 de março de 2021
