Na minha rede doméstica, tenho um servidor rodando o Ubuntu e outro desktop rodando o Windows 7. Estou usando o cygwin na máquina Windows para ssh no servidor. Eu tentei configurar as chaves entre essas duas máquinas. Na máquina do Windows, criei chaves usando ssh-keygen -t rsa . Eu então 'scp'ed o id_rsa.pub resultante para o servidor e coloquei no arquivo ~/.ssh/authorized_keys . Tanto quanto eu sei que deve ser tudo que preciso para fazer este trabalho. Mas, como você deve ter adivinhado, não é.
Estou tentando usar ssh usando [email protected] . Meus palpites (de que não consegui obter grandes informações) são que talvez precise definir algo um pouco diferente para usar o cygwin ou que possa ter algo a ver com o uso do endereço IP em vez do nome do host. Alguma direção ou idéia?
É provavelmente um problema de permissões no seu diretório ~ / .ssh ou no seu arquivo ~ / .ssh / authorized_keys.
Seu diretório ~ / .ssh deve ser chmod'd para 700 e seu arquivo authorized_keys deve ser chmod'd para 644 no mínimo. Se você verificar seu arquivo de log / var / log / secure, ele deve lhe dar uma dica sobre o motivo da falha.
Se você está tendo problemas de autenticação com o ssh, a primeira coisa a investigar é o que o cliente diz com alguma depuração:
% ssh -v host
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/david/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
...
é uma conexão de chave pública bem-sucedida.
% ssh -v host
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/david/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/david/.ssh/identity
debug1: Trying private key: /home/david/.ssh/id_rsa
debug1: Next authentication method: password
david@ace's password:
...
Isso não oferece muita informação sobre o motivo pelo qual a autenticação de chave pública foi recusada. A melhor informação está disponível no servidor. O Sshd irá logar ao recurso de syslog AUTH, então você pode encontrar informações onde quer que esteja logado (no caso do Debian /var/log/auth/ ).
Aug 19 08:18:36 ace sshd[10100]: Authentication refused: bad ownership or modes
for directory /home/david/.ssh
Isso nos diz que as permissões para .ssh estão erradas e que podemos consertar isso facilmente.
Aug 19 08:26:41 ace sshd[12156]: error: key_read: uudecode
ZAAAAB3NzaC1kc3MAAACBAIUuAmpj9FuE71EfqJDVAfI+pUZ++xSWbUvEh7U36WW/...
Isso nos diz que não foi possível ler essa chave em particular, por isso sabemos como corrigir isso.
Se você não obtiver nenhuma informação útil dos registros, poderá ativar o registro. Edite /etc/ssh/sshd_config e altere a linha LogLevel para:
LogLevel DEBUG
Em seguida, execute
/etc/init.d/ssh reload
Agora, quando você tentar se conectar, deverá ver alguns registros como:
Aug 19 08:32:12 ace sshd[13537]: debug1: Checking blacklist file
/usr/share/ssh/blacklist.DSA-1024
Aug 19 08:32:12 ace sshd[13537]: debug1: Checking blacklist file
/etc/ssh/blacklist.DSA-1024
Aug 19 08:32:12 ace sshd[13537]: debug1: temporarily_use_uid: 1002/513 (e=0/0)
Aug 19 08:32:12 ace sshd[13537]: debug1: trying public key file
/home/david/.ssh/authorized_keys
Aug 19 08:32:12 ace sshd[13537]: debug1: fd 4 clearing O_NONBLOCK
Aug 19 08:32:12 ace sshd[13537]: debug1: matching key found: file
/home/david/.ssh/authorized_keys, line 1
Aug 19 08:32:12 ace sshd[13537]: Found matching DSA key:
1c:46:89:52:c1:79:c8:8f:43:3c:4e:77:ad:a1:5d:1b
Este foi um login bem-sucedido.
Se precisar de mais informações, você pode usar DEBUG2 e DEBUG3 para obter mais informações. Não se esqueça de alterar seu nível de log novamente (provavelmente para INFO) quando tiver corrigido o problema.
As permissões são importantes para o arquivo ~ / .ssh / authorized_keys. O arquivo em si não deve ter permissões que permitam que qualquer outra pessoa grave nele chmod go-rwx ~/.ssh/authorized_keys Além disso, o diretório .ssh não deve permitir gravações nele chmod go-rwx ~/.ssh
Seu diretório home também não deve permitir gravações chmod go-w ~/
A razão para isso é que, se alguém foi capaz de escrever para o seu diretório (via permissão de grupo ou outra permissão), então seria muito fácil alguém colocar as chaves autorizadas lá sem o seu conhecimento. Se o seu diretório home permitir gravações, alguém poderá recriar o diretório .ssh e seu conteúdo.
Algumas distros fornecem uma ferramenta (é realmente um shell script) chamada ssh-copy-id . Acho que usar isso contorna muitas dores de cabeça com a cópia da parte .pub da chave de um usuário para o arquivo authorized_keys de uma conta remota.
$ ssh-copy-id user@remotehost
Você pode até mesmo dizer diferentes chaves para copiar (o padrão é o id_rsa* keys.
$ ssh-copy-id -i ~/.ssh/somekey.pub user@remotehost
Esse script também cuida da criação do diretório $HOME/.ssh do usuário no remotehost, bem como e definem as permissões corretamente.
$ ssh-copy-id --help
Usage: /usr/bin/ssh-copy-id [-i [identity_file]] [user@]machine
Tem uma página de manual básica para acompanhá-lo. Nas minhas distribuições baseadas no Red Hat (Fedora, CentOS, RHEL) era parte do pacote openssh-client de estoque!