Conexões SSH sem senha fácil e descomplicado

fernandofat

Utilizando chaves públicas e privadas é possível realizar conexões SSH sem o uso de senhas, é possível também a execução remota de comandos, o que facilita alguns processos de automatização. Vale lembrar que esta não é uma configuração totalmente segura, por isto devem ser adotadas medidas alternativas para melhorar a segurança.

[ Hits: 323.925 ]

Por: Fernando Ribeiro em 26/01/2007 | Blog: http://www.vivaolinux.com.br/~fernandofat

8 0

Denuncie Favoritos Indicar Impressora

Execução remota de comandos

Para executar os comandos remotamente basta executar o seguinte comando:

# ssh root@servidor '/etc/init.d/httpd restart'

Este é apenas um exemplo onde reiniciaria o servidor Web remotamente. Existem muitas possibilidades para a aplicação de execução de comandos remotos.

Execução remota de comandos usando PuTTY

No Windows a ferramenta de conexão SSH mais popular é o PuTTY. Ele disponibiliza diversas formas para conexões a consoles remotos como Telnet, Rlogin e SSH.

Uma das ferramentas "inclusas" é o Plink, que nada mais é que uma interface em linha de comando para as funcionalidades do PuTTY. Usando esta ferramenta e conexões SSH sem senha é possível executar comandos remotos dentro de scripts por exemplo.

O conceito de conexão SSH sem senha continua o mesmo, porém agora é preciso gerar uma chave pública/privada através do PuTTYgen, depois copiar a chave pública para o arquivo "authorized_keys" do servidor.

