Free IPA DNS Issues

[Pradeep KNS]

Hello Team,

While setting up Freeipa in my Linux infrastructure.I noticed a strange
warning. I would like to clarify before rolling into production.

*DNS zone alpha-grep.com http://alpha-grep.com. already exists in DNS and
is handled by server(s): ['ns2.', 'ns1.'] Please make sure that the domain
is properly delegated to this IPA server.*

Detailed installation log i have updated in this link. Please suggest me
will it be any security flaw in future.Before installing it on production.

https://bpa.st/AMITK

[Rob Crittenden]

Pradeep KNS via FreeIPA-users wrote:
> Hello Team,
>
> While setting up Freeipa in my Linux infrastructure.I noticed a strange
> warning. I would like to clarify before rolling into production.
>
> *|DNS zone alpha-grep.com http://alpha-grep.com. already exists in DNS
> and is handled by server(s): ['ns2.', 'ns1.'] Please make sure that the
> domain is properly delegated to this IPA server.|*
>
> Detailed installation log i have updated in this link. Please suggest me
> will it be any security flaw in future.Before installing it on production.
>
> https://bpa.st/AMITK

I'm not sure what security issue you are worried about but you
explicitly allow this configuration with the --allow-zone-overlap
install option.

Your domain DNS is managed externally and you've installed a DNS server
to be authoritative for the same domain. If you want to expose you IPA
DNS to the Internet you'll need to repoint the nameservers on your
domain to your IPA host.

If what you're hoping to do is provide views, to limit what hosts are
resolvable depending on where the request is coming from, that is not
available in IPA. While IPA uses bind under the hood not all
capabilities are exposed.

So whether this configuration is acceptable or not is up to you.

rob

[Pradeep KNS]

Hi Rob,

Thank you for your valuable insights on FreeIPA and DNS. I have an existing
internal DNS server that I would like to integrate with FreeIPA's DNS
feature. As I understand it, FreeIPA can serve as an integrated DNS
solution. However, I would like to ensure that my existing internal DNS
infrastructure is utilized alongside FreeIPA's DNS capabilities.

Could you provide guidance on how to configure FreeIPA to work with my
internal DNS server? Specifically, I'd like to achieve the following:

- Use FreeIPA for centralized user authentication and management.
   - Integrate my existing internal DNS server with FreeIPA's DNS, so I can
   manage internal DNS records within FreeIPA while maintaining the internal
   DNS functionality.

I want to avoid any conflicts between FreeIPA's DNS and my existing
internal DNS server. Your expertise in this matter would greatly assist me
in achieving a successful and well-integrated DNS solution.

Thank you for your time and support.

On Wed, Aug 30, 2023 at 6:34 PM Rob Crittenden  wrote:
> Pradeep KNS via FreeIPA-users wrote:
> > Hello Team,
> >
> > While setting up Freeipa in my Linux infrastructure.I noticed a strange
> > warning. I would like to clarify before rolling into production.
> >
> > *|DNS zone alpha-grep.com http://alpha-grep.com. already exists in DNS
> > and is handled by server(s): ['ns2.', 'ns1.'] Please make sure that the
> > domain is properly delegated to this IPA server.|*
> >
> > Detailed installation log i have updated in this link. Please suggest me
> > will it be any security flaw in future.Before installing it on
>
> production.
> > https://bpa.st/AMITK
>
> I'm not sure what security issue you are worried about but you
> explicitly allow this configuration with the --allow-zone-overlap
> install option.
>
> Your domain DNS is managed externally and you've installed a DNS server
> to be authoritative for the same domain. If you want to expose you IPA
> DNS to the Internet you'll need to repoint the nameservers on your
> domain to your IPA host.
>
> If what you're hoping to do is provide views, to limit what hosts are
> resolvable depending on where the request is coming from, that is not
> available in IPA. While IPA uses bind under the hood not all
> capabilities are exposed.
>
> So whether this configuration is acceptable or not is up to you.
>
> rob

[Rafael Jeffman]

Hi Pradeep,

On Wed, Aug 30, 2023 at 3:27 PM Pradeep KNS via FreeIPA-users <
[e-mail]> wrote:
> Hi Rob,
>
> Thank you for your valuable insights on FreeIPA and DNS. I have an

existing internal DNS server that I would like to integrate with FreeIPA's
DNS feature. As I understand it, FreeIPA can serve as an integrated DNS
solution. However, I would like to ensure that my existing internal DNS
infrastructure is utilized alongside FreeIPA's DNS capabilities.
> Could you provide guidance on how to configure FreeIPA to work with my

internal DNS server? Specifically, I'd like to achieve the following:
> Use FreeIPA for centralized user authentication and management.

That would be just setting up FreeIPA and maintaining correct DNS records,
so I won't jump into this one.
> Integrate my existing internal DNS server with FreeIPA's DNS, so I can

manage internal DNS records within FreeIPA while maintaining the internal
DNS functionality.
>

Is a short answer: you can't.

The longer answer might provide a way to almost have what you want.

FreeIPA's embedded nameserver has to be authoritative, and you can only
manage its records, not the ones on your current DNS infrastructure.

To change DNS management to FreeIPA you'd have to set your internal DNS
nameserver to be a secondary nameserver, and configure FreeIPA's
nameserver to notify the internal nameserver of changes. It's doable, but I
would not recommend doing so.

Another possibility is to change DNS infrastructure to use FreeIPA instead
of
the current nameserver.

If you can manage your internal zones with the limitations that FreeIPA's
nameserver has (e.g. split-view is not supported), then you could plan on
retiring the current nameserver in favor of the FreeIPA one. With replicas
you
can also get redundancy on the nameservers.

If your current nameserver is exposed to the world, again, I'd suggest
against
this move.

Bottom line, either use your current DNS infrastructure or fully migrate to
FreeIPA.

Rafael
> I want to avoid any conflicts between FreeIPA's DNS and my existing

internal DNS server. Your expertise in this matter would greatly assist me
in achieving a successful and well-integrated DNS solution.
> Thank you for your time and support.
>
> On Wed, Aug 30, 2023 at 6:34 PM Rob Crittenden

wrote:
> > Pradeep KNS via FreeIPA-users wrote:
> > > Hello Team,
> > >
> > > While setting up Freeipa in my Linux infrastructure.I noticed a strange
> > > warning. I would like to clarify before rolling into production.
> > >
> > > *|DNS zone alpha-grep.com http://alpha-grep.com. already exists in

DNS
> > > and is handled by server(s): ['ns2.', 'ns1.'] Please make sure that the
> > > domain is properly delegated to this IPA server.|*
> > >
> > > Detailed installation log i have updated in this link. Please suggest

me
> > > will it be any security flaw in future.Before installing it on

production.
> > > https://bpa.st/AMITK
> >
> > I'm not sure what security issue you are worried about but you
> > explicitly allow this configuration with the --allow-zone-overlap
> > install option.
> >
> > Your domain DNS is managed externally and you've installed a DNS server
> > to be authoritative for the same domain. If you want to expose you IPA
> > DNS to the Internet you'll need to repoint the nameservers on your
> > domain to your IPA host.
> >
> > If what you're hoping to do is provide views, to limit what hosts are
> > resolvable depending on where the request is coming from, that is not
> > available in IPA. While IPA uses bind under the hood not all
> > capabilities are exposed.
> >
> > So whether this configuration is acceptable or not is up to you.
> >
> > rob
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:

https://pagure.io/fedora-infrastructure/new_issue

--
Rafael Guterres Jeffman
Senior Software Engineer
FreeIPA - Red Hat

[Yavor Marinov]

Hey guys,

