O seu problema é provavelmente que as permissões da sua chave de usuário estão erradas. Tente isso no servidor Ubuntu:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa ~/.ssh/authorized_keys
chmod 644 ~/.ssh/id_rsa.pub
Eu tenho um servidor Ubuntu em execução para o meu SCM e estou fazendo meu desenvolvimento em um computador com Windows. Essa configuração funcionou por um longo tempo sem problemas. Mas agora eu tenho um problema estranho.
O problema começou quando eu precisei mudar os direitos de acesso em um repositório git no servidor (não me diga que foi idiota para chmod o diretório home inteiro ... eu já sei). Depois disso, toda vez que tento acessar o servidor via ssh (git inclusive) usando minha chave pública. Eu recebo o seguinte erro:
$ ssh [email protected] open log failed: Permission denied Connection to 192.168.0.240 closed.
No entanto, quando tento conectar-me ao servidor, usando apenas a senha, tudo funciona conforme o esperado:
Eu tentei executar o sshcommand com -vvv. Não me dá a menor ideia de onde procurar o problema. Talvez você possa ver algo disso.
... debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 2097152 debug2: channel 0: rcvd ext data 35 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: obuf_empty delayed efd 6/(35) open log failed: Permission denied debug2: channel 0: written 35 to efd 6 debug3: channel 0: will not send data after close debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
Alguma idéia?
O seu problema é provavelmente que as permissões da sua chave de usuário estão erradas. Tente isso no servidor Ubuntu:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa ~/.ssh/authorized_keys
chmod 644 ~/.ssh/id_rsa.pub
Além da resposta do terdons , algum comportamento estranho com chaves ssh também ocorre, se ~ for gravável por outras pessoas .
Suponha que você configurou com êxito o ssh para usar o login de chaves:
user@local:~> ssh remote
Last login: Thu Mar 7 17:39:18 2013 from local
user@remote:~>
Agora torne sua casa gravável por outro usuário na máquina remota :
user@remote:~> getfacl .
# file: .
# owner: user
# group: users
user::rwx
group::r-x
other::r-x
user@remote:~> setfacl -m u:coauthor:rwx .
user@remote:~> exit
user@local:~>
Ok, agora tente novamente fazer login no remoto:
user@local:~> ssh remote
user@remote's password:
ssh solicita a senha agora! Remova a ACL e a tecla voilà ssh está funcionando novamente.
[Minha solução alternativa era usar um subdiretório para colaboração.]
Craig Sanders sabe o motivo , esse comportamento depende de StrictModes yes em sshd_config. Citando man 5 sshd_config :
StrictModes Specifies whether sshd(8) should check file modes and ownership of the user's files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is “yes”.