Secure Shell (SSH) é umprotocolo de redecriptográfico para operação de serviços de rede de forma segura sobre uma rede insegura.[1] O melhor exemplo de aplicação conhecido é paralogin remoto de utilizadores a sistemas de computadores.
O SSH fornece umcanal seguro sobre uma rede insegura em uma arquiteturacliente-servidor, conectando uma aplicaçãocliente SSH com umservidor SSH.[2] Aplicações comuns incluemlogin emlinha de comando remoto e execução remota de comandos, mas qualquerserviç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 ashells remotos em sistemas operacionais dotipo Unix, mas também verifica-se algum uso limitado noWindows. 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 oTelnet e para protocolos deshell remotos inseguros como os protocolos Berkeleyrlogin,rsh erexec. Estes protocolos enviam informações, especialmentesenhas, emtexto simples, tornando-os suscetíveis à interceptação e divulgação usandoanálise de pacotes.[4] Acriptografia usada pelo SSH objetiva fornecerconfidencialidade eintegridade de dados sobre uma rede insegura, como aInternet, apesar dos arquivos vazados porEdward Snowden indicarem que aAgência de Segurança Nacional pode algumas vezes descriptografar o SSH, permitindo-os ler o conteúdo de sessões SSH.[5]
O SSH usacriptografia de chave pública paraautenticar 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 porsenha 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 verificarchaves 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.
Em sistemas dotipo 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 pilhaMessage 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áriossh-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.
O SSH é normalmente usado para login em uma máquina remota e execução de comandos, mas também suportatunelamento,redirecionamento deportas TCP e conexõesX11. Ele pode transferir arquivos usando os protocolosSSH file transfer (SFTP) ousecure copy (SCP).[2] O SSH utiliza o modelocliente-servidor. Aporta TCP padrão 22 tem sido usada para contatar servidores SSH.[7]
Um programa cliente SSH é tipicamente utilizado para estabelecer conexões à umdaemon SSH remoto. Ambos os programas são comumente encontrados na maioria dossistemas operacionais modernos baseados emUNIX, incluindomacOS, distruibuiçõesLinux,OpenBSD,FreeBSD eNetBSD. Notoriamente, versões doWindows anteriores aoWindows 10 Versão 1709 não incluiam clientes SSH por padrão, abrindo espaço para softwares de terceiros como oPuTTY.
SSH possui grande relevância para aComputaçã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 amá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]
Em 1998, uma vulnerabilidade foi descrita noSSH 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 dodaemon SSH, normalmente oroot.
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 doSSH-1 possuir inúmeras falhas de design que o tornam vulnerável, ele é atualmente considerado obsoleto e deve ser evitado, desabilitando explicitamente ofallback paraSSH-1.[14] [37] A maioria dos servidores e clientes modernos suportam SSH-2. [38]
Referências