Como posso executar o ssh-add automaticamente, sem um prompt de senha?

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 frase-senha deve ser inserida toda vez que a chave for usada para autenticação. Embora seja a melhor opção do ponto de vista de segurança, ela oferece a pior usabilidade. Isso também pode fazer com que uma frase secreta fraca seja escolhida para diminuir o fardo de digitá-la repetidamente.

chave ssh com frase secreta, com ssh-agent

Adicionar o seguinte a ~/.bash_profile iniciará automaticamente ssh-agent e carregue a (s) chave (s) ssh no login:

if [ -z "$SSH_AUTH_SOCK" ] ; then eval `ssh-agent -s` ssh-add fi 

Agora, a senha deve ser inserida a cada Conecte-se. Embora um pouco melhor do ponto de vista da usabilidade, tem a desvantagem de ssh-agent solicitar a senha, independentemente de a chave ser usada ou não durante a sessão de login. Cada novo login também gera uma instância ssh-agent distinta que permanece em execução com as chaves adicionadas na memória mesmo após o logout, a menos que seja explicitamente eliminado.

Para matar ssh_agent ao sair, adicione o seguinte a ~/.bash_logout

if [ -n "$SSH_AUTH_SOCK" ] ; then eval `/usr/bin/ssh-agent -k` fi 

ou o seguinte a ~/.bash_profile

trap "test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`" 0 

A criação de várias ssh-agent instâncias pode ser evitada por criar um soquete de comunicação persistente para o agente em um local fixo no sistema de arquivos, como na resposta de Collin Anderson . Esta é uma melhoria em relação à geração de vários agentes instâncias, no entanto, a menos que explicitamente eliminado, a chave descriptografada ainda permanece na memória após o logout.

Em desktops, ssh-agents incluídos no ambiente de desktop, como Agente SSH do Gnome Keyring , pode ser uma abordagem melhor, pois normalmente podem ser feitos para solicitar o passe frase na primeira vez que a chave ssh é usada durante uma sessão de login e armazena a chave privada descriptografada na memória até o final da sessão.

ssh- chave 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 as chaves apenas uma vez conforme são necessárias, independentemente de quantos terminais, ssh ou sessões de login que requerem acesso a um ssh-agent. Ele 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 do qual o ssh é chamado. Isso permite o isolamento de chaves ao usar o encaminhamento de agente com hosts diferentes. Também permite o uso de 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 que ssh-agent permaneça em execução quando a sessão de login termina. Nos logins subsequentes, keychain se conectará à instância ssh-agent existente. Na prática, isso significa que a senha deve ser inserida apenas durante o primeiro login após uma reinicialização. Em logins subsequentes, a chave não criptografada da instância ssh-agent existente é usada.Isso também pode ser útil para permitir autenticação RSA / DSA sem senha em cron jobs sem ssh-keys sem senha.

Para habilitar keychain, instale-o e adicione algo como o seguinte em ~/.bash_profile:

eval `keychain --agents ssh --eval id_rsa` 

De um ponto de segurança de view, ssh-ident e keychain são piores do que ssh-agent instâncias limitadas ao tempo de vida de um determinado sessão, mas oferecem um alto nível de conveniência. Para melhorar a segurança de keychain, algumas pessoas adicionam a opção --clear ao seu chaveiro ~/.bash_profile invocação. Ao fazer isso, as frases de acesso devem ser inseridas novamente no login como acima, mas cron as tarefas ainda terão acesso às chaves não criptografadas depois que o usuário fizer logout. A keychain página wiki tem mais informações e exemplos.

ssh-key sem senha

Do ponto de vista de segurança, esta é a pior opção, pois a chave privada é totalmente desprotegida caso seja está exposto. No entanto, esta é a única maneira de garantir que a senha não precise ser inserida novamente após uma reinicialização.

chave ssh com senha, com ssh-agent, passando a senha longa para ssh-add do script