I would suggest an easier and quite simple method: create a subdomain in
your current DNS, and describe its NSes to point to FreeIPA's DNSes.
Configure FreeIPA with a subdomain, instead of the domain and if you need
to create forwarding rules in FreeIPA to use your main DNS as a forwarder.
Additionally newly added infra, can be just CNAME-ed into your main DNS
with specifics (or even A record). Offering this, because in current infra
we are using google's DNS for the domain, and our centralized login can be
used with both of the domain and the subdomain. The only "frustrating"
thing is that i need to change the client's DNS (eg resolv.conf) when I'm
enrolling them, to point to FreeIPA and be able to properly enroll their
DNS records into FreeIPA

~br

On Wed, Aug 30, 2023 at 11:26 PM Rafael Jeffman via FreeIPA-users <
[e-mail]> wrote:
> Hi Pradeep,
>
> On Wed, Aug 30, 2023 at 3:27 PM Pradeep KNS via FreeIPA-users <
> [e-mail]> wrote:
> > Hi Rob,
> >
> > Thank you for your valuable insights on FreeIPA and DNS. I have an
>
> existing internal DNS server that I would like to integrate with FreeIPA's
> DNS feature. As I understand it, FreeIPA can serve as an integrated DNS
> solution. However, I would like to ensure that my existing internal DNS
> infrastructure is utilized alongside FreeIPA's DNS capabilities.
> > Could you provide guidance on how to configure FreeIPA to work with my
>
> internal DNS server? Specifically, I'd like to achieve the following:
> > Use FreeIPA for centralized user authentication and management.
>
> That would be just setting up FreeIPA and maintaining correct DNS records,
> so I won't jump into this one.
> > Integrate my existing internal DNS server with FreeIPA's DNS, so I can
>
> manage internal DNS records within FreeIPA while maintaining the internal
> DNS functionality.
> >
>
> Is a short answer: you can't.
>
> The longer answer might provide a way to almost have what you want.
>
> FreeIPA's embedded nameserver has to be authoritative, and you can only
> manage its records, not the ones on your current DNS infrastructure.
>
> To change DNS management to FreeIPA you'd have to set your internal DNS
> nameserver to be a secondary nameserver, and configure FreeIPA's
> nameserver to notify the internal nameserver of changes. It's doable, but I
> would not recommend doing so.
>
> Another possibility is to change DNS infrastructure to use FreeIPA instead
> of
> the current nameserver.
>
> If you can manage your internal zones with the limitations that FreeIPA's
> nameserver has (e.g. split-view is not supported), then you could plan on
> retiring the current nameserver in favor of the FreeIPA one. With replicas
> you
> can also get redundancy on the nameservers.
>
> If your current nameserver is exposed to the world, again, I'd suggest
> against
> this move.
>
> Bottom line, either use your current DNS infrastructure or fully migrate to
> FreeIPA.
>
> Rafael
> > I want to avoid any conflicts between FreeIPA's DNS and my existing
>
> internal DNS server. Your expertise in this matter would greatly assist me
> in achieving a successful and well-integrated DNS solution.
> > Thank you for your time and support.
> >
> > On Wed, Aug 30, 2023 at 6:34 PM Rob Crittenden
>
> wrote:
> > > Pradeep KNS via FreeIPA-users wrote:
> > > > Hello Team,
> > > >
> > > > While setting up Freeipa in my Linux infrastructure.I noticed a
>
> strange
> > > > warning. I would like to clarify before rolling into production.
> > > >
> > > > *|DNS zone alpha-grep.com http://alpha-grep.com. already exists in
>
> DNS
> > > > and is handled by server(s): ['ns2.', 'ns1.'] Please make sure that
>
> the
> > > > domain is properly delegated to this IPA server.|*
> > > >
> > > > Detailed installation log i have updated in this link. Please suggest
>
> me
> > > > will it be any security flaw in future.Before installing it on
>
> production.
> > > > https://bpa.st/AMITK
> > >
> > > I'm not sure what security issue you are worried about but you
> > > explicitly allow this configuration with the --allow-zone-overlap
> > > install option.
> > >
> > > Your domain DNS is managed externally and you've installed a DNS server
> > > to be authoritative for the same domain. If you want to expose you IPA
> > > DNS to the Internet you'll need to repoint the nameservers on your
> > > domain to your IPA host.
> > >
> > > If what you're hoping to do is provide views, to limit what hosts are
> > > resolvable depending on where the request is coming from, that is not
> > > available in IPA. While IPA uses bind under the hood not all
> > > capabilities are exposed.
> > >
> > > So whether this configuration is acceptable or not is up to you.
> > >
> > > rob
> >
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to
>
> [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it:
>
> https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Rafael Guterres Jeffman
> Senior Software Engineer
> FreeIPA - Red Hat
> _______________________________________________
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Pradeep KNS]

Thanks a lot,Will try it.

