Publicando o comentário de Xenoid como resposta:
Faça o comando ssh -v {host} e você terá uma lista completa dos protocolos de autenticação verificados (o último deles é o usado). - xenoid 2 de Jul às 20:20
NOTA: Crédito devido ao Xenoid
Estou tentando entender o mecanismo pelo qual estou executando com êxito a autenticação SSH sem senha. Embora a autenticação de chave pública esteja habilitada, isso não é como está acontecendo. Eu tenho minha chave pública comentada no meu arquivo authorized_keys . Além disso, não tenho certeza se o arquivo authorized_keys de meu usuário pessoal entra em ação, já que estamos usando a implementação LDAP do FreeIPA para autenticação.
A configuração SSH do lado do cliente faz parecer que a autenticação baseada em host está sendo usada. No entanto, a configuração SSH do lado do servidor tem a autenticação baseada em host desativada.
Abaixo, forneço o que acredito ser todas as informações de configuração relevantes.
Do que é fornecido abaixo, alguém poderia me explicar como a autenticação sem senha está ocorrendo? Se não, que informações adicionais posso fornecer para ajudar?
Obrigado antecipadamente!
CentOS: 7.3.1611
ipa-client.x86_64 4.4.0-14.el7.centos.7
ipa-client-common.noarch 4.4.0-14.el7.centos.7
ipa-common.noarch 4.4.0-14.el7.centos.7
sssd-ipa.x86_64 1.14.0-43.el7_3.18
openssh.x86_64 6.6.1p1-35.el7_3
sssd.x86_64 1.14.0-43.el7_3.18
sssd-ad.x86_64 1.14.0-43.el7_3.18
sssd-client.x86_64 1.14.0-43.el7_3.18
sssd-common.x86_64 1.14.0-43.el7_3.18
sssd-common-pac.x86_64 1.14.0-43.el7_3.18
sssd-ipa.x86_64 1.14.0-43.el7_3.18
sssd-krb5.x86_64 1.14.0-43.el7_3.18
sssd-krb5-common.x86_64 1.14.0-43.el7_3.18
sssd-ldap.x86_64 1.14.0-43.el7_3.18
sssd-proxy.x86_64 1.14.0-43.el7_3.18
PubkeyAuthentication sim
GlobalKnownHostsFile / var / lib / sss / pubconf / known_hosts
ProxyCommand / usr / bin / sss_ssh_knownhostsproxy -p% p% h
Anfitrião *
GSSAPIAutenticação sim
Abaixo, forneço as opções de configuração do sshd que acredito serem relevantes. Por favor, deixe-me saber se o valor de outras opções é necessário. Estes foram obtidos executando sshd -T ao invés de apenas copiar e colar de / etc / ssh / sshd_config. Então, eles devem ser o que realmente está em vigor.
allowtcpforwarding sim
authenticationmethods any
authorizedkeyscommand / usr / bin / sss_ssh_authorizedkeys
authorizedkeysfile .ssh / authorized_keys
challengeresponseauthentication yes
gatewayports no
gssapiauthentication sim
gssapicleanupcredentials yes
gssapienablek5users no
gssapikexalgorithms gss-gex-sha1-, gss-group1-sha1-, gss-group14-sha1-
gssapikeyexchange no
gssapistorecredentialsonrekey no
gssapistrictacceptorcheck sim
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
ignoreuserknownhosts no
kbdinteractiveauthentication sim
kerberosauthentication no
kerberosorlocalpasswd sim
kerberosticketcleanup sim
kerberosusekuserok sim
senhaauthentication sim
permitopen any
permittunnel no
permituserenvironment no
pubkeyauthentication sim
strictmodes sim
usedns no
uselogin no
usepam sim
Da sua lista de pacotes:
sssd-ipa.x86_64 1.14.0-43.el7_3.18
sssd-krb5.x86_64 1.14.0-43.el7_3.18
Da sua configuração do servidor SSH:
gssapiauthentication yes
Da sua configuração do cliente SSH:
GSSAPIAuthentication yes
Com base em suas informações, presumo que você registrou seu host como cliente IPA com FreeIPA e provavelmente está usando a conexão única baseada em Kerberos por meio de GSSAPI .
Principalmente, você teria feito kinit [email protected] antes do login SSH para obter um ticket de concessão de tíquete Kerberos (TGT), que você pode listar com o comando klist junto com os tíquetes de serviço obtidos.
Para saber com certeza, seria útil ver a saída de ssh -v como os outros já escreveram e adicionar quais documentos / instruções você seguiu ao configurar tudo isso.