Embora possa parece uma ideia simples passar a frase secreta para ssh-add a partir de um script, por exemplo echo "passphrase\n" | ssh-add, isso não é tão direto quanto parece como ssh-add não lê o senha longa de stdin, mas abre /dev/tty diretamente para leitura .

Isso pode ser contornado com expect , uma ferramenta para automatizar formulários. Abaixo está um exemplo de um script que adiciona uma chave ssh usando uma senha longa 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 simples em o script, de uma perspectiva de segurança, dificilmente é melhor do que ter uma chave ssh sem senha. Se essa abordagem for usada, é importante certificar-se de que o script expect que contém a frase secreta tenha as permissões adequadas definidas, tornando-a legível, gravável e executável apenas pela chave proprietário.

Comentários

• Tudo bem, mas quando coloco seu código em ~ / .bash_profile, preciso digitar a senha toda vez que faço o login, não ‘ não quero isso também. Não estou nem um pouco preocupado com a segurança. echo ” pass \ n ” | ssh-add não ‘ não funciona
• @ user1607072 Sim, é assim que o ssh-agent snippet em ~/.bash_profile se comporta conforme explicado na resposta. Você pode querer dar uma olhada no utilitário keychain. Com keychain, você precisa inserir a senha no primeiro login após a reinicialização, mas nos logins subsequentes keychain se conectará a um ssh-agent com a chave descriptografada na memória. Além disso, há ‘ s a opção de gerar uma chave ssh sem uma senha longa, mas isso obviamente não é recomendado.
• @ user1607072 Embora eu recomende fortemente Para sugerir uma das abordagens mais seguras, existe uma maneira de passar a frase secreta para ssh-add a partir de um script. O motivo pelo qual echo "pass\n" | ssh-add não funciona é que ssh-add não lê a senha de stdin, mas abre /dev/tty diretamente para leitura. A resposta foi atualizada para incluir uma solução alternativa para isso, usando um utilitário chamado expect.
• @ user1607072 Pode ser um pouco exagero para o seu caso de uso, mas Kerberos em combinação com o suporte ssh GSSAPI também pode ser usado para logins ssh sem senha. O método de autenticação correspondente em ssh é denominado gssapi-with-mic. Isso geralmente é usado em redes maiores, mas é claro que se você tiver interesse nisso, pode valer a pena dar uma olhada.
• @ErickBrown: Já respondido aqui . A unidade do Agente SSH deve ser interrompida no logout se você tiver o usuário lingering desativado no gerenciador de login systemd . Se a demora do usuário estiver ativada, a instância do usuário systemd e a unidade do Agente SSH são mantidas em execução mesmo após o último login ser fechado.

Adicione ao seu ~/.bashrc e saia e voltar a fazer efeito.

 if [ ! -S ~/.ssh/ssh_auth_sock ]; then eval `ssh-agent` ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock fi export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock ssh-add -l > /dev/null || ssh-add  

Isso deve solicitar apenas uma senha na primeira vez que você fizer login após cada reinicialização. Ele continuará a reutilizar o mesmo ssh-agent enquanto continuar em execução.

Comentários

