Loading AI tools
Da Wikipédia, a enciclopédia livre
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]
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.
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.
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]
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]
|título=
(ajuda)|título=
(ajuda)