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.prad...@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-sha...@libssh.org > ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, > sntrup761x25519-sha...@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-poly1...@openssh.com > ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, > aes256-...@openssh.com > debug2: ciphers stoc: chacha20-poly1...@openssh.com > ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com, > aes256-...@openssh.com > debug2: MACs ctos: umac-64-...@openssh.com,umac-128-...@openssh.com, > hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, > hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: MACs stoc: umac-64-...@openssh.com,umac-128-...@openssh.com, > hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, > hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: compression ctos: none,z...@openssh.com,zlib > debug2: compression stoc: none,z...@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-sha...@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-...@openssh.com,chacha20-poly1...@openssh.com > ,aes256-ctr,aes128-...@openssh.com,aes128-ctr > debug2: ciphers stoc: aes256-...@openssh.com,chacha20-poly1...@openssh.com > ,aes256-ctr,aes128-...@openssh.com,aes128-ctr > debug2: MACs ctos: hmac-sha2-256-...@openssh.com,hmac-sha1-...@openssh.com > ,umac-128-...@openssh.com,hmac-sha2-512-...@openssh.com > ,hmac-sha2-256,hmac-sha1,umac-...@openssh.com,hmac-sha2-512 > debug2: MACs stoc: hmac-sha2-256-...@openssh.com,hmac-sha1-...@openssh.com > ,umac-128-...@openssh.com,hmac-sha2-512-...@openssh.com > ,hmac-sha2-256,hmac-sha1,umac-...@openssh.com,hmac-sha2-512 > debug2: compression ctos: none,z...@openssh.com > debug2: compression stoc: none,z...@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-poly1...@openssh.com MAC: > <implicit> compression: none > debug1: kex: client->server cipher: chacha20-poly1...@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-ed25...@openssh.com > ,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, > sk-ecdsa-sha2-nistp...@openssh.com, > webauthn-sk-ecdsa-sha2-nistp...@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-sessi...@openssh.com > debug1: Entering interactive session. > debug1: pledge: filesystem > debug1: client_input_global_request: rtype hostkeys...@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.prad...@alpha-grep.com> > wrote: > >> Thanks Alexander,Thanks for the info >> >> On Tue, 3 Oct 2023 at 2:21 PM, Alexander Bokovoy <aboko...@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 <aboko...@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.prad...@alpha-grep.com> >>> >> >wrote: >>> >> > >>> >> >> Awesome, thanks for the info! >>> >> >> >>> >> >> On Tue, 3 Oct 2023 at 1:44 PM, Alexander Bokovoy < >>> aboko...@redhat.com> >>> >> >> wrote: >>> >> >> >>> >> >>> On Аўт, 03 кас 2023, Pradeep KNS via FreeIPA-users wrote: >>> >> >>> >Hi Rob, >>> >> >>> > >>> >> >>> >Thanks for your email, >>> >> >>> > >>> >> >>> >Yeah true FQDN is working without any issues.But is there any >>> way to >>> >> ssh >>> >> >>> >via IP as well rather than hostname >>> >> >>> >>> >> >>> Kerberos authentication is based on names of services known to >>> your >>> >> KDC. >>> >> >>> IP address is not a name in this context and is not associated >>> with the >>> >> >>> service host/$FQDN, hence it is not found in the Kerberos >>> database. >>> >> >>> >>> >> >>> You can add such service name alias using 'ipa host-add-principal' >>> >> >>> command. It is, however, not always enough because most Kerberos >>> >> >>> services do not expect to operate with multiple aliases. Luckily, >>> SSH >>> >> >>> works fine with such tickets in IPA environment. >>> >> >>> >>> >> >>> $ ipa host-add-principal server.ipa.example host/10.40.1.201 >>> >> >>> --------------------------------------- >>> >> >>> Added new aliases to host "server.ipa.example" >>> >> >>> --------------------------------------- >>> >> >>> Host name: server.ipa.example >>> >> >>> Principal alias: host/server.ipa.example@IPA.EXAMPLE, >>> >> >>> host/10.40.1.201@IPA.EXAMPLE >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> > >>> >> >>> >On Tue, 3 Oct 2023 at 2:22 AM, Rob Crittenden < >>> rcrit...@redhat.com> >>> >> >>> wrote: >>> >> >>> > >>> >> >>> >> Pradeep KNS wrote: >>> >> >>> >> > ssh kns@10.40.1.201 -v >>> >> >>> >> >>> >> >>> >> [snip] >>> >> >>> >> >>> >> >>> >> > SHA256:1BAWa9F52c6u26qe8T9ZQsin3lk+VTFeRYBDtkOzNMU >>> >> >>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts: No >>> such >>> >> >>> file or >>> >> >>> >> > directory >>> >> >>> >> > debug1: load_hostkeys: fopen /home/kns/.ssh/known_hosts2: No >>> such >>> >> >>> file >>> >> >>> >> > or directory >>> >> >>> >> > debug1: Host '10.40.1.201' is known and matches the ED25519 >>> host >>> >> key. >>> >> >>> >> > debug1: Found key in /var/lib/sss/pubconf/known_hosts:2 >>> >> >>> >> >>> >> >>> >> The SSSD ssh integration was used to to validate that the >>> host's SSH >>> >> >>> key >>> >> >>> >> matched what was received so you avoided the "do you trust this >>> >> host" >>> >> >>> >> prompt. So that's good. >>> >> >>> >> >>> >> >>> >> > debug1: rekey out after 4294967296 blocks >>> >> >>> >> > debug1: SSH2_MSG_NEWKEYS sent >>> >> >>> >> > debug1: expecting SSH2_MSG_NEWKEYS >>> >> >>> >> > debug1: SSH2_MSG_NEWKEYS received >>> >> >>> >> > debug1: rekey in after 4294967296 blocks >>> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_rsa >>> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_dsa >>> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa >>> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ecdsa_sk >>> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519 >>> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_ed25519_sk >>> >> >>> >> > debug1: Will attempt key: /home/kns/.ssh/id_xmss >>> >> >>> >> > debug1: SSH2_MSG_EXT_INFO received >>> >> >>> >> > debug1: kex_input_ext_info: >>> >> >>> >> > server-sig-algs=<ssh-ed25519,sk-ssh-ed25...@openssh.com >>> >> >>> >> > <mailto:sk-ssh-ed25...@openssh.com >>> >> >>> >> >>> >> >>> >>> >> >>> >,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, >>> >> >>> >> sk-ecdsa-sha2-nistp...@openssh.com >>> >> >>> >> > <mailto:sk-ecdsa-sha2-nistp...@openssh.com>, >>> >> >>> >> webauthn-sk-ecdsa-sha2-nistp...@openssh.com >>> >> >>> >> > <mailto:webauthn-sk-ecdsa-sha2-nistp...@openssh.com>> >>> >> >>> >> > debug1: SSH2_MSG_SERVICE_ACCEPT received >>> >> >>> >> > debug1: Authentications that can continue: >>> >> >>> >> > >>> >> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive >>> >> >>> >> > debug1: Next authentication method: gssapi-with-mic >>> >> >>> >> > *debug1: Unspecified GSS failure. Minor code may provide >>> more >>> >> >>> >> information >>> >> >>> >> > Server host/10.40.1....@alpha-grep.com >>> >> >>> >> > <mailto:10.40.1....@alpha-grep.com> not found in Kerberos >>> >> database* >>> >> >>> >> >>> >> >>> >> IPA keys on hostnames, not IP addresses, hence this message. >>> You >>> >> need >>> >> >>> to >>> >> >>> >> use a FQDN. AFAIK there is no workaround. >>> >> >>> >> >>> >> >>> >> > debug1: Authentications that can continue: >>> >> >>> >> > >>> >> publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive >>> >> >>> >> > debug1: Next authentication method: publickey >>> >> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_rsa >>> >> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_dsa >>> >> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa >>> >> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_ecdsa_sk >>> >> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_ed25519 >>> >> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_ed25519_sk >>> >> >>> >> > debug1: Trying private key: /home/kns/.ssh/id_xmss >>> >> >>> >> > debug1: Next authentication method: keyboard-interactive >>> >> >>> >> > (kns@10.40.1.201 <mailto:kns@10.40.1.201>) Password: >>> >> >>> >> >>> >> >>> >> It failed to do a Kerberos/GSSAPI auth so it fell back to >>> password. >>> >> >>> >> >>> >> >>> >> rob >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> -- >>> >> >>> / Alexander Bokovoy >>> >> >>> Sr. Principal Software Engineer >>> >> >>> Security / Identity Management Engineering >>> >> >>> Red Hat Limited, Finland >>> >> >>> >>> >> >>> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> / Alexander Bokovoy >>> >> Sr. Principal Software Engineer >>> >> Security / Identity Management Engineering >>> >> Red Hat Limited, Finland >>> >> >>> >> >>> >>> >>> >>> >>> -- >>> / Alexander Bokovoy >>> Sr. Principal Software Engineer >>> Security / Identity Management Engineering >>> Red Hat Limited, Finland >>> >>>
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
