Stoa :: Oda :: Blog :: SSH sem senha

julho 17, 2009

default user icon
Postado por Oda

Mais um post da serie receitas de bolo!

Hoje me perguntaram se eh possivel fazer ssh para uma maquina e nao precisar fornecer senha. A resposta que dei foi: claro!

Eh uma coisa bem simples de se fazer, mas acho que pouca gente usa.

Mas pq raios alguem vai querer isso? Oras, se vc trabalha muito com maquinas remotas (para administra-las, para rodar programas em paralelo, etc) vai achar um saco ter que ficar digitando sua senha 364765294734 vezes.

Bom, vamos a receita de bolo:

Primeiro, da maquina da qual vc vai fazer o ssh (maquina local) crie um par de chaves:

$ ssh-keygen

Vai te solicitar uma senha que eh opcional. Ela eh usada para cifrar sua chave privada, mas nesse caso, cada vez que vc for usa-la vai precisar digitar a senha e vc nao quer isso, portanto deixe a senha em branco. Se vc nao se sente seguro em deixar sua chave privada em uma maquina sem que ela esteja protegida por senha, entao nao deixe sua chave la, mesmo que protegida por uma senha, isso nao eh obvio?

Agora copie a chave publica ($HOME/.ssh/id_rsa.pub) para a maquina remota usando scp, mandando por email, sem muita preocupacao, afinal, a chave publica eh publica!

Faca um ssh para a maquina remota e anexe o conteudo de id_rsa.pub ao final do arquivo $HOME/.ssh/authorized_keys:

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

Pronto! Pode dar um logoff e fazer o ssh novamente, e dessa vez sem senha!

Deixe eu fazer algumas consideracoes importantes. Cuide muito bem da sua chave privada. Se alguem pega-la eh como saber sua senha. Por exemplo, se vc tem conta em uma rede e em uma das estacoes de trabalho vc faz o passo a passo acima para acessar uma outra maquina, a da sua casa, por exemplo,o administrador da rede podera acessar a maquina da sua casa. Fazer o contrario (gerar o par de chaves na maquina da sua casa) eh seguro, se vc confiar nas pessoas da sua casa, claro...

Eu, por exemplo, contrato um servico de hosting barato para eu brincar com algumas coisas, fazer o site de uns parentes e outras bobagens. Eu posso fazer ssh para o servidor onde estao os sites, mas nunca vou permitir ssh sem senha da rede do IME para o servidor e nem o contrario, entende?

Mas eu gerei um par de chaves no meu micro de casa e mandei a chave publica para a rede IME e para o servidor compartillhado, de modo que de casa acesso os dois lugares sem usar senha.

Vc pode tb colocar a chave privada no seu notebook, mas dai eh melhor usar discos criptografados.

Caso vc tenha conta em uma rede, cada hora usa uma estacao de trabalho diferente e precisa fazer ssh para outras estacoes/servidores que montam seu home por nfs ou similar, vc definitivamente pode usar o esquema descrito acima. E melhor, vc pode fazer numa mesma estacao ;)

 

Palavras-chave: Linux, ssh

Postado por Oda | 1 usuário votou. 1 voto

Comentários

  1. Ewout ter Haar escreveu:

    "Deixar sua chave privada em uma maquina sem que ela esteja protegida por senha, entao nao deixe sua chave la, mesmo que protegida por uma senha, isso nao eh obvio?"

    Mas isto não é "cuidar bem da sua chave privada". Me parece que a idéia de proteger a senha privada por senha é que se ao colocar mais uma camada de segurança se diminua um pouco o risco que a sua chave privada é roubada. No caso de um invasão da sua máquina, isto aumenta um pouco a barreira para a invasão dos seus outros servidores. No caso que a chave privada esteja num smart-card, proteja você caso perca o cartão, etc. etc.

    A solução no caso de ssh é usar ssh-agent. Mas concordo que no caso de scripts e processos automáticos que rodam sem intervenção pessoal, é complicado. 

     

    Ewout ter HaarEwout ter Haar ‒ sexta, 17 julho 2009, 13:35 BRT # Link |

  2. Oda escreveu:

    Ola Ewout!

    Desculpa a resposta tardia... Por algum motivo nao recebi o email notificando o seu comentario...

    Bom, a senha serve para isso mesmo que vc disse. Mas no caso de uma invasao da maquina, se vc estiver usando ssh-agent, tb esta lascado.

    Se invadir como root, nao preciso nem falar nada, hijacking seria trivial, mas o mais interessante eh que nem precisa ter invadido como root: invade como usuario comum, edita o .xinitrc ou qq outro lugar de onde o ssh-agent eh chamado e coloca um programinha sacana que pega a senha e manda manda ela para algum lugar (antigamente eu falaria IRC, mas hoje me parece mais muderrrno usar o twitter rsrs) e depois repassa a requisicao para o ssh-agent de verdade. No final, alem de pegar sua chave privada, ja vou ter pego uma de suas senhas. Meu dicionario agradece ;) rsrs

    Resumindo, invadiu sua maquina, ferrou, nao tem jeito, ja era... O negocio eh nao deixa invadir.

    Disso eu concluo que o ssh-agent acrescenta pouca ou nenhuma seguranca. Mas eh claro que vc pode ter um opniao diferente e achar que kids, por exemplo, nao chegariam a tanto... Pode ser...

    De todo modo, um problema sobre o qual vc tem muito menos controle eh ser assaltado na rua ou perder um pendrive. Nesse caso, sua chave privada nao deve ser a unica coisa que vc precisa proteger, certo? Entao nao tem motivo para vc nao utilizar criptografia em toda uma particao e nela colocar seus arquivos importantes, dentre eles, sua chave privada.

    Quando eu tiver um tempo coloco um tutorialzinho de como fazer isso.

    As pessoas no geral (eu me incluo nisso) sao muito ingenuas ou descuidadas com relacao aos dados que carregam por ai. Hoje em dia qq um tem um laptop, pendrive ou sd card cheio de dados cujos donos nao iriam querer ver dando sopa.

    E nao ha desculpa para esse descuido pois existem dezenas de ferramentas de uso simples (inclusive para windows) que podem aumentar muito a seguranca. Meu pai, por exemplo, arrumou um pendrive que ja criptografa as coisas sozinho, sem nenhuma intervencao do usuario que so precisa dar a senha. Eu nao vi como exatamente ele funciona, mas parece muito interessante (u3.com).

    Mas enfim, se as pessoas comecarem a fazer backups ja eh um grande avanco...Quem dira usar criptografia...

     

    OdaOda ‒ terça, 28 julho 2009, 21:41 BRT # Link |

Você deve entrar no sistema para escrever um comentário.

Termo de Responsabilidade

Todo o conteúdo desta página é de inteira responsabilidade do usuário. O Stoa, assim como a Universidade de São Paulo, não necessariamente corroboram as opiniões aqui contidas.