Respostas:
Para cada usuário: eles devem gerar (em sua máquina local) seu par de chaves usando ssh-keygen -t rsa
(eles rsa
podem ser substituídos 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
) ~/.ssh/authorized_keys
no servidor que está conectado.
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.
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
Isso é bastante simples de fazer - há uma explicação simples aqui .
Os pontos principais são:
ssh-keygen
na sua máquina. Isso irá gerar chaves públicas e privadas para você.~/.ssh/id_rsa.pub
) na ~/.ssh/authorized_keys
má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.
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 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-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 tiver, copie a chave para o host de destino e adicione-a ao .ssh/authorized_keys
arquivo (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
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 ~/.ssh
diretório chmod 700
em 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 $SHELL
parte 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.
Sua chave privada deve ser colocada ~/.ssh/id_rsa
ou ~/.ssh/id_dsa
conforme 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.
Sua chave privada deve ser chmod 600
.
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.
~/.ssh/authorized_keys
na 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.chmod 600 ~/.ssh/authorized_keys
. Deve ser pelo menos gw.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 .
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.