☰

Como organizar chaves SSH?

tag-icon • tag-icon ssh ssh-agent
Como organizar chaves SSH?

Tenho criado várias chaves SSH no Debian para contas diferentes (ou seja, Digital Ocean, GitHub e Bitbucket), mas está ficando confuso muito rapidamente.

Listando o conteúdo da minha pasta .ssh, recebo:

digOcn digOcn.pub github github.pub id_rsa id_rsa.pub

(Eu uso a id_rsachave do Bitbucket.)

Eu faço a eval 'ssh-agent -s'coisa e depois "adiciono" as chaves assim:

  • ssh-add ~/.ssh/github(e depois inserindo a senha)

  • ssh-add ~/.ssh/id_rsa(e depois inserindo a senha)

  • ssh-add ~/.ssh/digOcn(Quando tento adicionar digOcn, aparece "Permissão negada". Não tento sudoevitar bagunçar alguma coisa e também porque as outras chaves não exigiam sudo.)

Aqui está a parte confusa: atuar ssh-add -lme dá isso:

2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 /home/USER/.ssh/id_rsa (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 /home/USER/.ssh/github (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 github (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 USER@COMPUTER_NAME (RSA)

Sim, adicionei chaves SSH no passado, mas não consigo refazer o que fiz. É provavelmente por isso que há ambos/home/USER/.ssh/github e github.

O que eu fiz errado? Como devo organizar minhas chaves SSH?

Responder1

Primeiro, não há nada de errado em usar chaves diferentes para contas diferentes. Isso é um exagero para shells interativos, mas há razões legítimas para fazer isso quando você está lidando com outros serviços não interativos. Por exemplo, há alguns anos, o GitHub começou a permitir chaves SSH mais fortes, enquanto o Bitbucket insistiu em usar chaves mais fracas por mais algum tempo. A ação correta na época foi usar chaves diferentes para acessar o GitHub e o Bitbucket.

Outro exemplo é rsync. Se você estiver usando rsync, por exemplo, para implantar arquivos em um servidor web, provavelmente desejará chaves SSH dedicadas para isso. Eles permitem que você defina permissões diferentes das que normalmente usaria com sua conta interativa.

Voltando à sua pergunta sobre o gerenciamento de múltiplas chaves: o SSH permite definir opções diferentes para destinos diferentes. Para fazer isso você precisa editar um arquivo ~/.ssh/configcomo este:

Host  bitbucket.org
    User                    hg
    IdentitiesOnly          yes
    IdentityFile            /home/user/.ssh/bitbucket

Host  github.com  gist.github.com
    User                    git
    IdentitiesOnly          yes
    IdentityFile            /home/user/.ssh/github

O arquivo ~/.ssh/configdeve ter permissões 0600 (não me lembro agora se isso é imposto por SSH ou não, mas certamente não faz mal).

Você também pode, é claro, usar o mesmo mecanismo para shells interativos, então defina coisas como nome de usuário remoto (se for diferente do local), porta remota, abrevie o nome do host, etc.

Host  sm
    Hostname                sphygmomanometer.example.com
    User                    human
    Port                    2222

Então você pode simplesmente correr

ssh sm

em vez de

ssh -p 2222 [email protected]

Curingas também são permitidos:

Host *
    ControlPath             ~/.ssh/ctl-%u-%r-%h-%p
    ControlMaster           auto
    ControlPersist          5m

Leia o manual para mais detalhes.

Por último, mas não menos importante:não"faça a eval 'ssh-agent -s'coisa". Ao contrário da crença popular, isso tem graves implicações de segurança. A maneira certa de fazer isso é assim:

ssh-agent /bin/bash
ssh-add

(em seguida, insira suas senhas principais quando solicitado). Só isso, não faça chave por tecla, ou de qualquer outra forma.

Isso executa um novo shell no qual suas chaves são carregadas e, quando você deseja revogar o acesso, basta usar exitesse shell. Se você "fizer a eval 'ssh-agent -s'coisa", os agentes de autenticação permanecerão em execução por muito tempo após o logoff e poderão (e eventualmente serão) usados ​​para acesso não autorizado.

Editar:Experimente esta pequena experiência:

  1. eval $(ssh-agent -s)
  2. faça logoff ou mate o terminal
  3. faça login novamente ou abra um novo terminal
  4. pgrep ssh-agent

Ninguém está matando esses ssh-agentprogramas, eles ficam por aí até o próximo reboot, prontos para serem usados ​​pelo malware mais recente.

informação relacionada