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 <kns.pradeep@alpha-grep.com> 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,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,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: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,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,curve25519-sha256@libssh.org,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: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
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: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com 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,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: client_input_global_request: rtype hostkeys-00@openssh.com 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 <kns.pradeep@alpha-grep.com> wrote:
Thanks Alexander,Thanks for the info 

On Tue, 3 Oct 2023 at 2:21 PM, Alexander Bokovoy <abokovoy@redhat.com> 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 <abokovoy@redhat.com>
>wrote:
>
>> On Аўт, 03 кас 2023, Pradeep KNS wrote:
>> >Hi Alexander,
>> >
>> >Thanks for your email,
>> >Like this i need to add all servers? As my dns is located in internal
>> >different server.
>>
>> Only if you need to use Kerberos authentication.
>>
>> >
>> >Also if i want to jump from one server to another server on ipa clients
>> >using sshkeybased? How this mechanism works? here
>>
>> If you are using SSH keypairs, you are not using Kerberos and thus don't
>> need these aliases at all.
>>
>> If you want to use SSH keypair to authenticate, then upload public SSH
>> key for that user to IPA.
>>
>> In general, almost all these details covered in the RHEL IdM
>> documentation:
>>
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/managing-public-ssh-keys_managing-users-groups-hosts
>>
>> >
>> >
>> >
>> >
>> >On Tue, 3 Oct 2023 at 1:45 PM, Pradeep KNS <kns.pradeep@alpha-grep.com>
>> >wrote:
>> >
>> >> Awesome, thanks for the info!
>> >>
>> >> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy <abokovoy@redhat.com>
>> >> wrote:
>> >>
>> >>> On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote:
>> >>> >Hi Rob,
>> >>> >
>> >>> >Thanks for your email,
>> >>> >
>> >>> >Yeah true FQDN is working without any issues.But is there any way to
>> ssh
>> >>> >via IP as well rather than hostname
>> >>>
>> >>> Kerberos authentication is based on names of services known to your
>> KDC.
>> >>> IP address is not a name in this context and is not associated with the
>> >>> service host/$FQDN, hence it is not found in the Kerberos database.
>> >>>
>> >>> You can add such service name alias using 'ipa host-add-principal'
>> >>> command. It is, however, not always enough because most Kerberos
>> >>> services do not expect to operate with multiple aliases. Luckily, SSH
>> >>> works fine with such tickets in IPA environment.
>> >>>
>> >>> $ ipa host-add-principal server.ipa.example host/10.40.1.201
>> >>> ---------------------------------------
>> >>> Added new aliases to host "server.ipa.example"
>> >>> ---------------------------------------
>> >>>    Host name: server.ipa.example
>> >>>    Principal alias: host/server.ipa.example@IPA.EXAMPLE,
>> >>> host/10.40.1.201@IPA.EXAMPLE
>> >>>
>> >>>
>> >>>
>> >>> >
>> >>> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden <rcritten@redhat.com>
>> >>> wrote:
>> >>> >
>> >>> >> Pradeep KNS wrote:
>> >>> >> > ssh kns@10.40.1.201 -v
>> >>> >>
>> >>> >> [snip]
>> >>> >>
>> >>> >> > SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU
>> >>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No such
>> >>> file or
>> >>> >> > directory
>> >>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No such
>> >>> file
>> >>> >> > or directory
>> >>> >> > debug1: Host '10.40.1.201' is known and matches the ED25519 host
>> key.
>> >>> >> > debug1: Found key in /var/lib/sss/pubconf/known_hosts:2
>> >>> >>
>> >>> >> The SSSD ssh integration was used to to validate that the host's SSH
>> >>> key
>> >>> >> matched what was received so you avoided the "do you trust this
>> host"
>> >>> >> prompt. So that's good.
>> >>> >>
>> >>> >> > debug1: rekey out after 4294967296 blocks
>> >>> >> > debug1: SSH2_MSG_NEWKEYS sent
>> >>> >> > debug1: expecting SSH2_MSG_NEWKEYS
>> >>> >> > debug1: SSH2_MSG_NEWKEYS received
>> >>> >> > debug1: rekey in after 4294967296 blocks
>> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_rsa
>> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_dsa
>> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa
>> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk
>> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519
>> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk
>> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_xmss
>> >>> >> > debug1: SSH2_MSG_EXT_INFO received
>> >>> >> > debug1: kex_input_ext_info:
>> >>> >> > server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com
>> >>> >> > <mailto:sk-ssh-ed25519@openssh.com
>> >>> >>
>> >>>
>> >,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
>> >>> >> sk-ecdsa-sha2-nistp256@openssh.com
>> >>> >> > <mailto:sk-ecdsa-sha2-nistp256@openssh.com>,
>> >>> >> webauthn-sk-ecdsa-sha2-nistp256@openssh.com
>> >>> >> > <mailto:webauthn-sk-ecdsa-sha2-nistp256@openssh.com>>
>> >>> >> > debug1: SSH2_MSG_SERVICE_ACCEPT received
>> >>> >> > debug1: Authentications that can continue:
>> >>> >> >
>> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
>> >>> >> > debug1: Next authentication method: gssapi-with-mic
>> >>> >> > *debug1: Unspecified GSS failure.  Minor code may provide more
>> >>> >> information
>> >>> >> > Server host/10.40.1.201@ALPHA-GREP.COM
>> >>> >> > <mailto:10.40.1.201@ALPHA-GREP.COM> not found in Kerberos
>> database*
>> >>> >>
>> >>> >> IPA keys on hostnames, not IP addresses, hence this message. You
>> need
>> >>> to
>> >>> >> use a FQDN. AFAIK there is no workaround.
>> >>> >>
>> >>> >> > debug1: Authentications that can continue:
>> >>> >> >
>> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
>> >>> >> > debug1: Next authentication method: publickey
>> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_rsa
>> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_dsa
>> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa
>> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa_sk
>> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_ed25519
>> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_ed25519_sk
>> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_xmss
>> >>> >> > debug1: Next authentication method: keyboard-interactive
>> >>> >> > (kns@10.40.1.201 <mailto:kns@10.40.1.201>) Password:
>> >>> >>
>> >>> >> It failed to do a Kerberos/GSSAPI auth so it fell back to password.
>> >>> >>
>> >>> >> rob
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> / 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