Como você configura o ssh para autenticar um usuário usando chaves em vez de um nome de usuário / senha?
Para cada usuário: eles devem gerar (em sua máquina local) seu par de chaves usando ssh-keygen -t rsa (o rsa pode ser substituído por dsa ou rsa1 també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 ) em ~/.ssh/authorized_keys no servidor que está sendo conectado.
Na verdade, eu prefiro ssh-copy-id , um script encontrado em * nix por padrão (pode ser colocado em Mac OS X com bastante facilidade também) que faz isso automaticamente para você. Na página do manual:
ssh-copy-id is a script that uses ssh to log into a remote machine (presumably using a login password, so password authentication should be enabled, unless you've done some clever use of multiple identities)
It also changes the permissions of the remote user's home, ~/.ssh, and ~/.ssh/authorized_keys to remove group writability (which would otherwise prevent you from logging in, if the remote sshd has StrictModes set in its configuration).
If the -i option is given then the identity file (defaults to ~/.ssh/identity.pub) is used, regardless of whether there are any keys in your ssh-agent.
Hum, não entendi. Basta criar uma chave e começar. :) COMO FAZER Além disso, você pode proibir o login via senha. Em p.ex. / etc / ssh / sshd_config:
PasswordAuthentication no
Isto é bastante simples de se fazer - há um simples passo a passo para ser encontrado aqui .
Os principais pontos são:
ssh-keygen em sua máquina. Isso gerará chaves públicas e privadas para você. ~/.ssh/id_rsa.pub ) em ~/.ssh/authorized_keys na máquina remota. É importante lembrar que isso dará a quem tiver acesso à chave privada em sua máquina o mesmo acesso à máquina remota; portanto, ao gerar o par de chaves, você pode inserir uma senha aqui para segurança extra.
Para usuários do Windows configurar massa de vidraceiro
Para resumir o que os outros disseram, configurar chaves SSH é fácil e inestimável.
Na máquina em que você será o SSHing de você precisa 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 indicado e inserir uma frase secreta quando solicitado - idealmente, isso é diferente de sua senha de login normal no host atual e no qual você será o SSHing.
Em seguida, você precisa copiar a chave que acabou de gerar para o host que você deseja que seja SSH para . A maioria das distribuições do Linux tem uma ferramenta ssh-copy-id para 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 tem isso, então você deve copiar a chave para o host de destino e adicioná-la ao arquivo (possivelmente existente) .ssh/authorized_keys :
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
Finalmente, para obter o máximo benefício das chaves SSH, você desejará executar um agente SSH. Se você usar um ambiente de área de trabalho (Gnome, KDE, etc.), basta desconectar e voltar a iniciar um agente SSH para você. Caso contrário, 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
Pretende-se 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 ~/.ssh directory chmod 700 em cada máquina na conta que originará ou receberá as conexões.
A chave (privada) deve ser gerada sem uma frase secreta ou um agente pode ser iniciado, o qual conterá uma versão descriptografada de uma chave portadora de frase secreta para uso dos clientes. Inicie o agente com ssh-agent $SHELL . É a parte $SHELL que demorou um pouco para encontrar. Veja a página do manual, pois há detalhes variados se você quiser usar um agente.
Não se esqueça de que, por padrão, as chaves fracas (< 2048 bit 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.
Sua chave privada deve ser colocada em ~/.ssh/id_rsa ou ~/.ssh/id_dsa , conforme apropriado. Você pode usar outro nome, mas deve ser incluído em uma opção -i no comando ssh na máquina de origem para indicar explicitamente a chave privada.
Sua chave privada deve ser chmod 600 .
Verifique se a sua pasta pessoal é chmod 700 .
Agora, para permitir que uma máquina receba uma solicitação. Um modelo comum é quando um administrador lhe dá acesso a uma máquina que você não possui (como hospedagem compartilhada). Portanto, a ideia com o ssh é que você ofereça sua chave pública para quem estiver lhe dando a conta. É por isso que você geralmente não coloca chaves privadas nas solicitações de recebimento da máquina. Mas, se você quer que esta máquina faça ssh de saída também, então você deve tratar é como uma máquina de origem com as etapas acima.
~/.ssh/authorized_keys na conta que irá receber as conexões. Você também pode colocar outras chaves que podem se conectar através dessa conta aqui. Uma coisa particularmente complicada se você está no vi e colando a chave no arquivo do buffer de colar no PuTTY é esta: a chave começa com um "ssh-". Se você não estiver no modo de inserção, o primeiro "s" colocará o vi no modo de inserção e o restante da chave ficará bem. Mas você estará perdendo um "s" no início da chave. Demorou dias para eu descobrir isso. chmod 600 ~/.ssh/authorized_keys . Deve ser pelo menos g-w. Como outros já disseram, seus usuários devem fazer keypairs para si mesmos em suas máquinas cliente com ssh-keygen e adicionar sua chave pública em ~ / .ssh / authorized_keys na máquina na qual desejam se conectar.
Para informações mais detalhadas, porém, eu recomendo SSH, The Secure Shell .
Há bons conselhos aqui, então não vou repetir. Uma vez que você tenha um servidor configurado para permitir que você assine com chaves, você pode configurar outros para fazer o mesmo com este forro:
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 para o seu diretório pessoal, definir a variável remota como um ou vários nomes de servidores e fazer um monte de uma só vez. A senha solicitada será sua senha ssh para o servidor remoto. É claro que você pode usar uma versão simplificada sem o loop:
tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh YOUR_SERVER_NAME_HERE "tar ztvf -; chmod 700 .ssh"
LEMBRE-SE: copie somente suas chaves públicas. Você não quer que suas chaves privadas fiquem em algum servidor, onde qualquer pessoa com o sudo pode copiá-las e forçar sua senha.