Adicionar uma chave pública a ~ / .ssh / allowed_keys não me loga automaticamente

Adicionei a chave pública SSH ao arquivo allowed_keys . ssh localhostdeve me conectar sem pedir a senha.

Eu fiz isso e tentei digitar ssh localhost, mas ele ainda me pede para digitar a senha. Existe outra configuração pela qual eu tenho que passar para fazer funcionar?

Eu segui as instruções para alterar permissões:

Abaixo está o resultado, se eu fizer ssh -v localhost.

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Em seguida, solicita uma fase de passagem após o log acima. Por que não está me conectando sem uma senha?

Você precisa verificar as permissões do authorized_keysarquivo e as pastas pai / pasta em que ele está localizado.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Para mais informações, consulte esta página .

Você também pode precisar alterar / verificar as permissões do seu diretório pessoal para remover o acesso de gravação para o grupo e outros.

chmod go-w ~

O SELinux também pode fazer com que as teclas_autorizadas não funcionem. Especialmente para root no CentOS 6 e 7. No entanto, não é necessário desativá-lo. Depois de verificar se suas permissões estão corretas, você pode corrigir isso da seguinte maneira:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

definir ssh author_keys parece simples, mas esconde algumas armadilhas que estou tentando descobrir

-- SERVIDOR --

em / etc / ssh / sshd_config configurado passwordAuthentication yespara permitir que o servidor aceite temporariamente a autenticação por senha

-- CLIENTE --

considere o cygwin como emulação de linux e instale e execute o openssh

1. gerar chaves públicas e privadas (lado do cliente) # ssh-keygen

aqui, pressionando apenas ENTER, você obtém os arquivos PADRÃO 2 " id_rsa " e " id_rsa.pub " em ~ / .ssh / mas se você der um nome para a chave, os arquivos gerados são salvos no seu pwd

2. coloque o your_key.pub no computador de destinossh-copy-id user_name@host_name

se você não criou a chave padrão, este é o primeiro passo para dar errado ... você deve usar

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. o log ssh user_name@host_namefuncionará apenas para id_rsa padrão, então aqui está a segunda armadilha para você precisarssh -i path/to/key_name user@host

(use a opção ssh -v ... para ver o que está acontecendo)

Se o servidor ainda solicitar a senha , você deu a smth. para Enter passphrase: quando você criou chaves (por isso é normal)

se o ssh não estiver escutando, a porta padrão 22 deve usar ssh -p port_nr

-- SERVIDOR -----

4. modifique / etc / ssh / sshd_config para ter

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

(descomentado se for o caso)

Isso instrui o ssh a aceitar o author_keys e procurar no diretório inicial do usuário o nome do key_name sting gravado no arquivo .ssh / allowed_keys

5 definir permissões na máquina de destino

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Desative também a autenticação de passe

passwordAuthentication no

fechar o portão para todas as tentativas ssh root / admin /....@ your_domain

6 garanta que a propriedade e a propriedade do grupo de todos os diretórios pessoais não raiz sejam apropriadas.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

=================================================

7. considere o excelente http://www.fail2ban.org

8. TUNNEL ssh extra para acessar um servidor MySQL (bind = 127.0.0.1)

Verifique também se o diretório inicial não é gravável por outras pessoas

chmod g-w,o-w /home/USERNAME

A resposta é roubada daqui

os desesperados também podem garantir que não tenham novas linhas extras no arquivo allowed_keys devido à cópia do texto id_rsa.pub de um terminal confuso.

usuário é seu nome de usuário

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Observe que o SELinux também pode acionar esse erro, mesmo que todas as permissões pareçam estar OK. Desativá-lo fez o truque para mim (insira isenções de responsabilidade comuns sobre desativá-lo).

Listar uma chave pública em .ssh / allowed_keys é necessário, mas não suficiente para o sshd (servidor) aceitá-la. Se sua chave privada estiver protegida por senha, você precisará fornecer a senha ao ssh (cliente) toda vez. Ou você pode usar o ssh-agent ou um equivalente do GNOME.

Seu rastreamento atualizado é consistente com uma chave privada protegida por senha. Consulte ssh-agent ou use ssh-keygen -p.

Comando de gravação:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Depois de fazer isso, verifique se o seu diretório é assim:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

O que fez o truque para mim finalmente foi garantir que o proprietário / grupo não fosse raiz, mas usuário:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

Tente "ssh-add", que funcionou para mim.

Outra dica para lembrar. Como a v7.0 OpenSSH desabilita as chaves ssh DSS / DSA por padrão, devido a sua fraqueza herdada. Portanto, se você possui o OpenSSH v7.0 +, verifique se sua chave não está ssh-dss.

