Como você configura o ssh para autenticar usando chaves em vez de um nome de usuário / senha?


34

Como você configura o ssh para autenticar um usuário usando chaves em vez de um nome de usuário / senha?

Respostas:


27

Para cada usuário: eles devem gerar (em sua máquina local) seu par de chaves usando ssh-keygen -t rsa(eles rsapodem ser substituídos por dsaou rsa1também, embora essas opções não sejam recomendadas). Em seguida, eles precisam colocar o conteúdo de sua chave pública ( id_rsa.pub) ~/.ssh/authorized_keysno servidor que está conectado.


A única outra coisa que eu acrescentaria a isso é examinar as permissões no arquivo e no diretório.
trent

2
Não se esqueça chmod 0700 .ssh chmod 0600 .ssh / authorized_keys
Dave Cheney

3
Definitivamente gere as chaves dessa maneira, mas verifique a postagem de @Chris Bunch sobre "ssh-copy-id". Essa é a maneira de transferir seu 'id_rsa.pub'.
5309 Gareth

@gyaresu: Obrigado! Acabei de aprender algo novo! :-D
Chris Jester-Young

23

Na verdade, prefiro ssh-copy-id , um script encontrado no * nix por padrão (também pode ser instalado no Mac OS X com bastante facilidade) que faz isso automaticamente para você. Na página do manual:

ssh-copy-id é um script que usa ssh para fazer login em uma máquina remota (presumivelmente usando uma senha de login, portanto a autenticação por senha deve ser ativada, a menos que você tenha feito algum uso inteligente de várias identidades)

Ele também altera as permissões da página inicial do usuário remoto, ~ / .ssh e ~ / .ssh / allowed_keys para remover a capacidade de gravação do grupo (o que impediria o login, se o sshd remoto tiver StrictModes definido em sua configuração).

Se a opção -i for fornecida, o arquivo de identidade (o padrão é ~ / .ssh / identity.pub) será usado, independentemente de haver chaves no seu ssh-agent.


2
@ Chris Bunch TODOS OLHAM AQUI! :) ssh-copy-id é definitivamente o caminho a participação de um id_rsa.pub
Gareth

11
Legal, eu nunca soube disso ... Escrevi meu próprio script para fazer exatamente a mesma coisa: - /
David Z

6

Hum, não entenda. Basta criar uma chave e começar. :) COMO FAZER Além disso, você pode proibir o login via senha. Por exemplo, em / etc / ssh / sshd_config:

PasswordAuthentication no

2
E você também precisa definir o UsePAM no (ou configurar o PAM de acordo). É incrível quantos HOWTOs perdem essa parte. Caso contrário, você ainda poderá fazer login usando uma senha.
194 Nathan Nathan

3

Isso é bastante simples de fazer - há uma explicação simples aqui .

Os pontos principais são:

  • Corra ssh-keygenna sua máquina. Isso irá gerar chaves públicas e privadas para você.
  • Copie e cole o conteúdo da sua chave pública (provavelmente dentro ~/.ssh/id_rsa.pub) na ~/.ssh/authorized_keysmáquina remota.

É importante lembrar que isso concederá a qualquer pessoa que tenha acesso à chave privada da sua máquina o mesmo acesso à máquina remota; portanto, ao gerar o par de chaves, você pode optar por inserir uma senha aqui para obter segurança extra.


Eu recomendo recortar e colar em vez de copiar. Um arquivo allowed_keys pode conter várias chaves, e você não deseja derrotar as outras chaves já existentes.
31520 Chris Jester-Young

Meu detonado favorito foi remetido para o Wayback Machine: web.archive.org/web/20061103161446/http://...
Philip Durbin

@ Chris oops - eu quis copiá-lo para o arquivo em vez de sobrescrever! Resposta atualizada agora para esclarecer
ConroyP 2/09/09


1

Para resumir o que os outros disseram, configurar chaves SSH é fácil e inestimável.

Na máquina que você será SSHing de que você precisa para gerar seu par de chaves:

claudius:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/dinomite/.ssh/id_rsa): <ENTER>
Enter passphrase (empty for no passphrase): <PASSPHRASE>
Enter same passphrase again: <PASSPHRASE>
Your identification has been saved in /home/dinomite/.ssh/id_rsa.
Your public key has been saved in /home/dinomite/.ssh/id_rsa.pub.
The key fingerprint is:
a3:93:8c:27:15:67:fa:9f:5d:42:3a:bb:9d:db:93:db dinomite@claudius

Basta pressionar enter, onde estiver anotado, e digitar uma senha quando solicitado - idealmente, isso é diferente da sua senha de login normal no host atual e nos quais você estará usando o SSH.

Em seguida, você precisa copiar a chave que você acabou de gerar para o host que deseja SSH para . A maioria das distribuições Linux tem uma ferramenta ssh-copy-idpara fazer isso:

claudius:~$ ssh-copy-id caligula.dinomite.net
Now try logging into the machine, with "ssh 'caligula.dinomite.net'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Se a sua distribuição não tiver, copie a chave para o host de destino e adicione-a ao .ssh/authorized_keysarquivo (possivelmente existente) :

