Como permitir chaves de host SSH no Linux (Fedora 10 e CentOS 5.2)

Question

Estou tentando configurar chaves de host SSH do nosso servidor de backup central baseado no Mac OS X 10.5 Leopard Server para nossos dois servidores Linux que executam o Fedora 10 e o CentOS 5.2. O processo que geralmente tomamos funciona e coloca a chave em ~ / .ssh / authorized_keys, mas ainda pede a senha.

Eu não sou o administrador regular dessas caixas e entendo que o padrão é provavelmente ter chaves de host SSH desabilitadas. Como habilitar chaves de host SSH?

Atualização: eu já tinha desatualizado 'PubkeyAuthentication yes' em / etc / ssh / ssd_config e executei service restart sshd , mas isso não funcionou. Uncommented todas as três linhas ('RSAAuthentication', 'PubkeyAuthentication' e 'AuthorizedKeysFile'), corrigiu as permissões em ~ / .ssh e tentou novamente. Ainda sem amor.

Quando executo ssh -v user@host , obtenho o seguinte antes de solicitar uma senha e depois de alguns erros de GSS:

debug1: Next authentication method: publickey
debug1: Trying private key: /Users/shortname/.ssh/identity
debug1: Trying private key: /Users/shortname/.ssh/id_rsa
debug1: Trying private key: /Users/shortname/.ssh/id_dsa
debug1: Next authentication method: password

Outras sugestões?

Outra atualização: as permissões em ~/ e ~/.ssh/ são 700.

O comando que estou executando para criar a chave do host é o seguinte:

cat /blah/ssh_keys_for_shortname/id_dsa.pub | ssh -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa host.domain.tld 'cat - >> ~/.ssh/authorized_keys'

E ao tentar conectar, eu uso:

ssh --verbose -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa host.domain.tld

Então, obviamente, estamos usando chaves DSA. Eu tentei renomear ~/.ssh/authorized_keys2 , mas isso não ajuda.

Adoraria armazenar as chaves em seus locais padrão em vez de /blah/ssh_keys_for_shortname/ , mas isso está fora do meu controle.

Quando vejo /var/log/audit/audit.log e tento me conectar, obtenho o seguinte:

type=CRED_DISP msg=audit(1249426114.642:128): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:setcred acct="shortname" exe="/usr/sbin/sshd" (hostname=host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_END msg=audit(1249426114.647:129): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:session_close acct="shortname" exe="/usr/sbin/sshd" (hostname=host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_LOGIN msg=audit(1249426129.524:130): user pid=10633 uid=0 auid=4294967295 ses=4294967295 msg='acct="shortname": exe="/usr/sbin/sshd" (hostname=?, addr=192.168.1.149, terminal=sshd res=failed)'

Sugestões?

    

Answer 1

Parece que você tem o básico correto.

O motivo mais comum que vi para isso falhar é as permissões no arquivo authorized_keys remoto e nos diretórios acima dele. Antes de permitir a autenticação baseada em chave, sshd executa uma verificação de permissões; se não gostar dos resultados, não permite a autenticação. Eu geralmente defino ~/.ssh para 0700 e ~/.ssh/authorized_keys para 0600. Acredito que o $ HOME real não pode ter gravação em grupo ou mundo, embora a leitura seja boa.

Se isso ainda não resolver, o próximo passo é fazer algumas depurações no lado do servidor:

server$ /usr/sbin/sshd -d -p 2222

Em seguida, conecte-se ao servidor "debug" do seu cliente:

client$ ssh -v user@host  -p 2222

Você receberá informações de depuração copiosas sobre stderr no servidor. Ainda não encontrei um problema de autenticação que não consegui rastrear a partir daí.

    

Answer 2

Aqui está o processo que eu seguiria.

1. Crie um par de chaves pública / privada no servidor OS X. Eu não especifico uma senha quando solicitado.

   $ ssh-keygen -b 4096 -C "myusername @ myhostname" -t rsa

2. Copie o conteúdo de ~ / .ssh / id_rsa.pub no servidor OS X para ~ / ssh / authorized_keys no diretório home do usuário correto nos hosts CentOS / Fedora.

3. Verifique se as permissões estão corretas em todos os hosts. O diretório ~ / .ssh deve estar no modo 0700, os arquivos dentro devem ser 0600 (você pode usar 0644 para as chaves públicas, mas não faz mal ser mais restritivo).

Se a autenticação baseada em chave ainda não estiver funcionando, verifique se os seguintes valores estão definidos em seu arquivo sshd_config (/ etc / ssh / sshd_config) em cada um dos hosts CentOS / Fedora. (Esses valores devem ser padrões).

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys

Se ainda assim não funcionar, tente ssh -v user@host para ver o que está acontecendo quando você se conecta. Adicione mais v's para ver mais detalhes sobre o que está acontecendo.

EDIT : Tente verificar as permissões na árvore de diretórios completa de / para o diretório .ssh em questão. Se qualquer um dos diretórios desse caminho for grupo ou mundo gravável, o SSH será bombardeado. Execute isto para imprimir as permissões de todos os diretórios no caminho:

j="" ; for i in 'echo ~baumgart/.ssh | sed 's%/% %g'' ; do ls -ld $j/$i ; j=$j/$i ; done

Além disso - verifique o arquivo de log para mensagens de sshd nos sistemas CentOS / Fedora - Isso deve ter uma mensagem útil sobre o que está errado. Deve estar em / var / log / messages ou /var/log/auth.log. Se você não consegue encontrá-lo, faça grep sshd /var/log/* .

    

Answer 3

Se você já definiu as permissões de usuário / grupo corretamente, talvez esteja encontrando problemas com o SELinux. A maneira mais fácil de corrigir isso é com restorecon -R /home/user/.ssh/ . Os erros serão registrados em /var/log/audit/audit.log e você pode usar a ferramenta audit2why para que o sistema explique quaisquer negações do SELinux que possam ter ocorrido.

    

Answer 4

A primeira coisa a destacar é que /var/log/audit.log está registrando a atividade SELinux .

Suponho que, se você olhar um pouco mais para trás nesse log, verá outra entrada com a seguinte aparência:

type=AVC msg=audit(xxxxxxxxx.xxx:xxxx): avc: denied { search } for pid=xxxxx comm="sshd" name="xxxxxx" dev=xxxx ino=xxxxxx scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir

O que isto significa é que o seu processo sshd é confinado pela política selinux carregada e não é capaz de acessar o caminho do sistema de arquivos no qual seu arquivo de chaves autorizado está instalado.

Para verificar se a política do selinux está ativa, execute o comando sestatus e você verá a seguinte saída:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted

Para testar rapidamente se esse é o problema ou não, você pode temporariamente configurar o SELinux no modo permissivo emitindo o comando setenforce permissive . Depois disso, execute sestatus novamente e você verá a seguinte saída:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted

Tente sua conexão ssh novamente e, como todas as outras configurações estão corretas, isso deve funcionar.

Seguindo em frente, você provavelmente deve criar regras personalizadas que permitam o acesso ao caminho que você procura, mas isso está além do escopo dessa ajuda.

Para tornar essa alteração persistente (sobreviver a reinicializações), é necessário modificar o arquivo /etc/selinux/config e alterar:

SELINUX=enforcing

para

SELINUX=permissive

    

Answer 5

'PubkeyAuthentication yes' em / etc / ssh / sshd_config?