Autenticação de chave pública para usuários LDAP usando authorized_keys locais

3

Estamos usando o LDAP para informações da conta. O ambiente é configurado da seguinte forma ...

  • Um servidor de diretório do OpenLDAP do CentOS 7
  • Um cliente do CentOS 7 configurado para usar o servidor de diretórios
      O
    • authconfig foi usado para configurar o cliente do CentOS 7 para autenticação LDAP

Eu notei o seguinte

  • Um usuário local (um cujas informações de conta estão em / etc / passwd) pode ssh para o próprio cliente sem usar a autenticação de chave pública (sem uma senha)
  • Um usuário LDAP pode ssh para o próprio cliente usando uma senha
  • Um usuário LDAP não pode ssh para o próprio cliente usando autenticação de chave pública. O usuário possui chaves ssh configuradas corretamente ( id_rsa.pub , id_rsa ) e authorized_keys semelhantes ao usuário local

A saída de depuração ao executar um ssh usando o usuário local é

debug1: Offering RSA public key: /home/localuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279

A saída de depuração ao executar um ssh usando o usuário LDAP é

debug1: Offering RSA public key: /home/ldapuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic

O log, / var / log / secure, possui a seguinte entrada após o usuário LDAP tentar se conectar usando a autenticação de chave pública

Mar 19 16:47:01 localhost sshd[20539]: Connection closed by x.x.x.x [preauth]

O LDAP pode localizar a conta do usuário

$ getent passwd ldapuser
ldapuser:x:5001:5000::/home/ldapuser:/bin/bash

Quando o ssh permite PasswordAuthentication

$ ssh test
ldapuser@test's password: 
Last failed login: Sat Mar 19 17:08:29 UTC 2016 from x.x.x.x on ssh:notty
Last login: Sat Mar 19 15:55:40 2016

Eu percebo que existem alternativas como o OpenSSH-LPK, mas gostaria de poder usar um local authorized_keys que instalou usando o Puppet, pois não requer a manutenção do LDAP. Não tenho certeza se essa abordagem é possível e, se for, da configuração de sshd, PAM ou LDAP. Quaisquer ponteiros seriam apreciados ...

Seguindo a sugestão de Jakuje de configurar o nível de log para DEBUG para sshd, os logs continham a pista

Mar 19 18:22:42 localhost sshd[20934]: debug1: temporarily_use_uid: 5001/5000 (e=0/0)
Mar 19 18:22:42 localhost sshd[20934]: debug1: trying public key file /home/ldapuser/.ssh/authorized_keys
Mar 19 18:22:42 localhost sshd[20934]: debug1: Could not open authorized keys '/home/ldapuser/.ssh/authorized_keys': Permission denied
Mar 19 18:22:42 localhost sshd[20934]: debug1: restore_uid: 0/0

Os diretórios / e / home possuem as seguintes permissões

$ ll -and / /home
dr-xr-xr-x. 17 0 0 4096 Feb 22 17:26 /
drwxr-xr-x.  5 0 0   45 Mar 19 03:05 /home

O diretório / home / ldapuser tem as seguintes permissões

$ ll -an .
drwxr-xr-x. 3 5001 5000  99 Mar 19 16:46 .
drwxr-xr-x. 5    0    0  45 Mar 19 03:05 ..
drwx------. 2 5001 5000  76 Mar 19 02:45 .ssh

O diretório /home/ldapuser/.ssh tem as seguintes permissões

$ ll -an .
total 16
drwx------. 2 5001 5000   76 Mar 19 02:45 .
drwxr-xr-x. 3 5001 5000   99 Mar 19 16:46 ..
-rw-r--r--. 1 5001 5000  419 Mar 19 02:45 authorized_keys
-rw-------. 1 5001 5000 1679 Mar 19 02:45 id_rsa
-rw-r--r--. 1 5001 5000  419 Mar 19 02:45 id_rsa.pub
-rw-r--r--. 1 5001 5000  177 Mar 19 02:45 known_hosts

O daemon sshd está configurando o usuário efetivo para 5001/5000 e, portanto, não tem certeza do motivo pelo qual a permissão seria negada. O usuário root pode alternar para o ldapuser para que o sistema esteja ciente do usuário.

Jakuje: Muito obrigada! O SELinux foi a causa do problema e a execução do restorecon corrigiu o problema. Agradeço sua ajuda e paciência!

    
por bkeyser5280 19.03.2016 / 18:22

2 respostas

1

O SELinux está ligado? Quais são os respectivos rótulos nesses arquivos?

ls -lZ /home/ldapuser /home/ldapuser/.ssh /home/ldapuser/.ssh/authorized_keys

A execução de restorecon -rf /home/ldapuser/ deve corrigir os problemas.

    
por 19.03.2016 / 20:16
0

O diretório inicial do usuário LDAP precisa pertencer ao uid do usuário. O mesmo com o diretório .ssh dentro da home do usuário LDAP e a chave pública (authorized_keys) dentro do diretório .ssh.

Exemplo:

mkdir -p /home/ldapuser/.ssh

cp authorized_keys /home/ldapuser/.ssh

getent passwd
...
kibosh:*:6035:100:kibosh:/home/kibosh:/bin/bash
ldapuser:*:6036:100:ldapuser:/home/ldapuser:/bin/bash

chmod -R 6036:users /home/ldapuser

ls -l /home
drwxr-xr-x  4 ldapuser         users      4096 Nov  2 10:40 ldapuser
...

Nota: o gid 100 é o código dos usuários do grupo local no meu sistema.

Além disso, verifique se as permissões estão corretas para $ HOME / .ssh e $ HOME / .ssh / authorized_keys, etc.

    
por 02.11.2016 / 15:50