Como armazenar chaves SSH?

67

Comecei a usar chaves SSH em vez de senhas recentemente (graças ao GitHub, é claro), então lembre-se de que sou bastante novo em todo esse conceito. Atualmente, minhas chaves simplesmente estão em ~ / .ssh, mas não tenho certeza se essa é uma boa prática. Por exemplo, se eu tiver várias máquinas, precisarei duplicar minhas chaves privadas, o que acho indesejável. Ou, se o meu disco rígido ficar vazio, perderei essas chaves, o que (eu acho) também é indesejável.

Então, quais são as práticas recomendadas para armazenar chaves SSH de forma segura, conveniente e confiável?

Parece que usar um cartão inteligente é uma opção (consulte Cartões inteligentes para armazenar as chaves gpg / ssh (Linux) - o que eu preciso? ). Essa é a melhor?

Atualização: O motivo da pergunta é que muitos serviços (como GitHub, AWS EC2) fornecem guias sobre como configurar chaves SSH para usar o serviço, mas pouco ou nenhum plano de fundo (como, o que fazer se você já tiver uma chave gerada por ssh-keygen[1], quais são as medidas de segurança recomendadas). E não está claro se essas informações são de fato sem importância ou se você as conhece "por padrão".

Para resumir as respostas até esse ponto (mas, por favor, leia-as e se você tiver algo a acrescentar - por favor, faça): parece que, neste caso, é bom se você deixar suas chaves privadas em ~ / .ssh, desde que você mantenha-os de outras pessoas; mas verifique se você tem outra maneira de acessar o serviço para carregar ou gerar uma nova chave se você perder uma (normalmente é o caso).

[1] O GitHub é usado para fornecer ajuda sobre como gerenciar várias chaves .

security ssh-keys

— Anton Strogonoff
fonte

Esse link parece estar quebrado help.github.com/multiple-ssh-keys

— KJ Price

@KJ Price, graças à Wayback Machine do Internet Archive , a página ainda está disponível online, embora não no link original. Uma cópia da página arquivada em 2 de setembro de 2011 pode ser encontrada em Várias chaves SSH .

— moonpoint

41

Por exemplo, se eu tiver várias máquinas, seria necessário duplicar chaves privadas, o que acho indesejável.

Não, na verdade você não. Se você tiver várias máquinas, basta criar uma chave privada separada em cada uma. Para cada chave privada, basta carregar a chave pública correspondente no GitHub usando o mesmo processo.

Além disso, se o meu disco rígido ficar vazio, perderei minha chave privada, o que (eu acho) também é indesejável.

Na verdade não; se você perder sua chave privada, basta gerar uma nova e fazer upload da chave pública correspondente.

Pelo que vale, você está certo que duplicar uma chave privada é altamente indesejável. Idealmente, uma chave privada deve ser gerada em um arquivo ( ~/.ssh/id_rsapor exemplo) e nunca deve sair desse arquivo - ou seja, nunca deve ser copiada, movida e, principalmente, não transferida pela rede. (por exemplo, eu os excluo dos backups) Devido à natureza dos protocolos de autenticação assimétricos, você só precisa se preocupar em manter sua chave privada fora do alcance de outras pessoas. Se você exagera um pouco e perde a noção disso, geralmente não é grande coisa. (Isso não deve ser confundido com chaves privadas de criptografia assimétrica , por exemplo, chaves GPG, nas quais você provavelmente deseja se apegar.)

— David Z
fonte

14

Isso funciona apenas se você tiver algum outro método de acessar os servidores aos quais essa chave privada fornece acesso. Você pode carregar a nova chave pública apenas se tiver esse acesso de backup.

— TREE

2

@TREE: certo, mas, na minha experiência, é excepcionalmente raro encontrar um servidor que não forneça algum método alternativo de acesso (ou pelo menos adicione uma chave pública adicional sem passar pelo SSH).

— David Z

3

Obrigado, isso esclarece bastante as coisas. Realmente, perder a chave SSH privada não parece ser um problema, pois para todos os serviços que estou usando, sempre parece haver outra maneira de acessar um serviço para fazer upload de um novo.

— Anton Strogonoff

3

A AWS não fornece nenhuma outra forma de acesso além da chave privada. Você precisa desconectar a unidade e brincar com ela para obter acesso depois de perder sua chave privada.

— Asad Saeeduddin

1

Observe que você pode colocar uma senha em sua chave privada se desejar outra camada de segurança.

— sudo

8

Eu acrescentaria que ~ / .ssh / é legível pelo seu navegador se você estiver usando a mesma conta de usuário para executar os dois.

Tente! Aponte seu navegador para sua chave privada em seu diretório pessoal. É divertido.

Portanto, eu recomendaria armazenar as chaves ssh no diretório inicial de outra conta de usuário.

uma palavra na senha protegendo chaves

Atualmente, a quebra de senhas não aleatórias é super rápida. Confira o hash cat
- (Embora senhas aleatórias e longas com mais de 12 caracteres ainda levem um tempo razoavelmente longo para força bruta)
- Portanto, as chaves ssh criptografadas em AES não podem ser quebradas no futuro próximo, desde que você use boas frases longas. Veja as recomendações do github
Assim, algum site pode adivinhar sua chave sem JavaScript. E então força bruta a chave offline.
E os navegadores também podem ver a área de transferência com JS. Portanto, copiar e colar frases muito longas também coloca em risco os ataques javascript mais sofisticados.

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

— HeyWatchThis
fonte

17

Para ser claro, apenas porque o navegador pode ler sua chave privada, o que não significa que um site em execução no navegador possa.