• muito legal , desta forma, você só tem um agente ssh em execução (: vários agentes como em @thomasNyman ‘ s segunda solução parece um risco de segurança para mim …
• Depois de pesquisar em vários sites e ler várias soluções, este aqui parece ser o mais claro, direto ao ponto. Muito bom. +1
• melhor fazer isso: `alias ssh = ssh-check-agent “, e faça com que a versão do agente de verificação faça o acima. Dessa forma: a) você só obtém um agente eb) você só obtém o agente se precisar
• Acho que -s é o padrão, então ‘ já estamos fazendo isso.
• Observe que ssh-add sem argumentos adiciona ~/.ssh/id_rsa. Você pode querer passar ssh-add argumentos se suas chaves privadas estiverem em outro arquivo.

Não intimamente relacionado à pergunta do OP, mas pode ser útil para outros: desde 7.2.0 ssh (1) tem uma opção que permite adicionar uma chave ao ssh-agent na primeira autenticação; a opção é AddKeysToAgent e pode ser definida como yes, no, ask ou confirm, em todo o sistema ou em seu arquivo .ssh/config pessoal.

Referência : https://www.openssh.com/txt/release-7.2

Comentários

• Aplicável a quem é novo no arquivo .ssh/config: aplica-se a ssh e a qualquer coisa que use ssh por trás dele, por exemplo scp, e pode ser feito por host.
• Ele ainda me pede a senha cada vez que eu logo e tento fazer o git pull, por exemplo.
• @trainosis O problema é que você provavelmente não tem uma instância do agente ssh em execução para manter a (s) chave (s) descriptografada (s) na memória para uso futuro. Você só deve precisar inserir a senha para uma determinada chave uma vez por sessão de login ao usar o agente ssh.

ssh-agent armazena em cache várias ssh-keys desbloqueadas, então você pode ter ssh-keys protegidas por senhas, mas sem ter que digitá-las todas as vezes.

Para armazenar as chaves desbloqueadas em cache, obviamente é necessário desbloquear essas chaves. Para desbloquear chaves que estão bloqueadas com uma frase-senha, obviamente precisa saber essas frases-senha.

Qualquer método que não requeira a autorização de um ser humano (por exemplo, “digitar uma senha”) não fará apenas sistema inseguro; isso também tornará todo o propósito do agente ssh sem sentido.

Tendo dito tudo isso, você pode simplesmente usar as chaves ssh que não são protegidas por senha (pressione Enter quando solicitado para uma senha durante a geração da chave). Como não há nenhuma senha, ssh-agent não precisa pedir uma para (não) armazená-la em cache.

Comentários

• Eu concordo, contanto que suas chaves tenham permissão somente para o usuário, há pouca vantagem em ssh-agent sobre chaves sem permissão. Eu gosto de fazer SSH em um servidor de login, e então, esse servidor tem um monte de chaves sem permissão, cada uma das quais só pode ser usada para desbloquear outro servidor. o servidor de login não faz mais nada, então ‘ é muito mais difícil de hackear / falsificar, etc … os outros servidores não têm acesso por senha, são apenas chaves.

Aqui está uma solução alternativa para automatizar sua senha longa SSH.

1. Crie um script de uma linha que imprima sua senha longa na saída padrão, por exemplo:

    echo "echo MY_SSH_PASSWORD" > ~/.print_ssh_password && chmod 700 ~/.print_ssh_password 

   Importante: certifique-se de você copia o espaço inicial para evitar o armazenamento de sua senha em seu histórico .

E use um dos métodos abaixo.

• usando uma abordagem de entrada padrão:

  cat ~/.ssh/id_rsa | SSH_ASKPASS=~/.print_ssh_password ssh-add - 

• ou abordagem de pipe nomeado :

  1. Crie um pipe nomeado (você também pode tentar uma substituição de processo ):

     mkfifo --mode 0600 ~/.ssh_fifo 

  2. Execute ssh-add especificando o programa usado para a autenticação:

     cat ~/.ssh/id_rsa >~/.ssh_fifo | SSH_ASKPASS=~/.print_ssh_password ssh-add ~/.ssh_fifo 

  Veja: man ssh-add para ler mais sobre SSH_ASKPASS.

Comentários

• O echo my_passphrase é uma grande falha de segurança. Primeiro, depois de digitada, a senha está em texto não criptografado no arquivo de histórico de qualquer shell que você usar. E os argumentos da segunda linha de comando podem ser lidos por todos no Unix (ps -ef). Nunca coloque senhas em argumentos de linha de comando!
• @ceving Adicionar espaço extra à esquerda resolve o problema com o arquivo de histórico. Adicionadas informações extras.
• @kenorb: Isso não ‘ resolve o problema maior da senha visível em ps resultado. O arquivo de histórico normalmente só pode ser lido pelo usuário proprietário, mas as linhas de comando podem ser lidas por todos os usuários em um sistema.

Não vou recomendar que você ssh-add (que precisa abrir um ssh-agent) no login. Isso ocorre porque você não pode controlar quando a seção ssh-agent termina e pode criar risco de segurança quando você não precisa usar os arquivos de chave em uma seção de login.

Em vez disso, eu recomendo escrever um script que abre um sub-shell de seção do agente ssh, com todos os arquivos de chave adicionados automaticamente, e ser chamado quando precisava usar ssh. Se você pudesse adotá-lo, continue lendo.

Você teria duas opções:

1. Remova todas as senhas de suas chaves, que têm segurança fraca se seus arquivos de chave forem roubados. (portanto, não recomendado )

2. Use a mesma senha longa para as suas chaves. Então, quando você ssh-add keyfile1 keyfile2 ..., precisará digitar a senha apenas uma vez, por seção.

Em ambos os casos, você poderia escrever o arquivo de script “ssh_keys_section.sh” conforme abaixo:

#!/bin/bash # This script run a ssh-agent on a sub-shell and automatically ssh-add all keyfiles at once. # This agent ends when you type `exit` to close the sub-shell. exec ssh-agent bash -c "ssh-add /path/to/keyfile1 /path/to/keyfile2 ...; exec bash" 

Observações:

• Comando para alterar ou excluir a senha longa: ssh-keygen -p -f keyfile
• Dentro do sub-shell, você pode até mesmo bifurcar mais terminais que compartilham o mesmo chaves desbloqueadas, usando talvez um comando como /path/to/yourterminal & (depende do sistema operacional)

Comentários

• Ex. No Windows com Cygwin, /path/to/yourterminal & == > mintty &
• Observação: após o uso, feche a sessão com ctrl-d ou exit, assim como você invocou um bash shell e precisa fechá-lo.

if [ ! -S ${HOME}/.ssh/ssh_auth_sock ]; then eval $(ssh-agent) ln -sf "${SSH_AUTH_SOCK}" ${HOME}/.ssh/ssh_auth_sock fi export SSH_AUTH_SOCK=${HOME}/.ssh/ssh_auth_sock ssh_keys=$(find -E ~/.ssh -type f -regex ".*(rsa$|pem)") ssh_agent_keys=$(ssh-add -l | awk "{key=NF-1; print $key}") for k in "${ssh_keys}"; do for l in "${ssh_agent_keys}"; do if [[ ! "${k}" = "${l}" ]]; then ssh-add "${k}" > /dev/null 2>&1 fi done done 

Eu costumava usar o script mencionado por Steampowered, fiz o seguinte agora, porque ele não sai de arquivos mentindo.

Trabalhando em zsh somente shell.

#!/usr/bin/env zsh AGENT_BIN=`which ssh-agent` AGENT_ADD_BIN=`which ssh-add` AGENT_PID=`ps -fe | grep ${AGENT_BIN} | awk -vuser=$USER -vcmd="$AGENT_BIN" "$1==user && $8==cmd{print $2;exit;}"` if [ -z "$AGENT_BIN" ]; then echo "no ssh agent found!"; return fi if [ "" -eq "$AGENT_PID" ]; then if read -sq "YN?Do you want to unlock your ssh keys?"; then echo "" output=`$AGENT_BIN | sed "s/echo/#echo/g"` eval $output $AGENT_ADD_BIN fi else for f in "/proc/"* do cmdline=`cat "$f/cmdline"` if [ "${AGENT_BIN}" -ef "${cmdline}" ]; then export SSH_AUTH_SOCK=`cat $f/net/unix | grep --binary-file=text -oP "((/[^/]*?)+/ssh-[^/]+/agent\.\d+$)"` export SSH_AGENT_PID=${f##*/} break; fi done fi 

Comentários

• ” Trabalhando shell zsh apenas “, ok, mas por que sua linha shebang informa que requer apenas ” sh “?

Se estiver executando o Seahorse como gerenciador de senhas … O que você provavelmente é; D

Outra solução que atinge o objetivo que você está procurando é simplesmente adicionar as chaves ssh ao seahorse para desbloqueio automático após o login . O principal benefício disso é que você nunca precisa inserir uma senha para as chaves após fazer o login através do gdm, ou qualquer que seja o seu login, mesmo que as chaves tenham uma senha. Isso REQUER a chave privada e a chave pública. Eles também DEVEM seguir uma convenção de nomenclatura para cavalos-marinhos. O padrão é aceitável (id_rsa para chave privada e id_rsa.pub para chave pública … Realmente qualquer coisa que seja privatekeyname e privatekeyname.pub )

Para adicionar sua chave ssh ao cavalo marinho para desbloqueio automático após o login; (no fedora25, não tenho certeza de onde está o caminho em outras distros, embora seja provavelmente muito semelhante)

/lib64/seahorse/seahorse-ssh-askpass /path/to/keys/here 

Para mim, era

/lib64/seahorse/seahorse-ssh-askpass ~/.ssh/id_rsa 

(o cavalo-marinho assumirá automaticamente que a chave pública no meu caso era id_rsa.pub)

Depois de executar o comando, o cavalo-marinho abrirá um fofo campo de senha gtk para inserir a senha da chave privada em. ou apenas deixe-o em branco se você gerou a chave sem uma senha.

O Seahorse não irá avisá-lo se tudo correr bem. Você precisará tentar fazer o ssh na máquina de destino.Em seguida, o cavalo-marinho solicitará que você desbloqueie a chave graficamente com uma senha (ISSO SÓ ACONTECERÁ UMA VEZ) novamente, mas deve parecer um pouco diferente desta vez; P (esta também é a parte em que o cavalo marinho faz um cavalo-marinho para adicionar magia de ssh, eu acredito ) e oferecer a OPÇÃO para desbloquear a chave após o login, você deve marcar esta opção para alcance seu objetivo.

Só porque não li todas as respostas, recomendo desfazer o que todos disseram a você para fazer com ssh-add antes de tentar esta resposta. Caso contrário, pode resultar em algo ruim acontecendo às suas chaves, idk.

A solução de logon único para SSH pode me levar a pam_ssh .

De acordo com este artigo , o conceito é:

Se você trabalha com várias máquinas baseadas em * nix via ssh, provavelmente está cansado de contras constantemente ter que digitar sua senha toda vez que quiser acessar outra caixa. Existe uma maneira segura de permitir que você acesse todas as máquinas às quais você tenha acesso ssh, sem precisar inserir outra senha (diferente daquela com a qual você se inscreveu originalmente).

Isso é bem simples de fazer, você basicamente cria um par de chaves pública / privada para se autenticar em outras máquinas e, em seguida, O PAM gera um agente para carregar suas chaves após o logon, fornecendo uma solução de logon único para acessar todas as suas máquinas remotas. Este guia o orientará na configuração.

Não verifiquei se isso realmente funcionaria.

Adicione ao seu ~/.bashrc arquivo:

ssh-add -L|grep identities > /dev/null && ssh-add /path/to/ssh/private/key 

Comentários

• Não ‘ não vejo como isso se relaciona com a pergunta, que é sobre não ser solicitada a senha nos logins subsequentes.

Para adicionar uma chave (possivelmente sem senha) e garantir que ssh-add não solicitará uma senha, não importa o que aconteça, mesmo quando executado em X :

DISPLAY= ssh-add -k /path/to/key </dev/null &>/dev/null 

O status de saída indica sucesso ou falha.

Aqui está o definitivo roteiro.

Atualize $ PASSW e copie e cole em seu Terminal

# <sshpass> via typinator # Updated: 2017-01-18_21h36 # # apt-get update -y; apt-get install expect -qy # Pass this value to ssh-add PASSW="myfancypass123" # Define a name for this script THIS_SCRIPT="$(date +%Y-%m-%d_%H-%M-%S-%N)".sh # Create a fresh directory to work from / Clean up rm -rf ~/temp; mkdir -p ~/temp; cd ~/temp; ls -la # Output our bash script file - BEGIN cat <<< " #!/bin/bash set -u # Stop if an unbound variable is referenced set -e # Stop on first error export HISTIGNORE="expect*"; # Normal CMDs echo && echo "The process should take about 10 seconds:" && echo eval "$(ssh-agent -s)"; sleep 0.5; # Define VAR passed when this bash-script was launched password="$@" # Launch the expect magic expect -c " spawn ssh-add /root/.ssh/id_rsa expect "?assword:" send \"$password\r\" expect "?password:" send \"$password\r\" expect eof" export HISTIGNORE=""; export password=""; " > $THIS_SCRIPT # Output our bash script file - END # Ensure we are in the right path cd ~/temp; ls -la; sleep 1; # Run the bash script chmod +x ./$THIS_SCRIPT; ./$THIS_SCRIPT "$PASSW"; unset password; # Clean up rm -rf ~/temp; mkdir -p ~/temp; cd ~/temp; ls -la 

A melhor maneira que conheço é usar um script de login do PAM que adaptei de trabalhos anteriores porque não consegui encontrar uma resposta satisfatória para esta pergunta.

Sua senha é armazenado criptografado com a senha do sistema e uma função de derivação pesada. No login, a senha do sistema é usada para descriptografar a senha e adicioná-la ao agente.

https://github.com/capocasa/systemd-user-pam-ssh

A vantagem sobre todas as outras soluções apresentadas é que ela combina segurança equivalente à execução manual de ssh-add na inicialização sem esforço. sem ferramentas extras e tem uma dependência extra que já está instalada por padrão na maioria dos sistemas (OpenSSL).

Meu a configuração no macOS é a seguinte (em .zshrc ou .bash_profile para o pessoal do bash):

A parte || [[ $SSH_AUTH_SOCK == *"/private/tmp/"* ]] é necessária no macOS porque o valor padrão é /private/tmp/com.apple.launchd.SOMETHINGHERE/Listeners. Caso contrário, a resposta abrangente de @Thomas Nyman falha porque $SSH_AUTH_SOCK é sempre definido como algo.

Então, em .zlogout (ou .bash_logout para o pessoal do bash):

if [ -n "$SSH_AUTH_SOCK" ] ; then eval `/usr/bin/ssh-agent -k` fi 

Testado no macOS Mojave 10.14.5

Isso foi muito bem explicado pelo GitHub em Iniciando automaticamente o agente ssh no Git para Windows , que por sua vez também funciona para Linux.

Você pode executar ssh-agent automaticamente ao abrir o bash ou o Git shell. Copie as seguintes linhas e cole-as em seu arquivo ~/.profile ou ~/.bashrc no shell do Git:

 env=~/.ssh/agent.env agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; } agent_start () { (umask 077; ssh-agent >| "$env") . "$env" >| /dev/null ; } agent_load_env # agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?) if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then agent_start ssh-add elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then ssh-add fi unset env  

Se sua chave privada não estiver armazenada em um dos locais padrão (como ~/.ssh/id_rsa), você precisará informar ao seu agente de autenticação SSH onde encontrá-lo. Para adicionar sua chave ao ssh-agent, digite ssh-add ~/path/to/my_key.

Dica: Se desejar ssh-agent esqueça sua chave depois de algum tempo, você pode configure-o para fazê-lo executando ssh-add -t <seconds>.