On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:
Hi Rob,
Thanks for your email,
Yeah true FQDN is working without any issues.But is there any way to ssh via IP as well rather than hostname
Kerberos authentication is based on names of services known to your KDC. IP address is not a name in this context and is not associated with the service host/$FQDN, hence it is not found in the Kerberos database.
You can add such service name alias using 'ipa host-add-principal' command. It is, however, not always enough because most Kerberos services do not expect to operate with multiple aliases. Luckily, SSH works fine with such tickets in IPA environment.
$ ipa host-add-principal server.ipa.example host/10.40.1.201 --------------------------------------- Added new aliases to host "server.ipa.example" --------------------------------------- Host name: server.ipa.example Principal alias: host/server.ipa.example@IPA.EXAMPLE, host/10.40.1.201@IPA.EXAMPLE
On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden rcritten@redhat.com wrote:
Pradeep KNS wrote:
ssh kns@10.40.1.201 -v
[snip]
SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No such file or directory debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No such file or directory debug1: Host '10.40.1.201' is known and matches the ED25519 host key. debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
The SSSD ssh integration was used to to validate that the host's SSH key matched what was received so you avoided the "do you trust this host" prompt. So that's good.
debug1: rekey out after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 4294967296 blocks debug1: Will attempt key: /home/kns/.ssh/id_rsa debug1: Will attempt key: /home/kns/.ssh/id_dsa debug1: Will attempt key: /home/kns/.ssh/id_ecdsa debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk debug1: Will attempt key: /home/kns/.ssh/id_ed25519 debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk debug1: Will attempt key: /home/kns/.ssh/id_xmss debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com <mailto:sk-ssh-ed25519@openssh.com ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
sk-ecdsa-sha2-nistp256@openssh.com
webauthn-sk-ecdsa-sha2-nistp256@openssh.com
mailto:webauthn-sk-ecdsa-sha2-nistp256@openssh.com> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug1: Next authentication method: gssapi-with-mic *debug1: Unspecified GSS failure. Minor code may provide more
information
Server host/10.40.1.201@ALPHA-GREP.COM mailto:10.40.1.201@ALPHA-GREP.COM not found in Kerberos database*
IPA keys on hostnames, not IP addresses, hence this message. You need to use a FQDN. AFAIK there is no workaround.
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/kns/.ssh/id_rsa debug1: Trying private key: /home/kns/.ssh/id_dsa debug1: Trying private key: /home/kns/.ssh/id_ecdsa debug1: Trying private key: /home/kns/.ssh/id_ecdsa_sk debug1: Trying private key: /home/kns/.ssh/id_ed25519 debug1: Trying private key: /home/kns/.ssh/id_ed25519_sk debug1: Trying private key: /home/kns/.ssh/id_xmss debug1: Next authentication method: keyboard-interactive (kns@10.40.1.201 mailto:kns@10.40.1.201) Password:
It failed to do a Kerberos/GSSAPI auth so it fell back to password.
rob