Como organizar as chaves SSH?

Question

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

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

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

(eu uso a tecla id_rsa para o Bitbucket.)

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

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

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

• ssh-add ~/.ssh/digOcn (quando tento adicionar digOcn , ele diz "Permissão negada". Eu não tento sudo para evitar mexer em algo e também porque as outras chaves não precisaram de sudo .)

Aqui está a parte confusa: executar ssh-add -l me 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á tanto /home/USER/.ssh/github quanto github .

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

    

Answer 1

Primeiro, não há nada de errado em usar chaves diferentes para contas diferentes. Isso é muito exagerado para shells interativos, mas existem 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 strongs, enquanto o Bitbucket insistia em usar as mais fracas por mais algum tempo. A ação correta no momento era usar chaves diferentes para acessar o GitHub e o Bitbucket.

Outro exemplo é rsync . Se você estiver usando rsync para, digamos, implantar arquivos em um servidor da Web, provavelmente precisará de chaves SSH dedicadas para isso. Eles permitem que você defina permissões diferentes das que você normalmente usa com sua conta interativa.

Voltar à sua pergunta sobre o gerenciamento de várias chaves: o SSH permite definir opções diferentes para destinos diferentes. Para fazer isso, você precisa editar um arquivo ~/.ssh/config da seguinte forma:

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/config deve ter permissões 0600 (não me lembro agora se isso é imposto pelo SSH ou não, mas certamente não atrapalha).

Você pode, obviamente, usar o mesmo mecanismo para shells interativos, então defina coisas como nome de usuário remoto (se diferente do local), porta remota, encurtar o nome do host, etc. Por exemplo:

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

Então você pode simplesmente executar

ssh sm

em vez de

ssh -p 2222 [email protected]

Caracteres curinga 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 o eval 'ssh-agent -s' thing". Ao contrário da crença popular, existem implicações graves de segurança para isso. O jeito certo de fazer isso é assim:

ssh-agent /bin/bash
ssh-add

(insira suas senhas de chave quando for solicitado). Isso é tudo, não faça isso chave a chave, ou de qualquer outra forma.

Isso executa um novo shell no qual suas chaves são carregadas e, quando você quiser revogar o acesso, apenas exit deste shell. Se você "fizer o eval 'ssh-agent -s' thing", os agentes de autenticação permanecerão em execução por muito tempo depois que você efetuar logoff e poderão (e eventualmente serão) usados para acesso não autorizado.

Editar: experimente este pequeno experimento:

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-agent s, eles ficam por perto até o próximo reboot , pronto para ser usado pelo malware mais recente.