Thanks Alexander,Thanks for the info On Tue, 3 Oct 2023 at 2:21 PM, Alexander Bokovoy <[email protected]> wrote:
> On Аўт, 03 кас 2023, Pradeep KNS wrote: > >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? > > It happens exactly same way as you'd do that without IPA. Something > should provide access to that private key. Typically people achieve that > by forwarding SSH authentication agent connection. Look at man page for > ssh about authentication agent. > > > > > > >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 > >> > >> > > > > > -- > / 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