On Thu, Aug 31, 2023 at 10:40 AM Yavor Marinov  wrote:
> Hey guys,
>
> I would suggest an easier and quite simple method: create a subdomain in
> your current DNS, and describe its NSes to point to FreeIPA's DNSes.
> Configure FreeIPA with a subdomain, instead of the domain and if you need
> to create forwarding rules in FreeIPA to use your main DNS as a forwarder.
> Additionally newly added infra, can be just CNAME-ed into your main DNS
> with specifics (or even A record). Offering this, because in current infra
> we are using google's DNS for the domain, and our centralized login can be
> used with both of the domain and the subdomain. The only "frustrating"
> thing is that i need to change the client's DNS (eg resolv.conf) when I'm
> enrolling them, to point to FreeIPA and be able to properly enroll their
> DNS records into FreeIPA
>
> ~br
>
> On Wed, Aug 30, 2023 at 11:26 PM Rafael Jeffman via FreeIPA-users <
> [e-mail]> wrote:
> > Hi Pradeep,
> >
> > On Wed, Aug 30, 2023 at 3:27 PM Pradeep KNS via FreeIPA-users <
> > [e-mail]> wrote:
> > > Hi Rob,
> > >
> > > Thank you for your valuable insights on FreeIPA and DNS. I have an
> >
> > existing internal DNS server that I would like to integrate with FreeIPA's
> > DNS feature. As I understand it, FreeIPA can serve as an integrated DNS
> > solution. However, I would like to ensure that my existing internal DNS
> > infrastructure is utilized alongside FreeIPA's DNS capabilities.
> > > Could you provide guidance on how to configure FreeIPA to work with my
> >
> > internal DNS server? Specifically, I'd like to achieve the following:
> > > Use FreeIPA for centralized user authentication and management.
> >
> > That would be just setting up FreeIPA and maintaining correct DNS records,
> > so I won't jump into this one.
> > > Integrate my existing internal DNS server with FreeIPA's DNS, so I can
> >
> > manage internal DNS records within FreeIPA while maintaining the internal
> > DNS functionality.
> > >
> >
> > Is a short answer: you can't.
> >
> > The longer answer might provide a way to almost have what you want.
> >
> > FreeIPA's embedded nameserver has to be authoritative, and you can only
> > manage its records, not the ones on your current DNS infrastructure.
> >
> > To change DNS management to FreeIPA you'd have to set your internal DNS
> > nameserver to be a secondary nameserver, and configure FreeIPA's
> > nameserver to notify the internal nameserver of changes. It's doable, but
> > I
> > would not recommend doing so.
> >
> > Another possibility is to change DNS infrastructure to use FreeIPA
> > instead of
> > the current nameserver.
> >
> > If you can manage your internal zones with the limitations that FreeIPA's
> > nameserver has (e.g. split-view is not supported), then you could plan on
> > retiring the current nameserver in favor of the FreeIPA one. With
> > replicas you
> > can also get redundancy on the nameservers.
> >
> > If your current nameserver is exposed to the world, again, I'd suggest
> > against
> > this move.
> >
> > Bottom line, either use your current DNS infrastructure or fully migrate
> > to
> > FreeIPA.
> >
> > Rafael
> > > I want to avoid any conflicts between FreeIPA's DNS and my existing
> >
> > internal DNS server. Your expertise in this matter would greatly assist me
> > in achieving a successful and well-integrated DNS solution.
> > > Thank you for your time and support.
> > >
> > > On Wed, Aug 30, 2023 at 6:34 PM Rob Crittenden
> >
> > wrote:
> > > > Pradeep KNS via FreeIPA-users wrote:
> > > > > Hello Team,
> > > > >
> > > > > While setting up Freeipa in my Linux infrastructure.I noticed a
> >
> > strange
> > > > > warning. I would like to clarify before rolling into production.
> > > > >
> > > > > *|DNS zone alpha-grep.com http://alpha-grep.com. already exists
> >
> > in DNS
> > > > > and is handled by server(s): ['ns2.', 'ns1.'] Please make sure that
> >
> > the
> > > > > domain is properly delegated to this IPA server.|*
> > > > >
> > > > > Detailed installation log i have updated in this link. Please
> >
> > suggest me
> > > > > will it be any security flaw in future.Before installing it on
> >
> > production.
> > > > > https://bpa.st/AMITK
> > > >
> > > > I'm not sure what security issue you are worried about but you
> > > > explicitly allow this configuration with the --allow-zone-overlap
> > > > install option.
> > > >
> > > > Your domain DNS is managed externally and you've installed a DNS server
> > > > to be authoritative for the same domain. If you want to expose you IPA
> > > > DNS to the Internet you'll need to repoint the nameservers on your
> > > > domain to your IPA host.
> > > >
> > > > If what you're hoping to do is provide views, to limit what hosts are
> > > > resolvable depending on where the request is coming from, that is not
> > > > available in IPA. While IPA uses bind under the hood not all
> > > > capabilities are exposed.
> > > >
> > > > So whether this configuration is acceptable or not is up to you.
> > > >
> > > > rob
> > >
> > > FreeIPA-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
> >
> > [e-mail]
> > > 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/[e-mail]...
> > > Do not reply to spam, report it:
> >
> > https://pagure.io/fedora-infrastructure/new_issue
> >
> > --
> > Rafael Guterres Jeffman
> > Senior Software Engineer
> > FreeIPA - Red Hat
> > _______________________________________________
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to
> > [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue

[Pradeep KNS]

Hi,

I am able to configure Freeipa with internal DNS which is located on a
different server and added dns records under the dns zone file.
Now i have created a user and am able to communicate from Localhost to ipa
client both key based and password based both.

*Issue:*
Not able to ssh via from client A --> to Client B via key based
authentication its promoting for password.But if i use the hostname rather
than ip i am able to login.But most of the times i use ip only to
communicate.

Trick:
If add ssh-add <Keypath /rsa_pub> and then if cache with -A then able to
communicate with ip as well i can jump any client from local.But its a
trick it got worked but i would like to know where can i fix this to work
properly.Rather than doing this trick how can i jump from one client to
another without using password based authentication.Please let me know
where i need to change configuration to work smoothly.

_kerberos-master._tcp.test-local.com. 3600 IN SRV 0 100 88
ipa1-mum1.test-local.com.
_kerberos-master._udp.test-local.com. 3600 IN SRV 0 100 88
ipa1-mum1.test-local.com.
_kerberos._tcp.test-local.com. 3600 IN SRV 0 100 88 ipa1-mum1.test-local.com
.
_kerberos._udp.test-local.com. 3600 IN SRV 0 100 88 ipa1-mum1.test-local.com
.
_kerberos.test-local.com. 3600 IN TXT "ALPHA-GREP.COM"
_kerberos.test-local.com. 3600 IN URI 0 100 "krb5srv:m:tcp:
ipa1-mum1.test-local.com."
_kerberos.test-local.com. 3600 IN URI 0 100 "krb5srv:m:udp:
ipa1-mum1.test-local.com."
_kpasswd._tcp.test-local.com. 3600 IN SRV 0 100 464 ipa1-mum1.test-local.com
.
_kpasswd._udp.test-local.com. 3600 IN SRV 0 100 464 ipa1-mum1.test-local.com
.
_kpasswd.test-local.com. 3600 IN URI 0 100 "krb5srv:m:tcp:
ipa1-mum1.test-local.com."
_kpasswd.test-local.com. 3600 IN URI 0 100 "krb5srv:m:udp:
ipa1-mum1.test-local.com."
_ldap._tcp.test-local.com. 3600 IN SRV 0 100 389 ipa1-mum1.test-local.com.

On Fri, Sep 1, 2023 at 12:17 PM Pradeep KNS 
wrote:
> Thanks a lot,Will try it.
>
> On Thu, Aug 31, 2023 at 10:40 AM Yavor Marinov  wrote:
> > Hey guys,
> >
> > I would suggest an easier and quite simple method: create a subdomain in
> > your current DNS, and describe its NSes to point to FreeIPA's DNSes.
> > Configure FreeIPA with a subdomain, instead of the domain and if you need
> > to create forwarding rules in FreeIPA to use your main DNS as a forwarder.
> > Additionally newly added infra, can be just CNAME-ed into your main DNS
> > with specifics (or even A record). Offering this, because in current infra
> > we are using google's DNS for the domain, and our centralized login can be
> > used with both of the domain and the subdomain. The only "frustrating"
> > thing is that i need to change the client's DNS (eg resolv.conf) when I'm
> > enrolling them, to point to FreeIPA and be able to properly enroll their
> > DNS records into FreeIPA
> >
> > ~br
> >
> > On Wed, Aug 30, 2023 at 11:26 PM Rafael Jeffman via FreeIPA-users <
> > [e-mail]> wrote:
> > > Hi Pradeep,
> > >
> > > On Wed, Aug 30, 2023 at 3:27 PM Pradeep KNS via FreeIPA-users <
> > > [e-mail]> wrote:
> > > > Hi Rob,
> > > >
> > > > Thank you for your valuable insights on FreeIPA and DNS. I have an
> > >
> > > existing internal DNS server that I would like to integrate with FreeIPA's
> > > DNS feature. As I understand it, FreeIPA can serve as an integrated DNS
> > > solution. However, I would like to ensure that my existing internal DNS
> > > infrastructure is utilized alongside FreeIPA's DNS capabilities.
> > > > Could you provide guidance on how to configure FreeIPA to work with my
> > >
> > > internal DNS server? Specifically, I'd like to achieve the following:
> > > > Use FreeIPA for centralized user authentication and management.
> > >
> > > That would be just setting up FreeIPA and maintaining correct DNS
> > > records,
> > > so I won't jump into this one.
> > > > Integrate my existing internal DNS server with FreeIPA's DNS, so I can
> > >
> > > manage internal DNS records within FreeIPA while maintaining the internal
> > > DNS functionality.
> > > >
> > >
> > > Is a short answer: you can't.
> > >
> > > The longer answer might provide a way to almost have what you want.
> > >
> > > FreeIPA's embedded nameserver has to be authoritative, and you can only
> > > manage its records, not the ones on your current DNS infrastructure.
> > >
> > > To change DNS management to FreeIPA you'd have to set your internal DNS
> > > nameserver to be a secondary nameserver, and configure FreeIPA's
> > > nameserver to notify the internal nameserver of changes. It's doable,
> > > but I
> > > would not recommend doing so.
> > >
> > > Another possibility is to change DNS infrastructure to use FreeIPA
> > > instead of
> > > the current nameserver.
> > >
> > > If you can manage your internal zones with the limitations that FreeIPA's
> > > nameserver has (e.g. split-view is not supported), then you could plan on
> > > retiring the current nameserver in favor of the FreeIPA one. With
> > > replicas you
> > > can also get redundancy on the nameservers.
> > >
> > > If your current nameserver is exposed to the world, again, I'd suggest
> > > against
> > > this move.
> > >
> > > Bottom line, either use your current DNS infrastructure or fully migrate
> > > to
> > > FreeIPA.
> > >
> > > Rafael
> > > > I want to avoid any conflicts between FreeIPA's DNS and my existing
> > >
> > > internal DNS server. Your expertise in this matter would greatly assist me
> > > in achieving a successful and well-integrated DNS solution.
> > > > Thank you for your time and support.
> > > >
> > > > On Wed, Aug 30, 2023 at 6:34 PM Rob Crittenden
> > >
> > > wrote:
> > > > > Pradeep KNS via FreeIPA-users wrote:
> > > > > > Hello Team,
> > > > > >
> > > > > > While setting up Freeipa in my Linux infrastructure.I noticed a
> > >
> > > strange
> > > > > > warning. I would like to clarify before rolling into production.
> > > > > >
> > > > > > *|DNS zone alpha-grep.com http://alpha-grep.com. already exists
> > >
> > > in DNS
> > > > > > and is handled by server(s): ['ns2.', 'ns1.'] Please make sure that
> > >
> > > the
> > > > > > domain is properly delegated to this IPA server.|*
> > > > > >
> > > > > > Detailed installation log i have updated in this link. Please
> > >
> > > suggest me
> > > > > > will it be any security flaw in future.Before installing it on
> > >
> > > production.
> > > > > > https://bpa.st/AMITK
> > > > >
> > > > > I'm not sure what security issue you are worried about but you
> > > > > explicitly allow this configuration with the --allow-zone-overlap
> > > > > install option.
> > > > >
> > > > > Your domain DNS is managed externally and you've installed a DNS
> > >
> > > server
> > > > > to be authoritative for the same domain. If you want to expose you IPA
> > > > > DNS to the Internet you'll need to repoint the nameservers on your
> > > > > domain to your IPA host.
> > > > >
> > > > > If what you're hoping to do is provide views, to limit what hosts are
> > > > > resolvable depending on where the request is coming from, that is not
> > > > > available in IPA. While IPA uses bind under the hood not all
> > > > > capabilities are exposed.
> > > > >
> > > > > So whether this configuration is acceptable or not is up to you.
> > > > >
> > > > > rob
> > > >
> > > > FreeIPA-users mailing list -- [e-mail]
> > > > To unsubscribe send an email to
> > >
> > > [e-mail]
> > > > 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/[e-mail]...
> > > > Do not reply to spam, report it:
> > >
> > > https://pagure.io/fedora-infrastructure/new_issue
> > >
> > > --
> > > Rafael Guterres Jeffman
> > > Senior Software Engineer
> > > FreeIPA - Red Hat
> > > _______________________________________________
> > > FreeIPA-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
> > > [e-mail]
> > > 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/[e-mail]...
> > > Do not reply to spam, report it:
> > > https://pagure.io/fedora-infrastructure/new_issue

[Pradeep KNS]

Also ssh logs

[kns@ti-mum1-pve04 ~]$ ssh kns@10.40.1.201 -v
OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/04-ipa.conf
debug1: Executing command: 'true'
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data
/etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/04-ipa.conf
debug1: Executing command: 'true'
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data
/etc/crypto-policies/back-ends/openssh.config
debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p
22 10.40.1.201
debug1: identity file /home/kns/.ssh/id_rsa type -1
debug1: identity file /home/kns/.ssh/id_rsa-cert type -1
debug1: identity file /home/kns/.ssh/id_dsa type -1
debug1: identity file /home/kns/.ssh/id_dsa-cert type -1
debug1: identity file /home/kns/.ssh/id_ecdsa type -1
debug1: identity file /home/kns/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/kns/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/kns/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/kns/.ssh/id_ed25519 type -1
debug1: identity file /home/kns/.ssh/id_ed25519-cert type -1
debug1: identity file /home/kns/.ssh/id_ed25519_sk type -1
debug1: identity file /home/kns/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/kns/.ssh/id_xmss type -1
debug1: identity file /home/kns/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: compat_banner: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.40.1.201:22 as 'kns'
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: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [e-mail] MAC: <implicit>
compression: none
debug1: kex: client->server cipher: [e-mail] MAC: <implicit>
compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519
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
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,
[e-mail]
,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
[e-mail],
[e-mail]>
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
informationServer host/[e-mail]
 not found in Kerberos database*

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) Password:

####################################################################################3
[kns@ti-mum1-pve04 ~]$ ssh kns@ti-mum1-pve01 -v
OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/04-ipa.conf
debug1: Executing command: 'true'
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data
/etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/04-ipa.conf
debug1: Executing command: 'true'
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data
/etc/crypto-policies/back-ends/openssh.config
debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p
22 ti-mum1-pve01
debug1: identity file /home/kns/.ssh/id_rsa type -1
debug1: identity file /home/kns/.ssh/id_rsa-cert type -1
debug1: identity file /home/kns/.ssh/id_dsa type -1
debug1: identity file /home/kns/.ssh/id_dsa-cert type -1
debug1: identity file /home/kns/.ssh/id_ecdsa type -1
debug1: identity file /home/kns/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/kns/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/kns/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/kns/.ssh/id_ed25519 type -1
debug1: identity file /home/kns/.ssh/id_ed25519-cert type -1
debug1: identity file /home/kns/.ssh/id_ed25519_sk type -1
debug1: identity file /home/kns/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/kns/.ssh/id_xmss type -1
debug1: identity file /home/kns/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: compat_banner: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ti-mum1-pve01:22 as 'kns'
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: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [e-mail] MAC: <implicit>
compression: none
debug1: kex: client->server cipher: [e-mail] MAC: <implicit>
compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519
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 'ti-mum1-pve01' is known and matches the ED25519 host key.
debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
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,
[e-mail]
,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
[e-mail],
[e-mail]>
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
Authenticated to ti-mum1-pve01 (via proxy) using "gssapi-with-mic".
debug1: pkcs11_del_provider: called, provider_id = (null)
debug1: channel 0: new [client-session]
debug1: Requesting [e-mail]
debug1: Entering interactive session.
debug1: pledge: proc
debug1: client_input_global_request: rtype [e-mail]
want_reply 0
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_GB.UTF-8"
Register this system with Red Hat Insights: insights-client --register
Create an account or view all your systems at
https://red.ht/insights-dashboard
Last login: Tue Oct  3 01:59:36 2023 from 10.40.1.200
[kns@ti-mum1-pve01 ~]$

