Uma chave SSH é uma credencial de acesso no protocolo SSH. A sua função é semelhante à dos nomes de utilizadores e senhas, mas as chaves são usadas principalmente para processos automatizados e para a implementação de um único login pelos administradores de sistemas e utilizadores de energia.

As chaves SSH são credenciais de autenticação

SSH (Secure Shell) é usada para gerir redes, sistemas operativos, e configurações. Está também dentro de muitas ferramentas de transferência de ficheiros e ferramentas de gestão de configuração. Cada grande empresa utiliza-a, em todos os centros de dados.

SSH chaves permitem a automatização que torna possíveis e rentáveis os modernos serviços de nuvem e outros serviços dependentes de computador. Oferecem conveniência e maior segurança quando geridas adequadamente.

As chaves SSH funcionais assemelham-se a palavras-passe. Concedem acesso e controlam quem pode aceder a quê. Na gestão da identidade e do acesso, necessitam de políticas semelhantes, aprovisionamento e terminação como contas de utilizador e palavras-passe. Não se pode ter confidencialidade, integridade, ou quaisquer garantias de disponibilidade contínua dos sistemas sem controlar chaves SSH.

Tecnicamente, as chaves são chaves criptográficas utilizando um sistema criptográfico de chave pública. No entanto, funcionalmente são credenciais de autenticação e precisam de ser geridas como tal.

As chaves autorizadas definem quem pode aceder a cada sistema

As chaves autorizadas são chaves públicas que concedem acesso. São análogas às fechaduras que a chave privada correspondente pode abrir.

Para mais informações, ver a página dedicada sobre chaves autorizadas.

As chaves de identidade identificam utilizadores e fornecem acesso

As chaves de identidade são chaves privadas que um cliente SSH utiliza para se autenticar quando entra num servidor SSH. São análogas às chaves físicas que podem abrir uma ou mais fechaduras.

As chaves autorizadas e as chaves de identidade são conjuntamente chamadas chaves de utilizador. Referem-se à autenticação do utilizador, ao contrário das chaves de anfitrião que são utilizadas para autenticação de anfitrião.

Para mais informações, ver a página dedicada sobre chaves de identidade.

Autenticação de utilizador baseada em certificados

Certificados PKI também podem ser utilizados para autenticação. Neste caso, o utilizador ainda tem uma chave privada, mas também tem um certificado associado à chave. A tecnologia é suportada tanto no Tectia SSH como no OpenSSH, com algumas diferenças. Para mais informações, ver a página dedicada à autenticação baseada em certificados em SSH.

Chaves de autenticação de dispositivos

Chaves de autenticação de servidores de host

Chaves de host são utilizadas para autenticação de hosts, ou seja, computadores. O seu objectivo é prevenir ataques de homem no meio. Ver a página separada sobre chaves de anfitrião para mais informações.

A autenticação de anfitrião baseada em certificados pode ser uma alternativa muito atractiva em grandes organizações. Permite que as chaves de autenticação do dispositivo sejam rodadas e geridas convenientemente e que cada ligação seja protegida.

Known host keys

Uma das características únicas do SSH é que, por defeito, confia e lembra-se da chave do host quando se liga a ele pela primeira vez. Este foi um diferenciador de chave que permitiu que o SSH fosse implantado no terreno, uma vez que não existia infra-estrutura de chave centralizada para anfitriões em 1995, e ainda não existe actualmente (2017), com isenção de certificados SSL para servidores Web. A facilidade de implementação resultante foi uma das principais razões para o sucesso do SSH.

As chaves de anfitrião memorizadas são chamadas chaves de anfitrião conhecidas e são armazenadas num ficheiro chamado known_hosts no OpenSSH. Desde que as chaves de anfitrião não mudem, este appoach é muito fácil de usar e proporciona uma segurança bastante boa. No entanto, em grande organização e quando as chaves mudam, a manutenção de ficheiros de anfitriões conhecidos pode tornar-se muito demorada. A utilização de certificados para chaves de anfitrião é recomendada nesse caso. O Tectia SSH suporta certificados padrão X.509 para anfitriões. O OpenSSH tem o seu próprio formato de certificado proprietário. A vantagem dos certificados baseados em padrões é que podem ser emitidos por qualquer autoridade certificadora (AC), enquanto que não existem ACs fiáveis para chaves OpenSSH. Ver a página dedicada aos certificados com SSH para mais informações.

Session keys

Uma chave de sessão em SSH é uma chave de encriptação utilizada para encriptar a maior parte dos dados de uma ligação. A chave de sessão é negociada durante a ligação e depois utilizada com um algoritmo de encriptação simétrica e um algoritmo de código de autenticação de mensagem para proteger os dados. Para mais informações, ver a página separada sobre chaves de sessão.

Como configurar autenticação baseada em chave

A autenticação baseada em chave em SSH é chamada autenticação de chave pública. É fácil de configurar pelos utilizadores finais na configuração por defeito. Por outro lado, organizações preocupadas com a segurança precisam de estabelecer políticas claras para o aprovisionamento e a cessação do acesso baseado em chaves.