Se você estiver com as chaves DSA, poderá reativar o suporte localmente, atualizando seus arquivos sshd_confige ~/.ssh/configcom as seguintes linhas:PubkeyAcceptedKeyTypes=+ssh-dss

No meu caso, eu precisava colocar meu authorized_keysarquivo .openssh.

Esta localização é especificada na /etc/ssh/sshd_configopção AuthorizedKeysFile %h/.ssh/authorized_keys.

Verifique se o usuário de destino tem uma senha definida. Corra passwd usernamepara definir um. Isso foi necessário para mim, mesmo que o login SSH da senha estivesse desativado.

isso resolve meu problema

bash do agente ssh

ssh-add

Outra questão que você precisa cuidar. Se o seu arquivo gerado não for o padrão id_rsa e id_rsa.pub

É necessário criar o arquivo .ssh / config e definir manualmente qual arquivo de identificação você usará com a conexão.

O exemplo está aqui:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

I emitido sudo chmod 700 ~/.sshe chmod 600 ~/.ssh/authorized_keyse chmod go-w $HOME $HOME/.sshde cima e fixa o meu problema em uma caixa CentOS7 que eu tinha foi cancelada as permissões ao tentar obter samba ações trabalhando. obrigado

Parece um problema de permissão. Geralmente isso acontece se a permissão de algum arquivo / diretório não estiver configurada corretamente. Na maioria dos casos, eles são ~/.sshe ~/.ssh/*. No meu caso eles são /home/xxx.

Você pode alterar o nível de log do sshd modificando /etc/ssh/sshd_config(pesquise LogLevel, defina-o como DEBUG) e verifique a saída /var/log/auth.logpara ver o que aconteceu exatamente.

Meu problema foi um AuthorizedKeysFile modificado, quando a automação para preencher / etc / ssh / allowed_keys ainda não havia sido executada.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Basta consultar /var/log/auth.log no servidor . Definir verbosidade adicional com -vv no lado do cliente não ajudará, porque é improvável que o servidor ofereça muitas informações a um possível invasor.

Verifique se você copiou toda a chave pública para authorized_keys; o ssh rsaprefixo é necessário para que a chave funcione.

você precisa verificar as propriedades dos arquivos. para atribuir o uso de propriedade necessário:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

Procure no /var/log/auth.logservidor por sshderros de autenticação.

Se tudo mais falhar, execute o sshdservidor no modo de depuração:

sudo /usr/sbin/sshd -ddd -p 2200

Em seguida, conecte-se a partir do cliente:

ssh user@host -p 2200

No meu caso, encontrei a seção de erro no final:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Com essas informações, percebi que sshd_configestava restringindo os logins aos membros do sshgrupo. O comando a seguir corrigiu esse erro de permissão:

sudo usermod -a -G ssh NEW_USER

nessa nota, verifique se o sshd config possui -;

PermitRootLogin without-password

definido como acima, e reinicie o sshd (/etc/init.d/sshd restart)

saia e tente fazer login novamente!

padrão eu acredito que é -;

PermitRootLogin no

No meu caso, é porque o grupo do usuário não está definido no AllowGroups do arquivo de configuração / etc / ssh / sshd_config. Depois de adicioná-lo, tudo funciona bem.

Eu tenho o diretório inicial em um local não padrão e, nos sshdlogs, tenho esta linha:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

mesmo se todas as permissões forem boas (veja as outras respostas).

Encontrei uma solução aqui: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

No meu caso particular:

• adicionou uma nova linha em /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

  • esta é a linha original para diretórios pessoais regulares:

    /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • esta é minha nova linha:

    /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• seguido por um restorecon -r /data/e um sshdreinício

Eu tive esse problema e nenhuma das outras respostas o resolveu, embora, é claro, as outras respostas estejam corretas.

No meu caso, descobriu-se que o /rootdiretório em si (não por exemplo /root/.ssh) tinha as permissões erradas. Eu precisei:

chown root.root /root
chmod 700 /root

Obviamente, essas permissões devem ser algo assim (talvez chmod 770) independentemente. No entanto, especificamente impedido sshdde trabalhar, mesmo que /root/.sshe /root/.ssh/authorized_keysambos tinham permissões e proprietários corretos.

Eu tive esse problema quando adicionei o grupo do usuário de logon a outro usuário. Digamos que exista um usuário ssh-login chamado userA e um usuário não ssh-login userB. userA também possui o grupo userA. Eu modifiquei o userB para ter o grupo userA também. O lead para o comportamento descrito, para que o userA não possa efetuar login sem um prompt. Depois de remover o grupo userA do userB, o login sem aviso funcionou novamente.