On Tue, Oct 3, 2023 at 1:19 AM Pradeep KNS 
wrote:
> Hi,
>
> I am able to configure Freeipa with internal DNS which is located on a
> different server and added dns records under the dns zone file.
> Now i have created a user and am able to communicate from Localhost to ipa
> client both key based and password based both.
>
> *Issue:*
> Not able to ssh via from client A --> to Client B via key based
> authentication its promoting for password.But if i use the hostname rather
> than ip i am able to login.But most of the times i use ip only to
> communicate.
>
> Trick:
> If add ssh-add <Keypath /rsa_pub> and then if cache with -A then able to
> communicate with ip as well i can jump any client from local.But its a
> trick it got worked but i would like to know where can i fix this to work
> properly.Rather than doing this trick how can i jump from one client to
> another without using password based authentication.Please let me know
> where i need to change configuration to work smoothly.
>
> _kerberos-master._tcp.test-local.com. 3600 IN SRV 0 100 88
> ipa1-mum1.test-local.com.
> _kerberos-master._udp.test-local.com. 3600 IN SRV 0 100 88
> ipa1-mum1.test-local.com.
> _kerberos._tcp.test-local.com. 3600 IN SRV 0 100 88
> ipa1-mum1.test-local.com.
> _kerberos._udp.test-local.com. 3600 IN SRV 0 100 88
> ipa1-mum1.test-local.com.
> _kerberos.test-local.com. 3600 IN TXT "ALPHA-GREP.COM"
> _kerberos.test-local.com. 3600 IN URI 0 100 "krb5srv:m:tcp:
> ipa1-mum1.test-local.com."
> _kerberos.test-local.com. 3600 IN URI 0 100 "krb5srv:m:udp:
> ipa1-mum1.test-local.com."
> _kpasswd._tcp.test-local.com. 3600 IN SRV 0 100 464
> ipa1-mum1.test-local.com.
> _kpasswd._udp.test-local.com. 3600 IN SRV 0 100 464
> ipa1-mum1.test-local.com.
> _kpasswd.test-local.com. 3600 IN URI 0 100 "krb5srv:m:tcp:
> ipa1-mum1.test-local.com."
> _kpasswd.test-local.com. 3600 IN URI 0 100 "krb5srv:m:udp:
> ipa1-mum1.test-local.com."
> _ldap._tcp.test-local.com. 3600 IN SRV 0 100 389 ipa1-mum1.test-local.com.
>
> On Fri, Sep 1, 2023 at 12:17 PM Pradeep KNS 
> wrote:
> > Thanks a lot,Will try it.
> >
> > On Thu, Aug 31, 2023 at 10:40 AM Yavor Marinov 
> > wrote:
> > > Hey guys,
> > >
> > > I would suggest an easier and quite simple method: create a subdomain in
> > > your current DNS, and describe its NSes to point to FreeIPA's DNSes.
> > > Configure FreeIPA with a subdomain, instead of the domain and if you need
> > > to create forwarding rules in FreeIPA to use your main DNS as a forwarder.
> > > Additionally newly added infra, can be just CNAME-ed into your main DNS
> > > with specifics (or even A record). Offering this, because in current infra
> > > we are using google's DNS for the domain, and our centralized login can be
> > > used with both of the domain and the subdomain. The only "frustrating"
> > > thing is that i need to change the client's DNS (eg resolv.conf) when I'm
> > > enrolling them, to point to FreeIPA and be able to properly enroll their
> > > DNS records into FreeIPA
> > >
> > > ~br
> > >
> > > On Wed, Aug 30, 2023 at 11:26 PM Rafael Jeffman via FreeIPA-users <
> > > [e-mail]> wrote:
> > > > Hi Pradeep,
> > > >
> > > > On Wed, Aug 30, 2023 at 3:27 PM Pradeep KNS via FreeIPA-users <
> > > > [e-mail]> wrote:
> > > > > Hi Rob,
> > > > >
> > > > > Thank you for your valuable insights on FreeIPA and DNS. I have an
> > > >
> > > > existing internal DNS server that I would like to integrate with FreeIPA's
> > > > DNS feature. As I understand it, FreeIPA can serve as an integrated DNS
> > > > solution. However, I would like to ensure that my existing internal DNS
> > > > infrastructure is utilized alongside FreeIPA's DNS capabilities.
> > > > > Could you provide guidance on how to configure FreeIPA to work with
> > > >
> > > > my internal DNS server? Specifically, I'd like to achieve the following:
> > > > > Use FreeIPA for centralized user authentication and management.
> > > >
> > > > That would be just setting up FreeIPA and maintaining correct DNS
> > > > records,
> > > > so I won't jump into this one.
> > > > > Integrate my existing internal DNS server with FreeIPA's DNS, so I
> > > >
> > > > can manage internal DNS records within FreeIPA while maintaining the
> > > > internal DNS functionality.
> > > > >
> > > >
> > > > Is a short answer: you can't.
> > > >
> > > > The longer answer might provide a way to almost have what you want.
> > > >
> > > > FreeIPA's embedded nameserver has to be authoritative, and you can only
> > > > manage its records, not the ones on your current DNS infrastructure.
> > > >
> > > > To change DNS management to FreeIPA you'd have to set your internal DNS
> > > > nameserver to be a secondary nameserver, and configure FreeIPA's
> > > > nameserver to notify the internal nameserver of changes. It's doable,
> > > > but I
> > > > would not recommend doing so.
> > > >
> > > > Another possibility is to change DNS infrastructure to use FreeIPA
> > > > instead of
> > > > the current nameserver.
> > > >
> > > > If you can manage your internal zones with the limitations that
> > > > FreeIPA's
> > > > nameserver has (e.g. split-view is not supported), then you could plan
> > > > on
> > > > retiring the current nameserver in favor of the FreeIPA one. With
> > > > replicas you
> > > > can also get redundancy on the nameservers.
> > > >
> > > > If your current nameserver is exposed to the world, again, I'd suggest
> > > > against
> > > > this move.
> > > >
> > > > Bottom line, either use your current DNS infrastructure or fully
> > > > migrate to
> > > > FreeIPA.
> > > >
> > > > Rafael
> > > > > I want to avoid any conflicts between FreeIPA's DNS and my existing
> > > >
> > > > internal DNS server. Your expertise in this matter would greatly assist me
> > > > in achieving a successful and well-integrated DNS solution.
> > > > > Thank you for your time and support.
> > > > >
> > > > > On Wed, Aug 30, 2023 at 6:34 PM Rob Crittenden
> > > >
> > > > wrote:
> > > > > > Pradeep KNS via FreeIPA-users wrote:
> > > > > > > Hello Team,
> > > > > > >
> > > > > > > While setting up Freeipa in my Linux infrastructure.I noticed a
> > > >
> > > > strange
> > > > > > > warning. I would like to clarify before rolling into production.
> > > > > > > *
> > > > > > > *
> > > > > > > *|DNS zone alpha-grep.com http://alpha-grep.com. already exists
> > > >
> > > > in DNS
> > > > > > > and is handled by server(s): ['ns2.', 'ns1.'] Please make sure
> > > >
> > > > that the
> > > > > > > domain is properly delegated to this IPA server.|*
> > > > > > >
> > > > > > > Detailed installation log i have updated in this link. Please
> > > >
> > > > suggest me
> > > > > > > will it be any security flaw in future.Before installing it on
> > > >
> > > > production.
> > > > > > >
> > > > > > > https://bpa.st/AMITK
> > > > > >
> > > > > > I'm not sure what security issue you are worried about but you
> > > > > > explicitly allow this configuration with the --allow-zone-overlap
> > > > > > install option.
> > > > > >
> > > > > > Your domain DNS is managed externally and you've installed a DNS
> > > >
> > > > server
> > > > > > to be authoritative for the same domain. If you want to expose you
> > > >
> > > > IPA
> > > > > > DNS to the Internet you'll need to repoint the nameservers on your
> > > > > > domain to your IPA host.
> > > > > >
> > > > > > If what you're hoping to do is provide views, to limit what hosts are
> > > > > > resolvable depending on where the request is coming from, that is not
> > > > > > available in IPA. While IPA uses bind under the hood not all
> > > > > > capabilities are exposed.
> > > > > >
> > > > > > So whether this configuration is acceptable or not is up to you.
> > > > > >
> > > > > > rob
> > > > >
> > > > > FreeIPA-users mailing list -- [e-mail]
> > > > > To unsubscribe send an email to
> > > >
> > > > [e-mail]
> > > > > 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/[e-mail]...
> > > > > Do not reply to spam, report it:
> > > >
> > > > https://pagure.io/fedora-infrastructure/new_issue
> > > >
> > > > --
> > > > Rafael Guterres Jeffman
> > > > Senior Software Engineer
> > > > FreeIPA - Red Hat
> > > > _______________________________________________
> > > > FreeIPA-users mailing list -- [e-mail]
> > > > To unsubscribe send an email to
> > > > [e-mail]
> > > > 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/[e-mail]...
> > > > Do not reply to spam, report it:
> > > > https://pagure.io/fedora-infrastructure/new_issue