Como configurar a autenticação de chave pública para OpenSSH

As chaves SSH são tipicamente configuradas num ficheiro autorizado de chaves em .ssh subdirectório no directório home do utilizador. Tipicamente um administrador de sistema criaria primeiro uma chave usando ssh-keygen e depois instalá-la como uma chave autorizada num servidor usando a ferramenta ssh-copy-id. Ver também a página dedicada à configuração de chaves autorizadas para OpenSSH.

Recomendamos a utilização de frases-passe para todas as chaves de identidade utilizadas para acesso interactivo. Em princípio, recomendamos a utilização de frases-passe também para acesso automatizado, mas isto não é muitas vezes prático.

Armazenar chaves em ssh-agente para um único sinal

SSH vem com um programa chamado , que pode guardar na memória as chaves privadas desencriptadas pelo utilizador e utilizá-las para autenticar logins. O agente também pode ser utilizado para aceder a chaves num smartcard ou num Módulo de Segurança de Hardware (HSM). Ver a documentação para ssh-agent sobre como configurá-lo.

A ligação ao agente SSH pode ser reencaminhada para um servidor, de modo a que o logon único também funcione a partir desse servidor. Esta funcionalidade deve ser utilizada com cuidado, pois permite a um servidor comprometido utilizar as credenciais do utilizador a partir do agente original. O reencaminhamento do agente pode, no entanto, ser uma característica de grande conveniência para utilizadores com poder em ambientes menos críticos de segurança.

Ativar o reencaminhamento de agentes, set AllowAgentForwarding to yes in /etc/ssh/sshd_config on the server and ForwardAgent to yes in /etc/ssh/ssh_config.

Tamanhos de chave recomendados

Recomendamos a selecção de tamanhos de chave de acordo com NIST SP 800-57. Os tamanhos de chave por defeito utilizados pela ferramenta ssh-keygen são geralmente de força aceitável. De facto, uma vez que o protocolo nunca revela as chaves públicas que são aceitáveis para autenticação do utilizador, os algoritmos utilizados para as chaves não são tão críticos como o são, por exemplo, nos certificados PKI.

Para chaves RSA, 2048 bits é provavelmente uma boa escolha hoje (2017). No entanto, muitos criptógrafos recomendam agora a mudança para chaves ECDSA e pensam que os avanços no factoring de grandes inteiros podem tornar as chaves RSA vulneráveis no curto/médio prazo. Para ECDSA recomendamos a utilização de chaves de 521 bits (sic!), ainda que 384 ou mesmo 256 bits sejam provavelmente seguros. Não há qualquer benefício prático em utilizar chaves mais pequenas.

Identity key location

Identity keys are usually stored in a user’s .ssh directory, for example, .ssh/ssh_id_rsa. O nome do ficheiro chave de identidade por defeito começa com id_<algorithm>. No entanto, é possível especificar qualquer nome de ficheiro e qualquer localização ao criar uma chave privada, e fornecer o nome do caminho com a opção -i ao cliente SSH. Por exemplo, ssh -i /home/ylo/secure/my-key [email protected] utilizaria uma chave privada do ficheiro my-key para autenticação.

O local padrão da chave de identidade também pode ser configurado em /etc/ssh/ssh_config ou no ficheiro .ssh/config usando a opção IdentityFile do utilizador.

Localização de chave autorizada

Quando um utilizador tenta iniciar sessão usando autenticação baseada em chave, o servidor OpenSSH procura chaves autorizadas de um directório especificado na configuração do servidor usando a opção AuthorizedKeysFile. O padrão é .ssh/authorized_keys no directório home do utilizador.

No entanto, ter as chaves autorizadas armazenadas no directório home do utilizador significa que o utilizador pode adicionar novas chaves que autorizam os logins à sua conta. Isto é conveniente, mas o utilizador pode então dar estas chaves a amigos ou colegas, ou mesmo vendê-las para Bitcoins (isto realmente aconteceu). As chaves SSH são além disso permanentes e permanecem válidas até serem expressamente removidas.

Se forem adicionadas chaves autorizadas para contas root ou de serviço, elas permanecem facilmente válidas mesmo depois de a pessoa que as instalou ter deixado a organização. São também uma forma conveniente para os hackers estabelecerem presença permanente num sistema se não houver detecção e alertas sobre novas chaves não autorizadas.

Por estas razões, a maioria das grandes organizações quer mover chaves autorizadas para um local de raiz e estabelecer um processo controlado de aprovisionamento e terminação para elas.

Mover chaves SSH para um local de raiz

Em princípio, mover chaves SSH para um local de raiz é fácil:

1. p>criar um directório de raiz adequado, por exemplo, /etc/ssh/keys, sob o qual as chaves autorizadas são armazenadas.
2. p>cria um subdirectório sob este directório para cada utilizador, e move o ficheiro authorized_keys de cada utilizador para /etc/ssh/keys/<user>/authorized_keys.
3. p>Finalmente, alterar conjunto AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys em /etc/ssh/sshd_config.

