O que esse erro ssh significa?

Question

Este é meu último recurso. Eu tenho tentado descobrir o problema aqui por horas.

O negócio é o seguinte: eu copiei minha chave privada da máquina # 1 para a máquina # 2. A máquina 1 é capaz de se conectar via ssh a um servidor com a minha chave pública, mas a máquina 2 fornece a seguinte saída, ao tentar se conectar ao servidor:

$ ssh -vvv -i /home/kevin/.ssh/kev_rsa [email protected] -p 22312
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.244 [192.168.1.244] port 22312.
debug1: Connection established.
debug3: Not a RSA1 key file /home/kevin/.ssh/kev_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace

...


Permission denied (publickey).

Existe obviamente mais resultados de depuração que omiti, e posso fornecer mediante solicitação. No entanto, estou convencido de que não gosta do meu arquivo de chave privada.

Eu também suspeitava que isso tivesse a ver com a forma como copiei a máquina # 1 para a máquina # 2. Eu copiei / colei o texto da chave privada em um pen drive. Este pode ser o problema, no entanto, quando eu dupliquei este método em outro arquivo de chave privada de trabalho, e fiz um diff no original, para copiar / colá-lo, eles são idênticos.

Eu tenho lutado com isso. Se eu pudesse obter um pouco mais de informações sobre por que não gosta da minha chave, eu poderia consertar isso, tenho certeza. Alguém tem alguma ideia sobre isso? Existe algum meta-dados em algum lugar que diz ao ssh que um arquivo é, na verdade, uma chave RSA?

    

Answer 1

Na minha experiência, os dois erros de autenticação mais comuns baseados em chaves são

1. Permissões inadequadamente amplas no diretório $HOME/.ssh
2. Um erro ao copiar a chave pública para o sistema remoto

Permissões de arquivo

OpenSSH faz muito em uma tentativa de protegê-lo de si mesmo. A maneira mais impactante de usar isso é impor restrições rígidas sobre quem tem acesso à pasta ssh local. Você realmente só quer que você, e somente você, acesse o diretório. Bem, e qualquer pessoa com uid = 0, mas não há maneira de contornar isso. Então, o que você precisa fazer é simplesmente alterar suas permissões: chmod -R go-rwx ~/.ssh Isso removerá os direitos de leitura, gravação e execução de quaisquer arquivos sob o diretório .ssh de todos os usuários, exceto o proprietário, ou seja, você .

Problemas com chaves autorizados

O arquivo que contém sua chave pública, normalmente $HOME/.ssh/authorized_keys , precisa caber em um formulário muito específico para o SSH entender como aceitar a chave privada. Cada chave deve consistir em, pelo menos, 2 campos

1. Tipo de chave usada (RSA, DSA, RSA1, etc)
2. Chave

Cada chave, juntamente com todas as suas opções e componentes, deve ser listada uma por linha neste arquivo. Uma vez que as teclas tendem a ser muito longas, elas geralmente são quebradas e aparecem como duas linhas em seu terminal. Isso às vezes causará estragos ao tentar copiar / colar, já que às vezes uma ou mais linhas novas serão inseridas sempre que a chave for envolvida na tela. Corrigir este problema pode ser um pouco mais complicado para um iniciante do shell.

Tente executar wc -l ~/.ssh/authorized_keys
Isso imprimirá o número de linhas no arquivo. Compare esse número com o número de chaves que você espera estar no arquivo. Se você aceitar apenas esta chave, também poderá fazer uma cópia do arquivo de chave pública, pois é o mesmo formato do arquivo de chaves autorizadas. Algo parecido com scp -p ~/.ssh/kev_rsa.pub remotehost:~/.ssh/authorized_keys
ou, se você tiver sua chave pública no mesmo sistema, você pode fazer cat ~/.ssh/kev_rsa.pub >> ~/.ssh/authorized_keys

Além disso, procure no arquivo de log no host remoto e veja se algum erro está sendo relatado lá. Os arquivos provavelmente serão /var/log/secure.log ou /var/log/auth .

    

Answer 2

Embora, você provavelmente terá que gerar um novo par de chaves para a máquina 2 se conectar ao servidor. Frequentemente, a chave pública listará o nome do usuário e da máquina daqueles que os geraram. Isso deve estar aparente no seu arquivo authorized_keys no servidor.

    

Answer 3

As mensagens de depuração fornecidas significam que um arquivo de chave privada é lido com a suposição de que ele é realmente um arquivo de chave pública / de hosts autorizados. Isso pode não ser um erro fatal (recebo essas mensagens mesmo para conexões de trabalho). Diz alguma coisa sobre "Oferecer" ou "nós enviamos"?

    

Answer 4

Tente comparar os arquivos de configuração ssh entre os dois servidores.

ie. algo como cat / etc / sshd_config