[Rob Crittenden]

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,[e-mail]
> ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[e-mail]
> ,[e-mail]
> >
> 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/[e-mail]
>  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 ) Password:

It failed to do a Kerberos/GSSAPI auth so it fell back to password.

rob

[Pradeep KNS]

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

On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden  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,[e-mail]
> > <mailto:[e-mail]
> > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
>
> [e-mail]
> > ,
>
> [e-mail]
> > >
> > 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/[e-mail]
> >  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 ) Password:
>
> It failed to do a Kerberos/GSSAPI auth so it fell back to password.
>
> rob

[Alexander Bokovoy]

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/[e-mail], host/[e-mail]
> On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden  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,[e-mail]
> > > <mailto:[e-mail]
> > > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> >
> > [e-mail]
> > > ,
> >
> > [e-mail]
> > > >
> > > 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/[e-mail]
> > >  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 ) Password:
> >
> > It failed to do a Kerberos/GSSAPI auth so it fell back to password.
> >
> > rob

[Pradeep KNS]

Awesome, thanks for the info!

On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
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/[e-mail],
> host/[e-mail]
> > On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden
>
> 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,[e-mail]
> > > > <mailto:[e-mail]
> >
> > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> > > [e-mail]
> > > > ,
> > >
> > > [e-mail]
> > > > >
> > > > 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/[e-mail]
> > > >  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 ) 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

[Pradeep KNS]

Hi Alexander,

Thanks for your email,
Like this i need to add all servers? As my dns is located in internal
different server.

Also if i want to jump from one server to another server on ipa clients
using sshkeybased? How this mechanism works? here

On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS 
wrote:
> Awesome, thanks for the info!
>
> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
> 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/[e-mail],
> > host/[e-mail]
> > > On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden
> >
> > 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,[e-mail]
> > > > > <mailto:[e-mail]
> > >
> > > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> > > > [e-mail]
> > > > > ,
> > > >
> > > > [e-mail]
> > > > > >
> > > > > 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/[e-mail]
> > > > >  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 ) 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]

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/htm...
> On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS 
> wrote:
> > Awesome, thanks for the info!
> >
> > On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
> > 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/[e-mail],
> > > host/[e-mail]
> > > > On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden
> > >
> > > 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,[e-mail]
> > > > > > <mailto:[e-mail]
> > > >
> > > > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> > > > > [e-mail]
> > > > > > ,
> > > > >
> > > > > [e-mail]
> > > > > > >
> > > > > > 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/[e-mail]
> > > > > >  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 ) 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

[Pradeep KNS]

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 
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/htm...
> > On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS 
> > wrote:
> > > Awesome, thanks for the info!
> > >
> > > On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
> > > 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/[e-mail],
> > > > host/[e-mail]
> > > > > On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden
> > > >
> > > > 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,[e-mail]
> > > > > > > <mailto:[e-mail]
> >
> > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> > > > > > [e-mail]
> > > > > > > ,
> > > > > > [e-mail]
> > > > > > > >
> > > > > > > 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/[e-mail]
> > > > > > >  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 ) 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]

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 
> 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/htm...
> > > On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS 
> > > wrote:
> > > > Awesome, thanks for the info!
> > > >
> > > > On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy 
> > > > 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/[e-mail],
> > > > > host/[e-mail]
> > > > > > On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden
> > > > >
> > > > > 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,[e-mail]
> > > > > > > >
> > >
> > > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> > > > > > > [e-mail]
> > > > > > > > ,
> > > > > > > [e-mail]
> > > > > > > > >
> > > > > > > > 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/[e-mail]
> > > > > > > >  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 ) 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

[Pradeep KNS]

Thanks Alexander,Thanks for the info

On Tue, 3 Oct 2023 at 2:21 PM, Alexander Bokovoy 
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 
> > 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/htm...
> > > > On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS <[e-mail]
> > > > wrote:
> > > > > Awesome, thanks for the info!
> > > > >
> > > > > On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy <
>
> [e-mail]>
> > > > > 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/[e-mail],
> > > > > > host/[e-mail]
> > > > > >
> > > > > > >
> > > > > > >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden <[e-mail]
> > > > > > 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,[e-mail]
> > > > > > >> > >
> >
> > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> > > > > > >> [e-mail]
> > > > > > >> > ,
> > > > > > >> [e-mail]
> > > > > > >> > >
> > > > > > >> > 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/[e-mail]
> > > > > > >> >  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 ) 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

[Pradeep KNS]

Hi,

Thanks for the links Alexander,I tried to setup as per the documents it is
working without any issues.

Problem:
I tried to bring the ipa server down and I am still able to communicate
with ssh-key mechanism.How it is possible and how it is allowing me to
communicate.Ideally when the ipa server is down! it shouldn't connect. as
all my public keys are located on ipa server.
Is there any way to fix this issue?

###################
─pradeep@sys-blr1-dsk04 ~
╰─$ ping 10.40.1.67
PING 10.40.1.67 (10.40.1.67) 56(84) bytes of data.
^C
--- 10.40.1.67 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2033ms

####################
─pradeep@sys-blr1-dsk04 ~
╰─$ ssh kns@10.40.1.200 -vv

1 ↵
OpenSSH_8.9p1 Ubuntu-3ubuntu0.3, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/my.conf
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 10.40.1.200 is address
debug1: Connecting to 10.40.1.200 [10.40.1.200] port 22.
debug1: Connection established.
debug1: identity file /home/pradeep/.ssh/id_rsa type 0
debug1: identity file /home/pradeep/.ssh/id_rsa-cert type -1
debug1: identity file /home/pradeep/.ssh/id_ecdsa type -1
debug1: identity file /home/pradeep/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pradeep/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/pradeep/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/pradeep/.ssh/id_ed25519 type -1
debug1: identity file /home/pradeep/.ssh/id_ed25519-cert type -1
debug1: identity file /home/pradeep/.ssh/id_ed25519_sk type -1
debug1: identity file /home/pradeep/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/pradeep/.ssh/id_xmss type -1
debug1: identity file /home/pradeep/.ssh/id_xmss-cert type -1
debug1: identity file /home/pradeep/.ssh/id_dsa type -1
debug1: identity file /home/pradeep/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: compat_banner: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.40.1.200:22 as 'kns'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[e-mail]
,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
[e-mail]
,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: [e-mail]
,aes128-ctr,aes192-ctr,aes256-ctr,[e-mail],
[e-mail]
debug2: ciphers stoc: [e-mail]
,aes128-ctr,aes192-ctr,aes256-ctr,[e-mail],
[e-mail]
debug2: MACs ctos: [e-mail],[e-mail],
[e-mail],[e-mail],
[e-mail],[e-mail],[e-mail]
,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [e-mail],[e-mail],
[e-mail],[e-mail],
[e-mail],[e-mail],[e-mail]
,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[e-mail],zlib
debug2: compression stoc: none,[e-mail],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[e-mail]
,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
debug2: host key algorithms:
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [e-mail],[e-mail]
,aes256-ctr,[e-mail],aes128-ctr
debug2: ciphers stoc: [e-mail],[e-mail]
,aes256-ctr,[e-mail],aes128-ctr
debug2: MACs ctos: [e-mail],[e-mail],
[e-mail],[e-mail]
,hmac-sha2-256,hmac-sha1,[e-mail],hmac-sha2-512
debug2: MACs stoc: [e-mail],[e-mail],
[e-mail],[e-mail]
,hmac-sha2-256,hmac-sha1,[e-mail],hmac-sha2-512
debug2: compression ctos: none,[e-mail]
debug2: compression stoc: none,[e-mail]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: [e-mail] MAC:
<implicit> compression: none
debug1: kex: client->server cipher: [e-mail] MAC:
<implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa
SHA256:wWKt87w2Wzv40Bhcbp533kOCLCJFXeogYcqycugoHSM
debug1: load_hostkeys: fopen /home/pradeep/.ssh/known_hosts2: No such file
or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or
directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or
directory
debug1: Host '10.40.1.200' is known and matches the RSA host key.
debug1: Found key in /home/pradeep/.ssh/known_hosts:5
debug2: ssh_set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: ssh_set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /home/pradeep/.ssh/id_rsa RSA
SHA256:o1zUnwlDUPSy/1/aPXOqFRt+DLKQaCw5BehTjDhNVGU agent
debug1: Will attempt key: /home/pradeep/.ssh/id_ecdsa
debug1: Will attempt key: /home/pradeep/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/pradeep/.ssh/id_ed25519
debug1: Will attempt key: /home/pradeep/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/pradeep/.ssh/id_xmss
debug1: Will attempt key: /home/pradeep/.ssh/id_dsa
debug2: pubkey_prepare: done
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,
[e-mail]
,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
[e-mail],
[e-mail]>
debug2: service_accept: ssh-userauth
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: No credentials were supplied, or the credentials were unavailable
or inaccessible
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1001)

