☰

Existe uma maneira de o ssh oferecer mais chaves para login automaticamente?

tag-icon • tag-icon ssh login
Existe uma maneira de o ssh oferecer mais chaves para login automaticamente?

Aprendi em inúmeras fontes on-line que (aproximadamente), para fazer login em um servidor remoto sem senha: gere uma chave ssh, coloque a versão pub emauthorized_keys no sistema remoto; coloque a versão privada em seu diretório local ~/.ssh/; chmod para 0600 e poof, você está dentro. Embora isso esteja correto, acho que a chave (par) deve ser nomeada id_rsa (id_rsa.pub) ou id_dsa (id_dsa.pub) para que o SSH a ofereça ao controle remoto servidores.

Deixe-me voltar um pouco. Eu tenho um login SurnameGno meu Mac local. Eu tenho uma conta SurnameG em um sistema remoto, outro servidor.

Copiei o conteúdo ~/.ssh/surnameg.pubpara /home/surnameg/.ssh/authorized_keys desse sistema. Eu testei com a -iopção do meu Mac para ssh e funciona bem.

Eu tenho um ~/.ssh/id_rsa(que gerei para usar comgithub.com).

E claro, tenho ~/.ssh/surnamege até algumas outras chaves aí, que não estão sendo "tentadas" quando tento fazer o login da seguinte forma paraoutroservidor.com:

ssh 1.2.3.4

Aqui, estou tentando usar SurnameG(o usuário logado local atual) para fazer login na minha SurnameGconta nooutro servidor. Estou querendo que o openssh ofereça ~/.ssh/surnamegem sua tentativa de conexão, mas isso não acontece - vamos dar uma olhada mais de perto na opção detalhada:

BOX:~ SurnameG$ ssh -v 1.2.3.4
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/SurnameG/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 1.2.3.4 [50.112.132.124] port 22.
debug1: Connection established.
debug1: identity file /Users/SurnameG/.ssh/id_rsa type 1
debug1: identity file /Users/SurnameG/.ssh/id_rsa-cert type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA ax:64:3e:4a:e3:2c:e4:30:dd:36:a4:a0:9x:fa:ba:6b
debug1: Host '1.2.3.4' is known and matches the RSA host key.
debug1: Found key in /Users/SurnameG/.ssh/known_hosts:88
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/SurnameG/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /Users/SurnameG/.ssh/id_dsa
debug1: No more authentication methods to try.

Curiosamente, o openssh oferece apenas ~/.ssh/id_rsa, mas isso não é tudo. Ele "tenta" ~/.ssh/id_dsa também? Não tenho certeza da diferença entre os dois (oferecer versus tentar). De qualquer forma, se estou lendo corretamente, o openssh nunca tenta nenhuma das minhas outras chaves privadas no ~/.ssh/*.

Ok, eu sei que posso descrever explicitamente cada servidor ~/.ssh/configcom algo como

Host otherserver
   HostName 1.2.3.4
   User surnameg
   IdentityFile ~/.ssh/surnameg

e depois faça login com

ssh otherserver

e isso é bom e elegante e funciona muito bem. Mas, realmente, meu ~/.ssh/config está ficando pesado. Infelizmente não o fiz cd ~/.ssh && git inithá muito tempo. Mas eu discordo.

Minha pergunta é a seguinte: existe uma maneira mais simples, rápida e automatizada de fazer com que o ssh tente mais chaves no diretório ~/.ssh dinamicamente ao tentar logins ou está editando seu ~/.ssh/config para cada servidor que você precisa conectar-se à única maneira de configurar o ssh? Eu entendi mal alguma coisa acima sobre como o SSH deve funcionar?

Responder1

Se você quiser oferecer as mesmas chaves para todos os hosts, carregue-as em um agente SSH usando ssh-add. Muitas distribuições Linux iniciam uma automaticamente – tente ssh-add -lverificar se ela está rodando e depois carregue suas chaves:

ssh-add ~/.ssh/id_rsa ~/.ssh/surnameg etc.

Se o agente não foi iniciado automaticamente, coloque o seguinte no seu ~/.profile:

agent_running() {
    [ "$SSH_AUTH_SOCK" ] && { ssh-add -l >/dev/null 2>&1 || [ $? -eq 1 ]; }
}

env=~/.ssh/agent.env
if ! agent_running && [ -s "$env" ]; then
    . "$env" >/dev/null
fi
if ! agent_running; then
    ssh-agent >"$env"
    . "$env" >/dev/null
    ssh-add ~/.ssh/id_*
fi    
unset env

Responder2

Existe outra abordagem possível. Você pode usar espaços reservados na IdentityFileopção em ssh_config. Conformeman ssh_config:

  • %d—diretório inicial do usuário local
  • %u—nome de usuário local
  • %l—nome do host local
  • %h—nome do host remoto
  • %r—nome de usuário remoto

Eu uso assim (no ssh_configarquivo global):

IdentityFile ~/.ssh/%r@%h

Isso significa que meus arquivos de chave privada são nomeados como [email protected].

informação relacionada