On Аўт, 03 кас 2023, Pradeep KNS wrote:
>Hi Alexander,
>
>Thanks for your email,
>Like this i need to add all servers? As my dns is located in internal
>different server.
Only if you need to use Kerberos authentication.
>
>Also if i want to jump from one server to another server on ipa clients
>using sshkeybased? How this mechanism works? here
If you are using SSH keypairs, you are not using Kerberos and thus don't
need these aliases at all.
If you want to use SSH keypair to authenticate, then upload public SSH
key for that user to IPA.
In general, almost all these details covered in the RHEL IdM
documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/managing-public-ssh-keys_managing-users-groups-hosts
>
>
>
>
>On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS <kns.prad...@alpha-grep.com>
>wrote:
>
>> Awesome, thanks for the info!
>>
>> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy <aboko...@redhat.com>
>> wrote:
>>
>>> 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 <rcrit...@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-ed25...@openssh.com
>>> >> > <mailto:sk-ssh-ed25...@openssh.com
>>> >>
>>>
>,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
>>> >> sk-ecdsa-sha2-nistp...@openssh.com
>>> >> > <mailto:sk-ecdsa-sha2-nistp...@openssh.com>,
>>> >> webauthn-sk-ecdsa-sha2-nistp...@openssh.com
>>> >> > <mailto:webauthn-sk-ecdsa-sha2-nistp...@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....@alpha-grep.com
>>> >> > <mailto:10.40.1....@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
>>> >>
>>> >>
>>>
>>>
>>>
>>>
>>> --
>>> / Alexander Bokovoy
>>> Sr. Principal Software Engineer
>>> Security / Identity Management Engineering
>>> Red Hat Limited, Finland
>>>
>>>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