debug1: No credentials were supplied, or the credentials were unavailable
or inaccessible
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1001)

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Offering public key: /home/pradeep/.ssh/id_rsa RSA
SHA256:o1zUnwlDUPSy/1/aPXOqFRt+DLKQaCw5BehTjDhNVGU agent
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: /home/pradeep/.ssh/id_rsa RSA
SHA256:o1zUnwlDUPSy/1/aPXOqFRt+DLKQaCw5BehTjDhNVGU agent
Authenticated to 10.40.1.200 ([10.40.1.200]:22) using "publickey".
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [e-mail]
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: client_input_global_request: rtype [e-mail]
want_reply 0
debug1: client_input_hostkeys: searching /home/pradeep/.ssh/known_hosts for
10.40.1.200 / (none)
debug1: client_input_hostkeys: searching /home/pradeep/.ssh/known_hosts2
for 10.40.1.200 / (none)
debug1: client_input_hostkeys: hostkeys file
/home/pradeep/.ssh/known_hosts2 does not exist
debug1: client_input_hostkeys: no new or deprecated keys from server
debug1: Remote: /usr/bin/sss_ssh_authorizedkeys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /usr/bin/sss_ssh_authorizedkeys:1: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_IN"
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Register this system with Red Hat Insights: insights-client --register
Create an account or view all your systems at
https://red.ht/insights-dashboard
Last login: Wed Oct 11 17:37:13 2023 from 10.80.101.53
[kns@ts-mum1-pve01 ~]$ ^C
[kns@ts-mum1-pve01 ~]$

On Tue, Oct 3, 2023 at 2:33 PM Pradeep KNS 
wrote:
> Thanks Alexander,Thanks for the info
>
> On Tue, 3 Oct 2023 at 2:21 PM, Alexander Bokovoy 
> 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 
> > > 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/htm...
> > > > > On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS <
> >
> > [e-mail]>
> > > > > wrote:
> > > > > > Awesome, thanks for the info!
> > > > > >
> > > > > > On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy <
> >
> > [e-mail]>
> > > > > > 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/[e-mail],
> > > > > > > host/[e-mail]
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden <
> >
> > [e-mail]>
> > > > > > > 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,[e-mail]
> > > > > > > >> >  >>
> > > > > > >
> > >
> > > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> > > > > > > >> [e-mail]
> > > > > > > >> > ,
> > > > > > > >> [e-mail]
> > > > > > > >> > >
> > > > > > > >> > 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/[e-mail]
> > > > > > > >> >  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 ) 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

[Pradeep KNS]

Hey,

Do we have any docs regarding this?

Also where to set tuning settings like suppose if i want to make any
changes on ipa server how frequently it will apply the changes to clients?

Coz once i remove the users public key first its allowing him into ssh
server first and second attempt he is not able to ssh later i did sss_cache
-E option fixed it though.

Second issue i faced even if ipa server is down still i am able to
communicate via ssh keys.
I want to know how its communicating and how long it wjll allow us to ssh.