Na prática, contudo, isto nem sempre é tão simples, especialmente em ambientes maiores. Os nomes dos utilizadores podem vir de directórios (por exemplo, Active Directory ou LDAP). Muitas organizações têm várias versões OpenSSH, incluindo sistemas muito antigos ou construções de SSH personalizadas que têm caminhos não padronizados incorporados. Recomendamos a utilização de ferramentas de gestão de chaves tais como o Universal SSH Key Manager para ocultar esta complexidade em ambientes maiores. Estas ferramentas podem também implementar um fluxo de trabalho de aprovisionamento, terminação e aprovação de chaves e alertas sobre alterações não autorizadas feitas por utilizadores root.

A limitação do número de chaves privadas do OpenSSH

O servidor OpenSSH tem uma funcionalidade (eu chamaria um bug) que conta testar se uma determinada chave pode ser usada para autenticação como uma tentativa de autenticação. Isto tem a consequência de que se o utilizador tiver mais de cinco chaves em .ssh, apenas algumas delas funcionam. Isto causa frequentemente o fracasso da autenticação baseada em chaves e é muitas vezes difícil para os utilizadores de descobrir. A forma de contornar isto é especificar explicitamente a chave privada a usar usando a opção -i. Uma alternativa é ajustar a sessão MaxAuthTries no servidor, mas esta não é uma solução completa e é indesejável aumentar o número de tentativas de autenticação de palavra-passe.

Como são as chaves SSH

Uma chave autorizada pode ter este aspecto:

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar

Uma chave de identidade pode ter este aspecto:

-----BEGIN EC PRIVATE KEY-----MHcCAQEEIJWbvSW7h50HPwG+bWR3DXgQ6YhOxYbe0ifr1rRUvsUuoAoGCCqGSM49AwEHoUQDQgAE34yHdT/dZ7hVi1XVCZZQUjMUtNR56CXUCjn9Aa0JEYBmfxvFf0qUKutYhIiNJgDAJqMgQZI8RnA80wGgrxcPxA==-----END EC PRIVATE KEY-----

Como funciona a autenticação no SSH?

Initializar uma ligação em SSH consiste em:

• p>p>Negociar a versão do protocolo a utilizar
• p>p>Negociar algoritmos criptográficos e outras opções a utilizar
• p>p>Negociar umchave de sessão de tempo para encriptar o resto da sessão
• p>Autenticar o anfitrião do servidor usando a sua chave de anfitrião
• p>Autenticar o utilizador usando uma palavra-passe, autenticação de chave pública, ou outros meios.

Depois disto, os dados podem ser trocados, incluindo dados terminais, gráficos e ficheiros.

Autenticação de chave pública

O mecanismo de autenticação baseado em chave em SSH é chamado autenticação de chave pública. Essencialmente, alguns dados específicos da sessão são assinados usando a chave de identidade privada. A assinatura é então enviada para o servidor que verifica se a chave utilizada para assinatura está configurada como uma chave autorizada. O servidor verifica então a assinatura digital usando a chave pública na chave autorizada. A chave de identidade nunca é enviada para o servidor.

O essencial na autenticação da chave pública é que ela permite a um servidor aceder a outro servidor sem ter de digitar uma palavra-passe. Esta característica poderosa é a razão pela qual é tão amplamente utilizada para transferências de ficheiros (utilizando o protocolo SFTP) e gestão de configuração. É também normalmente utilizada por administradores de sistema para single sign-on.

Como são comuns chaves SSH e qual é o risco

chaves SSH acabam por ser extremamente comuns e amplamente utilizadas. Muitas grandes organizações acumulam-nas há vinte anos sem qualquer controlo. Uma empresa típica da Fortune 500 tem vários milhões de chaves que concedem acesso aos seus servidores. Num caso de cliente, examinámos 500 aplicações e 15.000 servidores, e encontrámos 3.000.000 de chaves autorizadas e 750.000 pares de chaves únicas. Esta organização também tinha mais de cinco milhões de logins diários utilizando chaves. As chaves foram utilizadas para executar transacções financeiras, actualizar configurações, mover dados de registo, transferências de ficheiros, logins interactivos por administradores de sistema, e muitos outros fins.

Está-se a verificar que a maioria das grandes empresas têm centenas de milhares ou mesmo milhões de chaves. Estas chaves são acessos não contabilizados, e podem arriscar toda a empresa.

Como eliminar completamente as chaves SSH

O Gestor de Acesso Privado On-Demand pode ser utilizado para eliminar completamente as chaves SSH dos servidores e estabelecer um controlo de acesso e registo de sessão baseado em políticas em toda a empresa. Também elimina a maior parte da carga administrativa na gestão de chaves, ao mesmo tempo que proporciona os benefícios: automatização e logon único.