ssh sem senha não está funcionando


35

Eu tentei configurar um sem senha ssh b / w Ade Be Bpara Abem. Gerou a chave pública e privada usando ssh-keygen -trsanas duas máquinas. Utilizou o ssh-copy-idutilitário para copiar as chaves públicas de Apara Be também Bpara A.

O ssh sem senha funciona de Apara Bmas notde Bpara A. Verifiquei as permissões da pasta ~ / ssh / e parece normal.

A's .ssh permissões de pasta:

-rw-------  1 root root 13530 2011-07-26 23:00 known_hosts
-rw-------  1 root root   403 2011-07-27 00:35 id_rsa.pub
-rw-------  1 root root  1675 2011-07-27 00:35 id_rsa
-rw-------  1 root root   799 2011-07-27 00:37 authorized_keys
drwxrwx--- 70 root root  4096 2011-07-27 00:37 ..
drwx------  2 root root  4096 2011-07-27 00:38 .

B's .ssh permissões de pasta:

-rw------- 1 root root  884 2011-07-07 13:15 known_hosts
-rw-r--r-- 1 root root  396 2011-07-27 00:15 id_rsa.pub
-rw------- 1 root root 1675 2011-07-27 00:15 id_rsa
-rw------- 1 root root 2545 2011-07-27 00:36 authorized_keys
drwxr-xr-x 8 root root 4096 2011-07-06 19:44 ..
drwx------ 2 root root 4096 2011-07-27 00:15 .

Aé um ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009) Bé uma máquina debian (OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 de outubro de 2007)

De A:

#ssh B

funciona bem.

De B:

#ssh -vvv A 
...
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x7f1581f23a50)
debug2: key: /root/.ssh/id_dsa ((nil))
debug3: Wrote 64 bytes for a total of 1127
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1495
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.122.1's password: 

O que significa essencialmente que não é autenticado usando o arquivo /root/id_rsa. Eu executei o ssh-addcomando nas duas máquinas também.

A parte de autenticação do /etc/ssh/sshd_configarquivo é

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files

Estou ficando sem idéias. Qualquer ajuda seria apreciada.


Qual é a configuração de PermitRootLoginem /etc/ssh/sshd_configA?
27411 taneli

@taneli:, yescaso contrário, o usuário não será solicitado a fornecer uma senha.
27611 Lekensteyn

No meu caso, tive que descomentar "IgnoreUserKnownHosts yes" no arquivo "/ etc / ssh / sshd_config" no ubuntu 12.04
Martin Magakian

Respostas:


24

Apenas certifique-se de ter seguido o seguinte procedimento:

Na máquina A

abra um terminal e insira os comandos da seguinte maneira:

root@aneesh-pc:~# id

Só para ter certeza de que somos raiz.

Se o comando acima exibir algo como abaixo, nós somos root else alterne para root usando o sucomando

uid=0(root) gid=0(root) groups=0(root)

1) Crie as chaves.

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
49:7d:30:7d:67:db:58:51:42:75:78:9c:06:e1:0c:8d root@aneesh-pc
The key's randomart image is:
+--[ RSA 2048]----+
|          ooo+==B|
|         . E=.o+B|
|        . . .+.*o|
|       . . .  ...|
|        S        |
|                 |
|                 |
|                 |
|                 |
+-----------------+

Eu não usei nenhuma senha. Se você precisar de um, pode usá-lo.

2) Copie a chave pública no .ssh/authorized_keysarquivo da máquina B

root@aneesh-pc:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@mylap
root@mylap's password: 

Agora tente fazer login na máquina com ssh 'root@mylap'e faça o check-in:

~/.ssh/authorized_keys

para garantir que não adicionamos chaves extras que você não esperava.

Substitua mylap pelo nome do host ou ip da máquina na qual você deseja fazer login (ou seja, máquina B)

3) Entre no B sem senha

root@aneesh-pc:~# ssh root@mylap
Warning: Permanently added 'mylap,192.168.1.200' (RSA) to the list of known hosts.
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Wed Jul 27 15:23:58 2011 from streaming-desktop.local
aneesh@mylap:~$

Na máquina B

4) Crie as chaves para efetuar login novamente na Máquina A

root@mylap:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
35:9f:e7:81:ed:02:f9:fd:ad:ef:08:c6:4e:19:76:b1 root@streaming-desktop
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|          o   .  |
|         . + + o |
|        S o * E  |
|           = O . |
|            O +  |
|           + o o.|
|            . o+=|
+-----------------+

5) Copie a chave pública no .ssh/authorized_keysarquivo da máquina A

root@mylap:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@aneesh-pc
Warning: Permanently added 'aneesh-pc,192.168.1.20' (RSA) to the list of known hosts.
root@aneesh-pc's password: 

Agora tente fazer login na máquina com ssh 'root@aneesh-pc'e faça o check-in:

.ssh/authorized_keys

para garantir que não adicionamos chaves extras que você não esperava.

6) Faça o login em A sem senha

ssh root@aneesh-pc
Warning: Permanently added 'aneesh-pc,192.168.1.20' (RSA) to the list of known hosts.
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/


Last login: Tue Jul 26 18:52:55 2011 from 192.168.1.116

Se você é capaz de concluir estas etapas, você terminou. Agora você tem duas máquinas com login ativado por ssh-key (chave pública).


fez todos os 6 passos conforme especificado, verificou todas as coisas relacionadas até a etapa 5, mas de alguma forma o passo 6 não está funcionando
Cuurious

Você pode fornecer a saída deste comando: 'ssh -v root @ aneesh-pc'. substitua o nome de usuário e o nome do host pelo seu.
aneeshep