— Ajedi32

6

Mas, se você injetar um processo no processo do navegador. Então você também pode assumir o controle do navegador. Portanto, esse argumento é perfeitamente válido.

— precisa saber é o seguinte

Mas você precisa hackear o processo que injeta processos no registro de processos da unidade de processamento dos navegadores.

— Skid Kadda

8

Existe uma ferramenta muito legal chamada KeePass2 ( http://keepass.info/ ) com a extensão ( http://lechnology.com/software/keeagent/ )

Você pode armazenar lá senhas, chaves SSH e muito mais (na página oficial do KeePass são extensões muito mais úteis)
Se você quiser fazer login automaticamente com suas chaves SSH, basta instalar o PuTTY, Pageant e KeePass com o KeeAgent. Se você estiver configurando corretamente, não precisará configurar as Chaves no PuTTY, Pageant ou FileZilla.

Eu mesmo uso e estou muito feliz com isso. Eu tenho mais de 30 VPS e servidor raiz com uma certa quantidade de chaves SSH diferentes e a única coisa que tenho a fazer é abrir o KeePass (não é meu principal cofre de senha) e, em seguida, só preciso digitar no console minha senha.

— CentrixDE
fonte

3

Eu recomendaria armazenar chaves privadas:

offline (não na nuvem)
em mais de um lugar
além de tudo relacionado a, por exemplo, uma chave para seus dados criptografados, armazene-os em um local separado dos dados

Eu diria que o melhor lugar seria:

um disco rígido externo
uma tecla flash
um computador não conectado à internet

Melhor ainda, basta imprimi-lo e colocá-lo em um cofre à prova de fogo.

— blá
fonte

4

Segurança / práticas recomendadas trabalham lado a lado com praticidade. Se uma estratégia de segurança prejudicar a capacidade de usar um sistema, ela será ignorada pelo usuário e não pelo invasor.

— ZaTricky 19/07

1

Eu tenho um arquivo tar que possui a minha configuração de diretório de usuário (.bashrc, .ssh / e outros arquivos de configuração) que guardo em um local seguro. Quando recebo uma nova conta shell em qualquer lugar, descompacte o arquivo tar nela.

Você só deve colocar suas chaves privadas nos servidores em que confia, caso contrário, deve criar uma nova chave privada no servidor apenas para esse servidor e permitir o acesso às coisas às quais você deseja ter acesso.

Pessoalmente, eu me sinto confortável apenas copiando meu arquivo .ssh / stuff em todos os lugares (também significa que, por meio da chave ssh comum, obtém acesso ssh instantaneamente, já que ele já está no arquivo allowed_keys).

— EightBitTony
fonte

Eu acho que ter criptografado ~ / .ssh pendurado em um pendrive economizaria a necessidade de gerar e fazer upload de nova chave em caso de falha de hardware. No entanto, como há muito poucos servidores nos quais eu uso chaves SSH para acessar (e poucas máquinas nas quais me conecto), a geração de novas chaves não causará muita sobrecarga.

— Anton Strogonoff

2

É um cavalo para percursos e depende de por que você usa as teclas. Não vejo problema ao copiar uma chave privada ssh por um link SSH já criptografado. Mas se você não confia na máquina de destino e não sabe quem tem acesso root, não deve colocar nada no servidor que não pode perder.

— EightBitTony

Você não deseja colocar sua chave privada no servidor de outra pessoa. Qualquer pessoa com acesso Raiz nesse servidor pode ler sua chave privada e, em seguida, pode se passar por você nos sistemas que você acessa com essa chave privada. Você só deve colocar sua chave pública para acessar o servidor. E não pense que a frase secreta ajuda muito se você a estiver usando em uma máquina remota para descriptografar uma chave privada.

— precisa saber é o seguinte

Você pode encaminhar ssh-agent sobre ssh. Dessa forma, você não precisa armazenar a chave privada no servidor ou enviar sua senha pela rede. stackoverflow.com/questions/12257968/…

— Codeguy007

1

Você pode armazenar suas chaves ssh em um diretório separado dentro de uma partição criptografada. Então você pode usar ssh apontando para esse diretório com -i:

ssh -i identity_file me@example.com

Descrição completa ( man ssh):

-i identity_file

Seleciona um arquivo do qual a identidade (chave privada) para autenticação de chave pública é lida. O padrão é ~ / .ssh / identity para a versão 1 do protocolo e ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 e ~ / .ssh / id_rsa para a versão 2. do protocolo. também deve ser especificado por host no arquivo de configuração.
É possível ter várias opções -i (e várias identidades especificadas nos arquivos de configuração). Se nenhum certificado foi especificado explicitamente pela diretiva CertificateFile, o ssh também tentará carregar as informações do certificado do nome do arquivo obtido anexando -cert.pub aos nomes dos arquivos de identidade.

Minha abordagem à segurança é que eu divido as informações em particular e geral. Não quero criptografar toda a minha partição pessoal, é por isso que copio arquivos secretos (como os que estão dentro ~/.ssh) para uma partição criptografada.

Acho que isso fornece uma segurança bastante eficiente, porque o malware não encontra nada no ~ / .ssh e provavelmente não varrerá todo o seu sistema ou perfis de shell para encontrar esse local.

-F configfile

define o caminho para o arquivo de configuração.

PS: Eu criaria um alias alias ssh='ssh -i ... -F ...'e o colocaria no seu perfil.

PPS Ainda não verifiquei isso e não sei como outros programas (como o git) funcionarão com essas configurações de ssh.

— Yaroslav Nikitenko
fonte