Como usar a chave privada SSH para efetuar login sem inserir a senha todas as vezes no Mac OS X Lion?


23

Eu uso o Mac OS X Lion e conecto hosts remotos via SSH todos os dias. Apesar do fato de eu usar o par de chaves SSH para autenticação remota e eu não precisar motorizar a frase de login de cada host, ainda é muito chato que o terminal peça a senha para acessar minha chave privada SSH.

Por razões de segurança, creio que uma senha para acessar a chave privada do SSH é obrigatória. Existe uma maneira que faça com que o terminal peça a frase exatamente uma única vez na inicialização, depois a memorize e automaticamente usando minha chave privada em sessões SSH posteriores?

Existe um script chamado keychainque funciona bem no Gentoo Linux. Mas eu nunca descobri no Mac OS X Lion. Além do mais, existem tantos termos intimidante, tais como ssh-agent, ssh-add. Depois de ler vários materiais sobre esses kits de ferramentas SSH e fazer alguns experimentos frustrados, fiquei mais confuso.

Portanto, cheguei ao StackExchange, procurando alguns conselhos sobre as seguintes perguntas.

  1. O que são ssh-agent, ssh-add, keychain, Keychain Access.appe como eles interagem uns com os outros?
  2. Como posso inserir a frase secreta da minha chave privada SSH uma vez no login e usá-la livremente na criação posterior da sessão SSH?
  3. Errr ... O que há de errado com isso Keychain Access.app? Não armazena a frase SSH como antes.

Eu listo o que fiz aqui. Espero que haja pistas sobre os passos que perdi.

Etapa 1. Crie um par de chaves SSH no meu Mac.

$ ssh-keygen -t rsa -C "me@email.com"
# Set a passphrase for accessing the private key.

Etapa 2. Copie minha chave pública SSH para o host remoto. Para dar um exemplo, copio a chave para localhost, Mac.

$ ssh-copy-id USER@localhost
# Enter the login password for USER at localhost, not my SSH passphrase

Etapa 3. Em seguida, tente conectar-se ao host remoto (host local aqui), via autenticação de par de chaves SSH.

$ ssh USER@locahost
Enter passphrase for key '/Users/YOUR_ACCOUNT/.ssh/id_rsa': 
# Enter my SSH passphrase, not the login password.

Etapa 4. Efetue logout do host remoto e tente conectar-se a ele novamente. Porra, o terminal pede a frase SSH novamente.

Uma pergunta frequente é que "O ssh-agent funciona bem no seu Mac?". Francamente falando, eu não tenho ideia do que está acontecendo nessas coisas. Aqui mostra alguns resultados em execução.

$ echo $SSH_AUTH_SOCK
/tmp/launch-M48niA/Listeners
$ echo $SSH_AUTH_PID
(EMPTY)
$ ssh-add -l
Could not open a connection to your authentication agent.
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-Z54zXukQiP/agent.26769; export SSH_AUTH_SOCK;
SSH_AGENT_PID=26770; export SSH_AGENT_PID;
echo Agent pid 26770;
$ ssh-add -l
Could not open a connection to your authentication agent.
$ echo $SSH_AUTH_SOCK
/tmp/launch-M48niA/Listeners
$ echo $SSH_AUTH_PID
(STILL EMPTY)
$ ssh-agent  # Oh no, anther ssh-agent with different PID
SSH_AUTH_SOCK=/tmp/ssh-cx0B4FUX8B/agent.26898; export SSH_AUTH_SOCK;
SSH_AGENT_PID=26899; export SSH_AGENT_PID;
echo Agent pid 26899;
$ ps -e | grep -i ssh
26769 ??         0:00.03 ssh-agent
26899 ??         0:00.02 ssh-agent

Qualquer feedback é bem-vindo. Obrigado!


Relacionados . É provável que você possa adaptar a resposta aceita para o seu caso de uso.
Daniel Beck

Respostas:


12

ssh-agenté a peça que você quer trabalhar, pois faz exatamente o que você está perguntando. O agente é executado como um daemon e, quando você "adiciona" uma chave privada a ele, ele se lembra dessa chave e a fornece automaticamente ao controle remoto sshddurante a conexão inicial. ( ssh-addé simplesmente o comando que você executa para adicionar manualmente uma chave privada a ssh-agent).

No OS X, a partir do Leopard, você nunca deveria ter que executar ssh-agentou ssh-addmanualmente. Deve "apenas acontecer" quando você tenta se conectar a um servidor. Uma vez por chave, ele solicitará uma caixa de diálogo com a senha da interface do usuário, que (entre outras coisas) permitirá que você adicione automaticamente a chave, para ssh-agentque nunca seja solicitado novamente.

