O que esse erro ssh significa?

9

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

O negócio é o seguinte: copiei minha chave privada da máquina 1 para a máquina 2. A máquina nº 1 é capaz de se conectar via ssh a um servidor com minha chave pública, mas a máquina nº 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).

Obviamente, há mais saída de depuração que eu omiti e posso fornecer mediante solicitação. No entanto, estou convencido de que ele não gosta do meu arquivo de chave privada.

Eu também suspeitava que isso tivesse a ver com como eu o copiei da máquina 1 para a máquina 2. Copiei / colei o texto da chave privada em uma unidade flash. Esse pode ser o problema, no entanto, quando eu dupliquei esse método em outro arquivo de chave privada em funcionamento, e fiz uma comparação do original com o arquivo copiado / colado, eles são idênticos.

Eu tenho lutado com isso. Se eu pudesse obter um pouco mais de informação sobre por que ela não gosta da minha chave, eu poderia corrigi-la, tenho certeza. Alguém tem alguma ideia sobre isso? Existe algum metadado em algum lugar que diga ao ssh que um arquivo é de fato uma chave RSA?

ssh rsa private-key keys Kevin
fonte
E o que diz /var/log/auth.logo servidor?
womble
Para esclarecimento, a chave pública da máquina 1 se conecta ao servidor. A chave privada da máquina 1, em execução na máquina 2, não se conectará ao servidor?
Dru
Eu tenho o mesmo par de chaves nas duas máquinas e a chave pública está no servidor. Copiei colei as chaves da máquina cliente 1, que não tem problemas para conectar-se ao servidor, aqui no meu computador doméstico (máquina 2) que está com esse problema de autenticação.
kevin
@womble, Infelizmente, eu não posso acessar o servidor, se eu conseguir isso descobri que será capaz de direito ssh em .. Ahh, ironia ...;)
kevin
Quais são os sistemas operacionais nas duas máquinas clientes? A transferência da chave privada poderia ter passado as linhas finais ou introduzido o texto (possivelmente linhas ou espaços em branco) antes da linha de abertura?
Stobor

Respostas:

7

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

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

Permissões de arquivo

O OpenSSH faz muito na tentativa de proteger você de si mesmo. A maneira que mais afeta o usuário é impor restrições rígidas sobre quem tem acesso à sua pasta ssh local. Você realmente deseja apenas que você, e somente você, acesse o diretório. Bem, e qualquer pessoa com uid = 0, mas não há uma maneira boa de contornar isso. Portanto, o que você precisa fazer é simplesmente alterar suas permissões: chmod -R go-rwx ~/.sshIsso removerá os direitos de leitura, gravação e execução de todos os arquivos abaixo do diretório .ssh de todos os usuários, exceto o proprietário, ou seja, você .

Problemas de chaves autorizadas

O arquivo que contém sua chave pública geralmente $HOME/.ssh/authorized_keystem que 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 partes componentes, deve ser listada uma por linha neste arquivo. Como as teclas tendem a ser muito longas, elas geralmente quebram e aparecem como duas linhas no seu terminal. Às vezes, isso causa estragos ao tentar copiar / colar, pois algumas vezes uma ou mais novas linhas são inseridas onde quer que a chave seja inserida na tela. Corrigir esse problema pode ser um pouco mais complicado para um iniciante em 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 essa chave única, também poderá fazer uma cópia do arquivo de chave pública, pois ele tem o mesmo formato do arquivo de chaves autorizado. Algo como
scp -p ~/.ssh/kev_rsa.pub remotehost:~/.ssh/authorized_keys
ou, se você tiver sua chave pública no mesmo sistema, poderá fazer
cat ~/.ssh/kev_rsa.pub >> ~/.ssh/authorized_keys

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

Scott Pack
fonte
1
Olá, obrigado pelo seu esforço aqui. Eu aprecio isso. Definitivamente, não é um problema de permissões. Eu verifiquei que as permissões estão corretas. (Eu deveria ter acrescentado isso como uma ressalva). Além disso, embora eu não possa acessar as chaves originais no momento, duplicou o processo usado para copiar a chave que estou usando. Eu até fiz um md5sum para verificar se os arquivos são idênticos. Faz sentido?
kevin
1
E, novamente, não consigo acessar o servidor. Tipo de todo o problema aqui ...;)
kevin
@ Scott: make a copy of the private key filedeve ser a chave pública (como mostrado em seus exemplos)
MLP
0

No entanto, você provavelmente precisará gerar um novo par de chaves para a máquina 2 se conectar ao servidor. Freqüentemente, a chave pública lista o nome do usuário e da máquina daqueles que os geraram. Isso deve ficar aparente no seu arquivo allowed_keys no servidor.

Dru
fonte
2
Fiquei com a impressão de que eles são ignorados, que são simplesmente comentários para ajudá-lo a identificá-los ao visualizar as teclas_autorizadas. De qualquer forma, novamente, apenas copiei / colei as chaves. Então eles são idênticos. Eu duvido seriamente que ele verifique seu nome de host. Se isso acontecesse, eu poderia mudar isso facilmente. Que diabos, eu vou tentar isso de qualquer maneira ...
kevin
0

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

Ansgar Esztermann
fonte
-3

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

ie algo como cat / etc / sshd_config

ae.
fonte
Eu deveria ter sido mais claro. Existem dois clientes, um servidor. Não consigo acessar o servidor ou a outra máquina cliente. I será capaz de acessar o servidor, logo que esta chave maldita irá autenticar;)
kevin