On Wed, 11 Oct 2023 at 5:45 PM, Pradeep KNS 
wrote:
> Hi,
>
> Thanks for the links Alexander,I tried to setup as per the documents it is
> working without any issues.
>
> Problem:
> I tried to bring the ipa server down and I am still able to communicate
> with ssh-key mechanism.How it is possible and how it is allowing me to
> communicate.Ideally when the ipa server is down! it shouldn't connect. as
> all my public keys are located on ipa server.
> Is there any way to fix this issue?
>
> ###################
> ─pradeep@sys-blr1-dsk04 ~
> ╰─$ ping 10.40.1.67
> PING 10.40.1.67 (10.40.1.67) 56(84) bytes of data.
> ^C
> --- 10.40.1.67 ping statistics ---
> 3 packets transmitted, 0 received, 100% packet loss, time 2033ms
>
> ####################
> ─pradeep@sys-blr1-dsk04 ~
> ╰─$ ssh kns@10.40.1.200 -vv
>                                                                    1 ↵
>
> OpenSSH_8.9p1 Ubuntu-3ubuntu0.3, OpenSSL 3.0.2 15 Mar 2022
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Reading configuration data /etc/ssh/ssh_config.d/my.conf
> debug1: /etc/ssh/ssh_config line 21: Applying options for *
> debug2: resolve_canonicalize: hostname 10.40.1.200 is address
> debug1: Connecting to 10.40.1.200 [10.40.1.200] port 22.
> debug1: Connection established.
> debug1: identity file /home/pradeep/.ssh/id_rsa type 0
> debug1: identity file /home/pradeep/.ssh/id_rsa-cert type -1
> debug1: identity file /home/pradeep/.ssh/id_ecdsa type -1
> debug1: identity file /home/pradeep/.ssh/id_ecdsa-cert type -1
> debug1: identity file /home/pradeep/.ssh/id_ecdsa_sk type -1
> debug1: identity file /home/pradeep/.ssh/id_ecdsa_sk-cert type -1
> debug1: identity file /home/pradeep/.ssh/id_ed25519 type -1
> debug1: identity file /home/pradeep/.ssh/id_ed25519-cert type -1
> debug1: identity file /home/pradeep/.ssh/id_ed25519_sk type -1
> debug1: identity file /home/pradeep/.ssh/id_ed25519_sk-cert type -1
> debug1: identity file /home/pradeep/.ssh/id_xmss type -1
> debug1: identity file /home/pradeep/.ssh/id_xmss-cert type -1
> debug1: identity file /home/pradeep/.ssh/id_dsa type -1
> debug1: identity file /home/pradeep/.ssh/id_dsa-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.3
> debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
> debug1: compat_banner: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000
> debug2: fd 3 setting O_NONBLOCK
> debug1: Authenticating to 10.40.1.200:22 as 'kns'
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: local client KEXINIT proposal
> debug2: KEX algorithms: curve25519-sha256,[e-mail]
> ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
> [e-mail]
> ,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
> debug2: host key algorithms: ssh-rsa
> debug2: ciphers ctos: [e-mail]
> ,aes128-ctr,aes192-ctr,aes256-ctr,[e-mail],
> [e-mail]
> debug2: ciphers stoc: [e-mail]
> ,aes128-ctr,aes192-ctr,aes256-ctr,[e-mail],
> [e-mail]
> debug2: MACs ctos: [e-mail],[e-mail],
> [e-mail],[e-mail],
> [e-mail],[e-mail],[e-mail]
> ,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> debug2: MACs stoc: [e-mail],[e-mail],
> [e-mail],[e-mail],
> [e-mail],[e-mail],[e-mail]
> ,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> debug2: compression ctos: none,[e-mail],zlib
> debug2: compression stoc: none,[e-mail],zlib
> debug2: languages ctos:
> debug2: languages stoc:
> debug2: first_kex_follows 0
> debug2: reserved 0
> debug2: peer server KEXINIT proposal
> debug2: KEX algorithms: curve25519-sha256,[e-mail]
> ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
> debug2: host key algorithms:
> rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
> debug2: ciphers ctos: [e-mail],[e-mail]
> ,aes256-ctr,[e-mail],aes128-ctr
> debug2: ciphers stoc: [e-mail],[e-mail]
> ,aes256-ctr,[e-mail],aes128-ctr
> debug2: MACs ctos: [e-mail],[e-mail]
> ,[e-mail],[e-mail]
> ,hmac-sha2-256,hmac-sha1,[e-mail],hmac-sha2-512
> debug2: MACs stoc: [e-mail],[e-mail]
> ,[e-mail],[e-mail]
> ,hmac-sha2-256,hmac-sha1,[e-mail],hmac-sha2-512
> debug2: compression ctos: none,[e-mail]
> debug2: compression stoc: none,[e-mail]
> debug2: languages ctos:
> debug2: languages stoc:
> debug2: first_kex_follows 0
> debug2: reserved 0
> debug1: kex: algorithm: curve25519-sha256
> debug1: kex: host key algorithm: ssh-rsa
> debug1: kex: server->client cipher: [e-mail] MAC:
> <implicit> compression: none
> debug1: kex: client->server cipher: [e-mail] MAC:
> <implicit> compression: none
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: SSH2_MSG_KEX_ECDH_REPLY received
> debug1: Server host key: ssh-rsa
> SHA256:wWKt87w2Wzv40Bhcbp533kOCLCJFXeogYcqycugoHSM
> debug1: load_hostkeys: fopen /home/pradeep/.ssh/known_hosts2: No such file
> or directory
> debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or
> directory
> debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or
> directory
> debug1: Host '10.40.1.200' is known and matches the RSA host key.
> debug1: Found key in /home/pradeep/.ssh/known_hosts:5
> debug2: ssh_set_newkeys: mode 1
> debug1: rekey out after 134217728 blocks
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug2: ssh_set_newkeys: mode 0
> debug1: rekey in after 134217728 blocks
> debug1: get_agent_identities: bound agent to hostkey
> debug1: get_agent_identities: agent returned 1 keys
> debug1: Will attempt key: /home/pradeep/.ssh/id_rsa RSA
> SHA256:o1zUnwlDUPSy/1/aPXOqFRt+DLKQaCw5BehTjDhNVGU agent
> debug1: Will attempt key: /home/pradeep/.ssh/id_ecdsa
> debug1: Will attempt key: /home/pradeep/.ssh/id_ecdsa_sk
> debug1: Will attempt key: /home/pradeep/.ssh/id_ed25519
> debug1: Will attempt key: /home/pradeep/.ssh/id_ed25519_sk
> debug1: Will attempt key: /home/pradeep/.ssh/id_xmss
> debug1: Will attempt key: /home/pradeep/.ssh/id_dsa
> debug2: pubkey_prepare: done
> debug1: SSH2_MSG_EXT_INFO received
> debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,
> [e-mail]
> ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> [e-mail],
> [e-mail]>
> debug2: service_accept: ssh-userauth
> 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: No credentials were supplied, or the credentials were unavailable
> or inaccessible
> No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1001)
>
> debug1: No credentials were supplied, or the credentials were unavailable
> or inaccessible
> No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1001)
>
> debug2: we did not send a packet, disable method
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/pradeep/.ssh/id_rsa RSA
> SHA256:o1zUnwlDUPSy/1/aPXOqFRt+DLKQaCw5BehTjDhNVGU agent
> debug2: we sent a publickey packet, wait for reply
> debug1: Server accepts key: /home/pradeep/.ssh/id_rsa RSA
> SHA256:o1zUnwlDUPSy/1/aPXOqFRt+DLKQaCw5BehTjDhNVGU agent
> Authenticated to 10.40.1.200 ([10.40.1.200]:22) using "publickey".
> debug1: channel 0: new [client-session]
> debug2: channel 0: send open
> debug1: Requesting [e-mail]
> debug1: Entering interactive session.
> debug1: pledge: filesystem
> debug1: client_input_global_request: rtype [e-mail]
> want_reply 0
> debug1: client_input_hostkeys: searching /home/pradeep/.ssh/known_hosts
> for 10.40.1.200 / (none)
> debug1: client_input_hostkeys: searching /home/pradeep/.ssh/known_hosts2
> for 10.40.1.200 / (none)
> debug1: client_input_hostkeys: hostkeys file
> /home/pradeep/.ssh/known_hosts2 does not exist
> debug1: client_input_hostkeys: no new or deprecated keys from server
> debug1: Remote: /usr/bin/sss_ssh_authorizedkeys:1: key options:
> agent-forwarding port-forwarding pty user-rc x11-forwarding
> debug1: Remote: /usr/bin/sss_ssh_authorizedkeys:1: key options:
> agent-forwarding port-forwarding pty user-rc x11-forwarding
> debug2: channel_input_open_confirmation: channel 0: callback start
> debug2: fd 3 setting TCP_NODELAY
> debug2: client_session2_setup: id 0
> debug2: channel 0: request pty-req confirm 1
> debug1: Sending environment.
> debug1: channel 0: setting env LANG = "en_IN"
> debug2: channel 0: request env confirm 0
> debug2: channel 0: request shell confirm 1
> debug2: channel_input_open_confirmation: channel 0: callback done
> debug2: channel 0: open confirm rwindow 0 rmax 32768
> debug2: channel_input_status_confirm: type 99 id 0
> debug2: PTY allocation request accepted on channel 0
> debug2: channel 0: rcvd adjust 2097152
> debug2: channel_input_status_confirm: type 99 id 0
> debug2: shell request accepted on channel 0
> Register this system with Red Hat Insights: insights-client --register
> Create an account or view all your systems at
> https://red.ht/insights-dashboard
> Last login: Wed Oct 11 17:37:13 2023 from 10.80.101.53
> [kns@ts-mum1-pve01 ~]$ ^C
> [kns@ts-mum1-pve01 ~]$
>
> On Tue, Oct 3, 2023 at 2:33 PM Pradeep KNS 
> wrote:
> > Thanks Alexander,Thanks for the info
> >
> > On Tue, 3 Oct 2023 at 2:21 PM, Alexander Bokovoy 
> > 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 
> > > > 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/htm...
> > > > > > On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS <
> > >
> > > [e-mail]>
> > > > > > wrote:
> > > > > >
> > > > > > > Awesome, thanks for the info!
> > > > > > >
> > > > > > > On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy <
> > >
> > > [e-mail]>
> > > > > > > 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/[e-mail],
> > > > > > >> host/[e-mail]
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> >
> > > > > > >> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden <
> > >
> > > [e-mail]>
> > > > > > >> 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,[e-mail]
> > > > > > >> >> > > >>
> > > > > > >>
> > > >
> > > > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> > > > > > >> >> [e-mail]
> > > > > > >> >> > ,
> > > > > > >> >> [e-mail]
> > > > > > >> >> > >
> > > > > > >> >> > 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/[e-mail]
> > > > > > >> >> >  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 ) 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