Isso é feito por meio de uma launchdconfiguração que escuta as conexões no $SSH_AUTH_SOCKsoquete e é iniciada automaticamente ssh-agentquando é necessário. depois disso, ssh-agentsolicitará credenciais somente quando precisar abrir uma nova chave.

Se isso não funcionar, verifique se você tem o launchdarquivo de configuração correto presente:

/System/Library/LaunchAgents/org.openbsd.ssh-agent.plist

Se ainda não estiver funcionando para você por algum motivo, aqui está a maneira "antiga" de fazer as coisas correrem à mão:

http://timesinker.blogspot.com/2007/08/getting-ssh-agent-going-on-mac-osx.html

Há também este aplicativo, que eu parei de usar desde que o Leopard saiu, mas basicamente fez a mesma coisa nas versões anteriores do Mac OS X:

http://www.sshkeychain.org/


4
Obrigado, Michael Edenfield. Eu descobri o que está errado e agora o ssh-login-without-passphrase funciona perfeitamente no Mac OS X Lion. Fiz algumas coisas estúpidas - fiz um link simbólico ~/tmpapontando /tmp/e executando um cron job para limpar a ~/tmpcada 2 horas, o que também removeu o soquete ssh-agent. Oh cara, eu me odeio.
Jianwen W.

13

Durante o processo de resolver o "problema", eu pesquisei alguns tópicos relacionados e anotar algumas notas sobre como ssh-agent, ssh-add, keychain, KeyChain Access.apptrabalho. Acontece que este problema não é um problema, em vez disso, o problema é tudo sobre mim, e assim chamado ssh-login-without-ask-passphrase-every-time funciona perfeitamente no Mac fora da caixa.

No entanto, esse processo me traz algumas experiências. Eu escrevo minhas anotações aqui na esperança de que elas ajudem alguém confuso sobre esses termos.

Dois termos de senha:

  • passphrase refere-se à frase requerida ao acessar sua chave privada SSH.
  • password refere-se à frase requerida para efetuar login no seu Mac.

Agora eu posso descobrir o que esses toolkits fazer, isto é, ssh-agent, ssh-add, keychain, Keychain Access.appno Mac.

  • ssh-agenté o serviço crítico para ativar o uso da chave privada SSH sem digitar a senha SSH. ssh-agentfunciona dessa maneira. Primeiro armazena, ou armazena em cache , sua chave privada SSH na memória principal. Então, mais tarde, nesta sessão, quando a sua chave SSH privada SSH for necessária para a autenticação remota, ssh-agentela encontrará sua chave privada na memória principal e a entregará ao processo remoto. A única chance de que você seja solicitado a digitar sua senha SSH é quando sua chave privada é adicionada ssh-agentinicialmente.
  • ssh-addfaz parte da ssh-agentcoleção, o que ajuda a gerenciar suas chaves SSH em ssh-agent. Usamos o ssh-addcomando para listar, adicionar, remover chaves privadas no chaveiro do ssh-agent. Em seguida, ssh-addcomunica-se com o ssh-agentserviço para cumprir as tarefas.
  • keychainé script para encontrar ssh-agentserviço (se não existir, iniciar um novo) e ligar ssh-addpara adicionar chaves privadas SSH. keychaintem uma idéia simples e direta, funcionando bem no Linux, onde o ssh-agent geralmente não é iniciado automaticamente.
  • Keychain Access.appparece ser o componente mais complicado. É o serviço de armazenamento de token universal do Mac OS X. Ele armazena vários tokens, como senhas, certs, et al e serve como um agente de token para os aplicativos que solicitam os tokens. Em nosso caso de chave privada SSH, primeiro ele capta a solicitação para acessar a chave privada SSH e abre uma janela para solicitar que você armazene a senha SSH, que é um tipo de token, no Keychain Access.appchaveiro. Da próxima vez que você for usar chaves privadas para autenticação, Keychain Access.appaparece uma janela novamente, perguntando se está concedendo o privilégio. Depois de receber um grande sim, keychain Access.appadiciona sua chave privada ao ssh-agentarmazenamento.