claudius:~$ scp .ssh/id_dsa.pub caligula.dinomite.net:
id_dsa.pub                                    100% 1119     1.1KB/s   00:00
claudius:~$ ssh caligula.dinomite.net
Last login: Sat May  9 10:32:30 2009 from claudius.csh.rit.edu
Caligula:~$ cat id_dsa.pub >> .ssh/authorized_keys

Por fim, para obter o máximo benefício das chaves SSH, convém executar um agente SSH. Se você usa um ambiente de área de trabalho (Gnome, KDE etc.), basta fazer o logout e o login iniciará um agente SSH para você. Se não, você pode adicionar o seguinte ao seu arquivo shell RC ( .bashrc, .profile, etc.):

SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
    eval `$SSHAGENT $SSHAGENTARGS`
trap "kill $SSH_AGENT_PID" 0
fi

1

Isso é planejado como uma lista de verificação. Se alguém o seguir ponto a ponto, as dicas mais comuns para logins sem senha devem ser cobertas. A maioria desses pontos é mencionada em outro lugar; isso é uma agregação.

Deve haver um ~/.sshdiretório chmod 700em cada máquina na conta que originará ou receberá as conexões.

A chave (privada) deve ser gerada sem uma senha, ou pode ser iniciado um agente que conterá uma versão descriptografada de uma chave portadora de senha para que os clientes possam usar. Inicie o agente com ssh-agent $SHELL. É a $SHELLparte que demorei a encontrar. Consulte a página do manual, pois há vários detalhes se você deseja usar um agente.

Não esqueça que, por padrão, chaves fracas (<2048 bits DSA) não são aceitas pelas versões recentes do sshd.

O seguinte deve ser feito na máquina do lado do cliente para originar uma conexão.

  1. Sua chave privada deve ser colocada ~/.ssh/id_rsaou ~/.ssh/id_dsaconforme apropriado. Você pode usar outro nome, mas deve ser incluído na opção -i no comando ssh na máquina de origem para indicar explicitamente a chave privada.

  2. Sua chave privada deve ser chmod 600.

  3. Verifique se a sua pasta pessoal está chmod 700.

Agora, para permitir que uma máquina receba uma solicitação. Um modelo comum é o local em que um administrador fornece acesso a uma máquina que você não possui (como hospedagem compartilhada na web). Portanto, a idéia com o ssh é que você ofereça sua chave pública a quem estiver fornecendo a conta. É por isso que você geralmente não coloca chaves privadas na máquina que recebe solicitações. Mas, se você deseja que esta máquina execute também ssh de saída, você deve tratá-la como uma máquina de origem com as etapas acima.

  1. Sua chave pública deve ser colocada em um arquivo chamado ~/.ssh/authorized_keysna conta que receberá as conexões. Você também pode colocar aqui outras chaves que têm permissão para se conectar por meio desta conta. Uma coisa particularmente complicada se você estiver no vi e colando a chave no arquivo do buffer de colagem no PuTTY é a seguinte: a chave começa com um "ssh-". Se você não estiver no modo de inserção, o primeiro "s" colocará vi no modo de inserção e o restante da tecla ficará bem. Mas você estará perdendo um "s" no início da chave. Levou dias para eu encontrar isso.
  2. Eu gosto de chmod 600 ~/.ssh/authorized_keys. Deve ser pelo menos gw.
  3. Agora, você deve ter a impressão digital do host adicionada ao cache. Vá para a máquina A e ssh para a máquina B manualmente. Na primeira vez, você receberá uma consulta como "Deseja adicionar ... ao cache de chaves do host?". Se você estiver tentando obter automação (como um script) para usar esse logon, verifique se o cliente ssh que está sendo usado pela automação não receberá esse prompt.

0

Como já foi dito, seus usuários devem criar pares de chaves para si mesmos nas máquinas clientes com o ssh-keygen e adicionar sua chave pública a ~ / .ssh / allowed_keys na máquina na qual desejam fazer login.

Para informações mais detalhadas, recomendo o SSH, o Secure Shell .


0

Há bons conselhos aqui, então não vou repeti-los. Depois de configurar um servidor para permitir que você faça logon com chaves, você pode configurar outros para fazer o mesmo com este liner:

remote=server1 server2 server3 server4
for r in $remote; do echo connecting to $r; tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh $r "tar zxf -; chmod 700 .ssh" ; done

Basta fazer o cd no diretório inicial, definir a variável remote como um ou vários nomes de servidores e executar várias operações ao mesmo tempo. A senha solicitada será a sua senha ssh para o servidor remoto. Obviamente, você pode usar uma versão simplificada sem o loop for:

tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh YOUR_SERVER_NAME_HERE "tar ztvf -; chmod 700 .ssh"

Lembre-se: copie apenas suas chaves públicas. Você não quer que suas chaves privadas estejam em algum servidor em que qualquer pessoa com sudo possa copiá-las e forçar sua senha com força bruta.

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.