15
descobriu o culpado as permissões do /root(770) drwxrwx--- 70 root root 4096 2011-07-27 00:37 .. estavam muito abertas. Alterou as permissões drwxr-xr-xe agora está funcionando. Não era possível imaginar o fato de a permissão do diretório pai afetar o arquivo ssh.
Cuurious

1
@Cuurious Boa captura, meu diretório pessoal 770também definiu, mudou para a 750e está tudo certo com o mundo :) Sempre pareço esquecer que os prems linux podem funcionar ao contrário dessa maneira.
complistic

1
Falha na etapa 3. O ssh-copy-id é executado depois que eu digito uma senha, mas ainda não consigo fazer o login sem ser solicitada uma senha, meu arquivo author_keys contém o texto do meu .pub e estou oferecendo a chave no login . Não disponível. A permissão em todos os diretórios está correta.
Matt Clark

44

Depois de configurar o ssh sem senha , ainda me pediram minha senha de usuário. Olhando para /var/log/auth.loga máquina remota apontou o problema:

sshd[4215]: Authentication refused: bad ownership or modes for directory /home/<user>

Portanto, certifique-se de que está correto:

chmod o-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Embora .sshseja óbvio proibir outros usuários de escrever sobre sua pasta, é mais difícil ter o mesmo requisito para sua pasta pessoal.

Além disso, verifique /etc/ssh/ssd_configse as opções RSAAuthenticatione PubkeyAuthenticationnão estão desabilitadas. O padrão é yesque não deve ser um problema.


Também certifique-se essas pastas listados acima são de propriedade do usuário correto
GoalBased

Entrei nessa situação desarquivando um arquivo de driver realtek mal criado. Ele mudou o proprietário no diretório em que eu estava descompactando-o.
Paul McMillan

2
Sua pasta pessoal não pode ser gravada porque, se fosse, eu poderia renomear sua ~/.sshpara outra coisa e criar uma nova com minha própria chave.
precisa

2
impressionante! não tinha pensado em procurar nos logs da máquina host. Obrigado!
user3099609

14

Provavelmente apenas um problema de permissões de nível superior. Você precisa remover as permissões de gravação do grupo e outras para o diretório inicial e o diretório .ssh. Para corrigir essas permissões, execute chmod 755 ~ ~/.sshou chmod go-w ~ ~/.ssh.

Se você ainda estiver com problemas, emita o seguinte grep em seu log:

sudo egrep -i 'ssh.*LOCAL_USER_NAME' /var/log/secure

(substitua LOCAL_USER_NAMEpelo seu nome de usuário local ...)

Espero que isso lhe conte mais sobre o seu problema, supondo que as informações de autenticação sshd estejam sendo registradas no log seguro, o que deve ser o padrão. Se você vir erros parecidos com este:

DATE HOSTNAME sshd [1317]: autenticação recusada: propriedade incorreta ou modos para o diretório / caminho / para / algum / diretório

É o problema descrito acima e você precisa encontrar o diretório em questão e remover as permissões de gravação do grupo e de outros.

Pelo motivo de você precisar restringir as permissões de gravação ao seu diretório pessoal (mesmo que as permissões já estejam restritas nos diretórios .ssh e subseqüentes), outros usuários poderão renomear o diretório .ssh e criar um novo - embora seria inutilizável como é (devido a permissões incorretas) a correção para a maioria dos usuários provavelmente seria alterar as permissões em vez de verificar o conteúdo do diretório ...

TLDNR : Permitir acesso de gravação para grupo e / ou outro em seu diretório pessoal fará com que o ssh force o login da senha.


2

você está usando a conta root em cada máquina? Geralmente no Ubuntu, você usaria uma conta de usuário e concederia privilégios de sudo, conforme necessário.

Se o uso de um usuário não root sudo chown $USER -R ~/.sshpode resolver seu problema

Outras coisas para verificar:

verifique novamente se B id_rsa.pubestá em A's authorized_keys.

verifique A /etc/ssh/sshd_configcontém

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes

Sim, eu habilitei a conta root na máquina Ubuntu, portanto, executando como usuário root no sistema #
602

Sim, eu pensei, adicionei algumas outras sugestões que você pode ter esquecido. Essa saída é realmente inútil, embora não seja, nada sobre por que o rsa não foi aceito.
Smithamax

1
você é verdadeiro, a razão pela qual a chave rsa não foi aceita é o elemento essencial aqui, eu acho :). o sshd_config contém os elementos acima mencionados, editei a questão para incorporar o conteúdo do /etc/ssh/sshd_configarquivo #
Cuurious

-3

em / etc / ssh / sshd_config na alteração de destino

PermitRootLogin no

para

PermitRootLogin sim

então mate -HUP seu PID sshd:

root @ dzone2 # ps -ef | grep ssh raiz 28075 27576 0 17 de novembro? 6:11 / usr / lib / ssh / sshd

root 17708 20618   0 10:09:30 pts/37      0:00 grep ssh root@dzone2 # kill -HUP 28075 root@dzone2 # ps -ef|grep ssh
root 17861 20618   0 10:09:44 pts/37      0:00 grep ssh
root 17852 27576   0 10:09:42 ?           0:00 /usr/lib/ssh/sshd

1
Isso não vai ajudar. O problema é que o login SSH sem senha (autenticando com um par de chaves RSA) não está funcionando. As instruções fornecidas são para fazer o rootlogin SSH funcionar. Isso não tem nenhuma relação com o que é essa pergunta. Além disso, se a rootconta estiver ativada (não é por padrão no Ubuntu), ativar rootlogins SSH pode ser bastante perigoso.
Eliah Kagan
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.