Nota: Existem formas diferentes de se realizar conexões sem senha usando o PuTTY, aqui mostro apenas uma delas. Para mais detalhes consulte a documentação (http://www.putty.nl/docs.html).

Vamos precisar de três arquivos do PuTTY encontrados neste endereço:

http://www.putty.nl/download.html

São eles:

putty.exe
plink.exe
puttygen.exe

Faça o download deles e salve no cliente.

Agora é preciso criar um par de chaves pública/privada, para isso execute o arquivo "puttygen.exe", depois clique no botão "Generate" e dê uma "brincadinha" com o mouse (essa é a parte que eu mais gosto! ;), pronto as chaves foram geradas. Para salvá-las, clique no botão "Save public key", escolha a pasta e dê um nome ao arquivo, faça o mesmo para a chave privada clicando no botão "Save private key" (manter a "passphrase" em branco).

A chave pública que deverá ser copiada para o servidor (em destaque na figura 1) está na janela principal do PuTTYgen no campo "Public key for pasting into OpenSSH authorized_keys file:", basta copiar este conteúdo e inserir dentro do arquivo "/root/.ssh/authorized_keys" (como nos exemplos anteriores) do servidor. Não entrarei em detalhes de como fazer esta cópia, pois existem muitas.

Figura 1

Para fazer a conexão SSH o Plink pode utilizar as informações de uma sessão previamente salva no PuTTY, é esta sessão que iremos criar.

Execute o PuTTY, coloque o endereço (IP ou nome) do servidor no campo "Host Name", selecione o protocolo "SSH", coloque um nome para a sessão (sem acento e sem espaços para facilitar) por exemplo "Servidor" e clique em "Save". Pronto, uma sessão chamada "Servidor" foi criada (Figura 2).

Figura 2

Selecione a sessão "Servidor" e clique em "Load", no menu da esquerda clique na opção "Data" e coloque o nome do usuário que será utilizado na conexão no campo "Auto-login username", por exemplo "root" (Figura 3).

Figura 3

Ainda no menu da esquerda, clique na opção "Auth" depois no botão "Browse" e localize e selecione o arquivo de chave privada que criamos anteriormente (Figura 4).

Figura 4

No menu da esquerda selecione a opção "Session", repare que estamos com a sessão "Servidor" ainda carregada, portanto as alterações realizadas anteriormente devem ser salvas nesta sessão, para isto clique em "Save".

Com a sessão "Servidor" selecionada, clique no botão "Open" para iniciar uma conexão, como (provavelmente) é a primeira conexão, o PuTTY irá perguntar se deseja registrar uma chave do servidor no cache do PuTTY (Figura 5), clique em "Sim", isto só acontece na primeira conexão.

Figura 5

Se tudo correu bem até aqui você terá conectado no servidor sem ter digitado nenhuma senha.

Para executar comandos remotamente utilize o Plink da seguinte forma:

plink Servidor "/etc/init.d/httpd restart"

Onde "Servidor" é o nome da sessão previamente configurada e "/etc/init.d/httpd restart" é o comando a ser executado no servidor.

Página anterior Próxima página

Páginas do artigo

   1. Chaves públicas/privadas, o que são e para que servem?
   2. Configurando o servidor
   3. Execução remota de comandos
   4. Considerações finais

Outros artigos deste autor

Linux logando no Domínio NT

Configurando OpenSSH no Windows Server 2003 para autenticação por chave (sem senha)

Leitura recomendada

Instalando o Vivo Zap no openSuSE 10.2

Instalando MultiLIB no Slackware 14.2 com Atualizações pelo GSlapt

Configurando e instalando o Java com Tomcat no Linux

TinyCore Linux - Gerenciando Usuários

Instalando o NTFS-3G corretamente no Ubuntu

Comentários

[1] Comentário enviado por thelinux em 26/01/2007 - 14:12h

Parabéns pelo artigo. Bem útil.

1 0

[2] Comentário enviado por kyrme em 26/01/2007 - 14:16h

Não posso fazer o processo ao contrário, gerar um par de chaves no servidor e então divulgar a pública?!

0 0

[3] Comentário enviado por dailson em 29/01/2007 - 10:52h

Kyrme

Isso pode ser feito também!
Parabéns pelo artigo!

Dailson

0 0

[4] Comentário enviado por superrlp2 em 29/01/2007 - 20:59h

Beleza de artigo...parabéns!

0 0

[5] Comentário enviado por cainf em 24/02/2007 - 23:53h

Fiz exatamente todo o procedimento so que no meu Debian 3.1 não aparece esse arquivo authorized_keys aparece so o arquivo known_hosts
Falta algum outro pacote no meu caso ??
Obrigado a todos

0 0

[6] Comentário enviado por fernandofat em 26/02/2007 - 14:25h

cainf,

Quando você executa o comando "cat /root/id_rsa.pub >> /root/.ssh/authorized_keys" ele deveria criar o arquivo ou se já existe inserir o conteúdo nele.

Se não está criando verifique se o caminho existe, em alguns casos o diretório ".ssh" não existe dentro do home do usuário então é preciso cria-lo.

[]'s

Fernando

0 0

[7] Comentário enviado por hendrigo em 17/04/2008 - 13:43h

bom artigo. foi muito útil para mim.

0 0

[8] Comentário enviado por emerson.candido em 08/10/2008 - 17:02h

Fernando,

Ja utilizo o OpenSSH em estações Windows XP e Windows 2000 Server e autenticação por chaves é feita sem problemas, porém realizei o mesmo procedimento no Windows 2003 Server e quando vou fazer a autenticação por chaves simplesmente ele fechou a conexão, já tentei de várias formas repetir o procedimento, mudei de máquina instalei um 2003 do zero e fiz o procedimento igual uma máquina Windows XP que funciona e nada.
Existe alguma particularidade de segurança no Windows 2003 Server que pode impedir esse tipo de autenticação?

0 0

[9] Comentário enviado por fernandofat em 10/10/2008 - 14:26h

Emerson,

Já fiz algumas instalações no Windows Server 2003 e não encontrei problemas.

Você consegue se conectar usando o Putty com autenticação mesmo?

[]'s

Fernando

0 0

[10] Comentário enviado por emerson.candido em 12/10/2008 - 22:22h

Fernando,

Eu consigo autenticar com senha tranquilamente, o problema é quando eu vou fazer a autenticação por chaves.

Ele simplesmente fecha a conexão como se a chave estivesse incorreta, mas não é exibido nenhuma mensagem de erro nem mesmo no event viewer e nenhuma pasta do próprio OpenSSH, tentei até olhar a pastar C:\Program Files\Openssh\var\log, porém não há nada de relevante lá.

Também tentei gerar novas chaves, pois inicialmente estava usando do tipo DSA, depois mudei para RSA, mas não mudou nada, gerei-as com o ssh-keygen e depois através do PuttyGen.

Abaixo segue o meu sshd_config, veja se você consegue achar algo errado:

# $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

Port 22
#Protocol 2,1
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes

# The following setting overrides permission checks on host key files
# and directories. For security reasons set this to "yes" when running
# NT/W2K, NTFS and CYGWIN=ntsec.
StrictModes no

#RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile etc/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts yes
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes

# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
#UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
UsePrivilegeSeparation no
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
MaxStartups 10:30:60

# default banner path
Banner /etc/banner.txt

# override default of no subsystems
Subsystem sftp /usr/sbin/sftp-server

0 0

[11] Comentário enviado por brunosilva.ti em 01/06/2009 - 14:40h

Parabens, funcionou perfeitamente!

0 0

[12] Comentário enviado por vlademiro em 10/07/2009 - 18:42h

Parabens, funcionou. Seu artigo é muito util, claro e prático.

0 0

[13] Comentário enviado por gdtec em 27/01/2010 - 17:03h

Muito bom artigo. Simples, prático e funcional. Obrigado!

0 0

[14] Comentário enviado por mirandamiranda em 09/02/2010 - 15:18h

Eu tenho uma dúvida:
O comando # ssh-keygen -t rsa deve ser executado no cliente. OK
Mas e se o cliente for Windows, o comando é o mesmo? Como devo proceder?

0 0

[15] Comentário enviado por fernandofat em 09/02/2010 - 16:33h

Miranda, veja a seção "Execução remota de comandos usando PuTTY". O PuTTY tem uma ferramenta para gerar esta chave.

[]'s

Fernando

0 0

[16] Comentário enviado por maneto em 12/03/2010 - 17:12h

acabei de precisar disso, pois achei um tuto do howtoforge que me dizia para fazer
$ cat ~/.ssh/id_dsa.pub | ssh you@example.com "cat - >> ~/.ssh/authorized_keys"

como tava dando erro ao executar pelo cliente, tive que usar o scp e mexer no servidor mesmo

0 0

[17] Comentário enviado por throberth em 06/04/2010 - 18:26h

parabens pelo artigo, ajudou muito mas agora surgiu algumas dificuldades:
-quando preciso acessar mais de uma maquina sem senha, do mesmo servidor de origem?
pois tenho um servidor que atualizada dados em vários servers assim o ssh sem senha me ajudaria pacas, tem alguma idéia como posso realizar isto?

0 0

[18] Comentário enviado por throberth em 06/04/2010 - 18:56h

senhores peço perdão pela minha ignorância, a chave é a mesma para todos os demais servidores, é somente copia-la para os tais, agradeço.

0 0

[19] Comentário enviado por mcabral em 10/09/2010 - 10:35h

Camarada ..!!!

Meus parabéns pelo artigo ... Funciona que é uma beleza ... estou usando para copiar dados de um servidor para outro.

Obrigado por estar ajudando
Marcelo Cabral

0 0

[20] Comentário enviado por Ze_Euros em 11/03/2011 - 10:09h

Gente amiga.
Eu tenho um problema eu não tenho a senha do root porque eu sou administrador aplicacional portanto tenho outros privilegios
no servidor com posso ultrapassar esse dilema ? É possivel eu usar o meu usar outro user para guardar as senhas publicas ?

0 0

[21] Comentário enviado por dborges em 02/09/2013 - 21:50h

Fernando e demais,
Não estou conseguindo autenticar sem precisar digitar a senha!
Meu cenário é: um macbook com uma VM do Ubuntu. A VM seria meu servidor. Enquanto que o mac, o cliente.
Criei as chaves no cliente, e copiei para o servidor. Na primeira tentativa, criei como usuario "douglas" no mac (cliente), e copiei para o usuario root da VM (servidor). Não funcionou.
Tentei então, como usuário root no mac, e copiei para o root da VM.
Sem sucesso também.
Essa comunicação mac x ubuntu funciona de forma correta (nesse contexto)? Alguém já tentou?!
Agradeço a ajuda.

Parabéns pelo tópico Fernando. Muito interessante!
Abraço a todos.

0 0

[22] Comentário enviado por viniciusmunizm em 14/01/2014 - 17:51h

Olá pessoal,

Escrevi sobre usar ssh sem senha de uma forma mais fácil, utilizando ssh-copy-id, quem desejar pode acessar : http://viniciusmuniz.com/usando-ssh-sem-senha/

0 0

[23] Comentário enviado por jeffersonsfelix em 26/03/2014 - 08:39h

Não esquecer que o arquivo authorized_keys (em alguns servidores chama-se authorized_keys2 não sei bem pq) deve estar com permissão 600:
chmod 600 authorized_keys

0 0