O SSH Alias solicita a autenticação por código, mas o SSH direto funciona

1

Eu estou tentando SSH em um servidor em que tenho sshd em execução (vamos chamá-lo de mim @ servidor). Eu configurei as chaves ssh usando ssh-keygen -t rsa para criar a chave e, em seguida, executei cat ~/.rsa/id_rsa.pub | ssh user@server 'cat >> ~/.ssh/authorized_keys' . Agora quando eu corro ssh user@server eu conecto ao servidor não tem problema. Mas quando eu uso o alias ssh server , sou solicitado pela senha da minha chave (que não tem uma senha) e, eventualmente, insiro a senha de user@server (que é o que eu estava tentando evitar em primeiro lugar.

Aqui está o meu .ssh/config na minha máquina local:

Host server
    HostName my_ip
    User user
    IdentityFile ~/.ssh/id_rsa.pub

Eu verifiquei todas as permissões de arquivo / diretório na máquina local e remota, e todas pareciam estar corretas. Alguém tem alguma ideia do que está acontecendo?

UPDATE

Então eu percebi que desde que o login funcionou sem a opção -i ~/.ssh/id_rsa.pub eu poderia também tentar o host sem o IndentityFile ~/.rsa/id_rsa.pub Então eu tirei essa linha do arquivo de configuração e tudo funcionou. Eu não tenho idéia do porquê. Alguém se importa em explicar isso?

    
por cderwin 06.08.2014 / 04:21

2 respostas

1
IdentityFile ~/.ssh/id_rsa.pub
-i ~/.ssh/id_rsa.pub

Você está especificando a chave pública aqui. Você deve especificar a chave privada. A chave privada provavelmente denominada ~/.ssh/id_rsa .

~/.ssh/id_rsa é um dos nomes de arquivos de chaves padrão que ssh procura. Quando você removeu a especificação incorreta de arquivo-chave do seu comando, ssh provavelmente voltou a procurar por suas chaves padrão e usou id_rsa para a sessão.

    
por 06.08.2014 / 15:40
0

Primeiro, você tem certeza de que está solicitando a senha do seu arquivo de chave e não a senha do servidor remoto?

Em segundo lugar, o SSH tem um modo de depuração incrivelmente detalhado se você especificar as opções da linha de comando: -v -v -v

Você pode fazer o mesmo no servidor: -d -d -d

Isso deve dizer exatamente o que está acontecendo nos dois lados e explicar qualquer comportamento bizarro.

Se eu tivesse que adivinhar, suspeito que o cliente SSH está resolvendo uma chave privada diferente e, em seguida, forçando um prompt por algum motivo, mas a saída de depuração é a maneira de descobrir.

Se eu tiver 4 chaves privadas diferentes, listarei todas elas como entradas do IdentityFile. Isso deve resolver esse problema - se, de fato, estiver substituindo uma chave inesperada.

    
por 06.08.2014 / 06:45