Duas coisas merecem sua atenção:

  1. O Mac OS X Lion inicia automaticamente um ssh-agentserviço na inicialização, ouvindo em um soquete abaixo /tmp.
  2. Keychain Access.apparmazena sua senha SSH, para que ela possa adicionar sua chave privada ssh-agentsem interrompê-lo. Sim, não é necessário digitar sua frase SSH, mas é necessário digitar a senha de login da sua conta Mac para conceder privilégios ao criar essa entrada pela primeira vez.

Portanto, em resumo, o SSH-login-without-ask-passphrase deve funcionar no Mac OS X fora da caixa.


1

No caso de outras soluções aqui não funcionarem para as pessoas, o seguinte funcionou para mim.

Para cada chave privada em seu diretório ~ / .ssh, certifique-se de que a chave pública correspondente também esteja presente. Certifique-se de que a chave pública tenha o mesmo nome da chave privada, mas .pubno final. Se você já tiver uma chave pública apropriada, tente regenerá-la.

Se você precisar recriar as chaves públicas, poderá fazê-lo facilmente:

ssh-keygen -y -f ~/.ssh/my_key > ~/.ssh/my_key.pub

substituindo my_keycom o que sua chave é chamada.

Depois disso, o MacOS lembra a frase-senha chave no keychain como deveria.

Nota - inserindo a frase secreta e salvando-a, o conjunto de chaves agora é uma ação única (não uma vez por sessão de login, como OP queria), mas assumindo que o login no mac em questão é protegido por senha, sua senha é protegida por essa senha de login. Além disso, esta solução não faz sentido para mim ... uma chave pública não deve ser necessária além da chave privada, mas por algum motivo o MacOSX exige isso.

(originalmente da resposta a uma pergunta semelhante no Apple Stack Exchange)


1

A única coisa que eu raramente encontro mencionado sobre a configuração da ~/.sshpasta é restringir as permissões do diretório.

Para permitir que o ssh evite pedir a senha, sempre tive que definir as permissões do diretório home do usuário 700e as ~/.sshpermissões da pasta 700também.

Caso contrário, ele continuará me pedindo uma senha mesmo quando eu tiver todas as chaves geradas e copiadas corretamente. Uma mensagem de erro é gerada nos logs de autenticação, mas isso é invisível para o usuário final em grande parte.


0

Outra coisa que você poderia ter tentado seria substituir ssh-copy-idpor algo parecido k="$(cat ~/.ssh/id_rsa.pub)"; ssh username@somehost.com "umask 0077; mkdir -p ~/.ssh; echo "$k" >> ~/.ssh/authorized_keys2".


0

Esta resposta é ligeiramente não a solução para esta questão; no entanto, é muito próximo (acabei nesta questão enquanto procurava uma solução para o meu problema).

Eu também faço um monte de SSH para servidores remotos no meu Mac, como descrito nesta pergunta, no entanto, o Keychain Access.appaplicativo armazenou o keyphrase e eu não preciso digitá-lo toda vez que eu preciso da chave para autenticar em um servidor SSH.

No entanto, eu habilitei o servidor SSH no meu Mac, para que eu possa me conectar a ele remotamente. Quando conectado remotamente no meu Mac, a frase sempre foi perguntada quando eu queria SSH ainda outro host.

Eu encontrei uma solução que permite que o keyphrase seja armazenado para a sessão atual. Eu pensei que isso poderia ser útil para alguém, daí este post / resposta.


Eu escrevi a minha solução semelhante aqui superuser.com/a/659668/154113
orkoden

0

Eu tenho me intrigado com esse problema. O ssh funciona para todas as máquinas do nosso departamento EXCETO para maçãs (MacBooks ou iMacs não importam). Eu finalmente me cansei de digitar as senhas e resolvi depurar isso.

Fui ao meu iMac e desabilitei o sshd no painel de preferência de compartilhamento. Eu então su'ed para root, e digitei "/ usr / sbin / sshd -d" para ativar o sshd no modo de depuração. Eu então tentei o ssh para aquela máquina e ela prontamente tentou usar o protocolo 2, o qual tudo parece usar muito bem, mas o sshd prontamente informou que não conseguiu encontrar "authorized_keys". Eu tinha um arquivo authorized_keys2 que todas as minhas caixas Linux, solaris, you-name-it unix aceitam muito bem. Eu simplesmente copiei authorized_keys2 para authorized_keys e BOOM. Funciona perfeitamente agora.

Por que * keys em vez de * keys2 é desconhecido. Particularmente quando o os x está satisfeito com o known_hosts2.

De qualquer forma, agora todas as nossas caixas de maçã podem estar conectadas ou ter comandos remotos executados nelas sem essa senha explodida: prompt ...

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.