Thanks for the information. Will go through the document. But if i add the public key i am able authenticate from server A to server B and C from same Server A.
But if i want to communicate in-between Server B to Server C how this ipa will work? should i want to copy my pvt key?? Across all the hosts so that internal communication will happens? On Tue, 3 Oct 2023 at 2:11 PM, Alexander Bokovoy <[email protected]> wrote: > 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 <[email protected]> > >wrote: > > > >> Awesome, thanks for the info! > >> > >> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy <[email protected]> > >> 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/[email protected], > >>> host/[email protected] > >>> > >>> > >>> > >>> > > >>> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden <[email protected]> > >>> wrote: > >>> > > >>> >> Pradeep KNS wrote: > >>> >> > ssh [email protected] -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,[email protected] > >>> >> > <mailto:[email protected] > >>> >> > >>> > >,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, > >>> >> [email protected] > >>> >> > <mailto:[email protected]>, > >>> >> [email protected] > >>> >> > <mailto:[email protected]>> > >>> >> > 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/[email protected] > >>> >> > <mailto:[email protected]> 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 > >>> >> > ([email protected] <mailto:[email protected]>) 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 > >
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
