Este é um exemplo típico de uma troca entre segurança e conveniência. Felizmente, existem várias opções. A solução mais apropriada depende do cenário de uso e do nível de segurança desejado.
chave ssh com senha, não ssh-agent
Agora a senha deve ser inserida toda vez que a chave é usada para autenticação. Embora essa seja a melhor opção do ponto de vista de segurança, ela oferece a pior usabilidade. Isso também pode levar à escolha de uma frase secreta fraca para diminuir o fardo de inseri-la repetidamente.
chave ssh com senha, com ssh-agent
Adicionar o seguinte a ~/.bash_profile
iniciará automaticamente ssh-agent
e carregará as teclas ssh no login:
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent -s`
ssh-add
fi
Agora, a senha deve ser inserida em cada login. Embora um pouco melhor do ponto de vista da usabilidade, isso tem a desvantagem que ssh-agent
solicita a senha, independentemente de a chave ser usada ou não durante a sessão de login. Cada novo login também gera uma ssh-agent
instância distinta que permanece sendo executada com as chaves adicionadas na memória, mesmo após o logout, a menos que seja explicitamente eliminado.
Para interromper o ssh_agent
logout, adicione o seguinte a~/.bash_logout
if [ -n "$SSH_AUTH_SOCK" ] ; then
eval `/usr/bin/ssh-agent -k`
fi
ou o seguinte para ~/.bash_profile
trap 'test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`' 0
É ssh-agent
possível evitar a criação de várias instâncias criando um soquete de comunicação persistente para o agente em um local fixo no sistema de arquivos, como na resposta de Collin Anderson . Essa é uma melhoria em relação à criação de várias instâncias de agentes, no entanto, a menos que a chave descriptografada seja eliminada explicitamente e ainda permaneça na memória após o logout.
Nas áreas de trabalho, os ssh-agents incluídos no ambiente da área de trabalho, como o Agente SSH do Gnome Keyring , podem ser uma abordagem melhor, pois normalmente podem ser feitos para solicitar a senha na primeira vez que a chave ssh é usada durante uma sessão de login e armazene a chave privada descriptografada na memória até o final da sessão.
chave ssh com senha, com ssh-ident
ssh-ident
é um utilitário que pode gerenciar ssh-agent
em seu nome e carregar identidades conforme necessário. Ele adiciona chaves apenas uma vez, conforme necessário, independentemente de quantos terminais, ssh ou sessões de login que requerem acesso a um ssh-agent
. Também pode adicionar e usar um agente diferente e um conjunto diferente de chaves, dependendo do host ao qual está conectado ou do diretório em que o ssh é chamado. Isso permite isolar chaves ao usar o encaminhamento de agente com hosts diferentes. Também permite usar várias contas em sites como o GitHub.
Para habilitar ssh-ident
, instale-o e adicione o seguinte alias ao seu ~/bash_profile
:
alias ssh='/path/to/ssh-ident'
chave ssh com senha, com keychain
keychain
é um pequeno utilitário que gerencia ssh-agent
em seu nome e permite ssh-agent
que permaneça em execução quando a sessão de login terminar. Nos logins subsequentes, keychain
será conectado à ssh-agent
instância existente . Na prática, isso significa que a senha deve ser inserida apenas durante o primeiro login após uma reinicialização. Nos logons subseqüentes, a chave não criptografada da ssh-agent
instância existente é usada. Isso também pode ser útil para permitir a autenticação RSA / DSA cron
sem senha em trabalhos sem chaves ssh sem senha.
Para habilitar keychain
, instale-o e adicione algo como o seguinte a ~/.bash_profile
:
eval `keychain --agents ssh --eval id_rsa`
Do ponto de vista da segurança, ssh-ident
e keychain
são piores do que ssh-agent
casos limitados ao tempo de vida de uma sessão particular, mas eles oferecem um alto nível de conveniência. Para melhorar a segurança de keychain
, algumas pessoas adicionam a --clear
opção à sua ~/.bash_profile
chamada de chaveiro. Ao fazer isso, as frases de acesso devem ser digitadas novamente no login, conforme descrito acima, mas os cron
trabalhos ainda terão acesso às chaves não criptografadas após o logout do usuário. A keychain
página wiki tem mais informações e exemplos.
chave ssh sem senha
Do ponto de vista da segurança, essa é a pior opção, pois a chave privada é totalmente desprotegida caso seja exposta. Essa é, no entanto, a única maneira de garantir que a senha não precise ser digitada novamente após uma reinicialização.
ssh-key com senha, com ssh-agent
, passando senha para a ssh-add
partir do script
Embora possa parecer uma idéia simples passar a senha ssh-add
de um script, por exemplo echo "passphrase\n" | ssh-add
, isso não é tão direto quanto parece ssh-add
não ler a senha stdin
, mas é aberto /dev/tty
diretamente para leitura .
Isso pode ser contornado com expect
uma ferramenta para automatizar aplicativos interativos. Abaixo está um exemplo de script que adiciona uma chave ssh usando uma frase secreta armazenada no script:
#!/usr/bin/expect -f
spawn ssh-add /home/user/.ssh/id_rsa
expect "Enter passphrase for /home/user/.ssh/id_rsa:"
send "passphrase\n";
expect "Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)"
interact
Observe que, como a senha é armazenada em texto sem formatação no script, do ponto de vista da segurança, isso não é melhor do que ter uma chave ssh sem senha. Se essa abordagem for usada, é importante garantir que o expect
script que contém a frase secreta tenha permissões adequadas definidas, tornando-a legível, gravável e executável apenas pelo proprietário da chave.