Secure Shell

Secure Shell (SSH) é um protocolo de rede criptográfico para operação de serviços de rede de forma segura sobre uma rede insegura. 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. 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.

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. 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.

Definição

O SSH usa criptografia de chave pública para autenticar o computador remoto e permiti-lo autenticar o utilizador, se necessário. 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

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. 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

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). O SSH utiliza o modelo cliente-servidor. A porta TCP padrão 22 tem sido usada para contatar servidores SSH.

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.

Vulnerabilidades

SSH-1

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. Uma correção conhecida como SSH Compensation Attack Detector 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, 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. 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.

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. [37] A maioria dos servidores e clientes modernos suportam SSH-2. [38]

Ver também

• OpenSSH

Ligações externas

• «OpenSSH» (em inglês) 
• «SSH». (em inglês) 
• «PUTTY» (em inglês). Cliente SSH para Windows. 
• «WinSCP». Cliente SFTP para Windows. (em inglês) 
• «Fugu SSH» (em inglês). Cliente SSH para OSX. 
• «Web». Cliente SSH para Internet. (em inglês)