Can't SSH to client after migrate

[Faraz Younus]

Hello Team,

I migrated freeipa client which is having 3.0 version to new freeipa server
version 4.6 and host is successfully enrolled on new IPA server but I can
not ssh into the client machine.

ssh [e-mail]

[e-mail]'s password:

Permission denied, please try again.

Is this the version issue due to which I can't login via ssh ?

Looking forward to your reply.

Thanks

Faraz

[Alexander Bokovoy]

On su, 22 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> Hello Team,
>
> I migrated freeipa client which is having 3.0 version to new freeipa server
> version 4.6 and host is successfully enrolled on new IPA server but I can
> not ssh into the client machine.
>
> ssh [e-mail]
>
> [e-mail]'s password:
>
> Permission denied, please try again.
>
> Is this the version issue due to which I can't login via ssh ?

Please follow SSSD troubleshooting guide.
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

[Faraz Younus]

Its not helping can you elaborate specifically ?

On Sun, Mar 22, 2020 at 12:37 PM Alexander Bokovoy 
wrote:
> On su, 22 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> > Hello Team,
> >
> > I migrated freeipa client which is having 3.0 version to new freeipa
>
> server
> > version 4.6 and host is successfully enrolled on new IPA server but I can
> > not ssh into the client machine.
> >
> > ssh [e-mail]
> >
> > [e-mail]'s password:
> >
> > Permission denied, please try again.
> >
> > Is this the version issue due to which I can't login via ssh ?
>
> Please follow SSSD troubleshooting guide.
> https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

[Alexander Bokovoy]

On su, 22 maalis 2020, Faraz Younus wrote:
> Its not helping can you elaborate specifically ?

You are literally providing zero details about your problem.

SSH server on Linux clients typically is configured to allow PAM
authentication. If your client is enrolled into IPA, then it is
configured to run SSSD and authenticate your users through PAM stack. It
means that your ways of debugging are along the following lines:

- look into existing system log to get an exact message SSH server is
    giving for a login attempt
  - enable SSH server debug log level to see what causes the issue if
    that is not clear
  - enable debugging for SSSD if you consider the issue is from pam_sss

Your original email has no details on either of these steps.

In any case, it is the work that nobody else can do for you. If you have
not gathered this information, nobody will able to help you, so we need
*your* help in order to be able to help *you*.

This is a community mailing list, there are no obligations to solve
any problems you are reporting, even if more detailed information is
available. However, people here could help to diagnoze a problem if
there would be any way to help. Without any substantiated details the
only way to do that is to speculate which is not something that, in my
opinion, should be done.

[Faraz Younus]

Sorry for not sharing the error my bad. I enabled sssd but ldap child error
on decrypt

Mar 22 11:11:26  sssd[be[fixedandmobile.com]]: Starting up

Mar 22 11:11:26  sssd[nss]: Starting up

Mar 22 11:11:26  sssd[pam]: Starting up

Mar 22 11:11:26 sssd[pac]: Starting up

Mar 22 11:11:26  sssd[ssh]: Starting up

Mar 22 11:11:26 sssd[sudo]: Starting up

Mar 22 11:11:32  [sssd[ldap_child[19468]]]: Failed to initialize
credentials using keytab [default]: Decrypt integrity check failed. Unable
to create GSSAPI-encrypted LDAP connection.

*:/var/log/sssd # *tail -f  ldap_child.log

(Sun Mar 22 10:52:10 2020) [[sssd[ldap_child[19122]]]]
[ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
integrity check failed

(Sun Mar 22 11:04:53 2020) [[sssd[ldap_child[19332]]]]
[ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
integrity check failed

^C

On Sun, Mar 22, 2020 at 3:54 PM Alexander Bokovoy 
wrote:
> On su, 22 maalis 2020, Faraz Younus wrote:
> > Its not helping can you elaborate specifically ?
>
> You are literally providing zero details about your problem.
>
> SSH server on Linux clients typically is configured to allow PAM
> authentication. If your client is enrolled into IPA, then it is
> configured to run SSSD and authenticate your users through PAM stack. It
> means that your ways of debugging are along the following lines:
> look into existing system log to get an exact message SSH server is
> giving for a login attempt
> enable SSH server debug log level to see what causes the issue if
> that is not clear
> enable debugging for SSSD if you consider the issue is from pam_sss
>
> Your original email has no details on either of these steps.
>
> In any case, it is the work that nobody else can do for you. If you have
> not gathered this information, nobody will able to help you, so we need
> *your* help in order to be able to help *you*.
>
> This is a community mailing list, there are no obligations to solve
> any problems you are reporting, even if more detailed information is
> available. However, people here could help to diagnoze a problem if
> there would be any way to help. Without any substantiated details the
> only way to do that is to speculate which is not something that, in my
> opinion, should be done.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

[Alexander Bokovoy]

On su, 22 maalis 2020, Faraz Younus wrote:
> Sorry for not sharing the error my bad. I enabled sssd but ldap child error
> on decrypt
>
> Mar 22 11:11:26  sssd[be[fixedandmobile.com]]: Starting up
>
> Mar 22 11:11:26  sssd[nss]: Starting up
>
> Mar 22 11:11:26  sssd[pam]: Starting up
>
> Mar 22 11:11:26 sssd[pac]: Starting up
>
> Mar 22 11:11:26  sssd[ssh]: Starting up
>
> Mar 22 11:11:26 sssd[sudo]: Starting up
>
> Mar 22 11:11:32  [sssd[ldap_child[19468]]]: Failed to initialize
> credentials using keytab [default]: Decrypt integrity check failed. Unable
> to create GSSAPI-encrypted LDAP connection.

This means your /etc/krb5.keytab contains the key from old IPA setup,
most likely. This key is unknown to your new KDC (IPA master) so it is
not able to successfully authenticate your client.

Please show two things:

1. On IPA master, do
   kinit admin
   kvno -S host client.host.name

2. On the client itself, do
   klist -k

The key version number (KVNO) in both cases should be the same. If you
fully reinstalled your IPA master, it might actually be the same but the
key would be totally different. In such case you need to regenerate the
key again, but first show the result of these two operations.
> *:/var/log/sssd # *tail -f  ldap_child.log
>
> (Sun Mar 22 10:52:10 2020) [[sssd[ldap_child[19122]]]]
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
> integrity check failed
>
> (Sun Mar 22 11:04:53 2020) [[sssd[ldap_child[19332]]]]
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
> integrity check failed
>
> ^C
>
> On Sun, Mar 22, 2020 at 3:54 PM Alexander Bokovoy 
> wrote:
> > On su, 22 maalis 2020, Faraz Younus wrote:
> > > Its not helping can you elaborate specifically ?
> >
> > You are literally providing zero details about your problem.
> >
> > SSH server on Linux clients typically is configured to allow PAM
> > authentication. If your client is enrolled into IPA, then it is
> > configured to run SSSD and authenticate your users through PAM stack. It
> > means that your ways of debugging are along the following lines:
> > look into existing system log to get an exact message SSH server is
> > giving for a login attempt
> > enable SSH server debug log level to see what causes the issue if
> > that is not clear
> > enable debugging for SSSD if you consider the issue is from pam_sss
> >
> > Your original email has no details on either of these steps.
> >
> > In any case, it is the work that nobody else can do for you. If you have
> > not gathered this information, nobody will able to help you, so we need
> > *your* help in order to be able to help *you*.
> >
> > This is a community mailing list, there are no obligations to solve
> > any problems you are reporting, even if more detailed information is
> > available. However, people here could help to diagnoze a problem if
> > there would be any way to help. Without any substantiated details the
> > only way to do that is to speculate which is not something that, in my
> > opinion, should be done.
> >
> > --
> > / Alexander Bokovoy
> > Sr. Principal Software Engineer
> > Security / Identity Management Engineering
> > Red Hat Limited, Finland

[Faraz Younus]

Thanks for your swift replies. below are output

ipamaster# kvno -S host england-web-dev.fixedandmobile.com

host/[e-mail]: kvno = 1

client# klist -k

Keytab name: FILE:/etc/krb5.keytab

KVNO Principal

----
--------------------------------------------------------------------------

1 host/[e-mail]

1 host/[e-mail]

1 host/[e-mail]

1 host/[e-mail]

On Sun, Mar 22, 2020 at 4:30 PM Alexander Bokovoy 
wrote:
> On su, 22 maalis 2020, Faraz Younus wrote:
> > Sorry for not sharing the error my bad. I enabled sssd but ldap child
>
> error
> > on decrypt
> >
> > Mar 22 11:11:26  sssd[be[fixedandmobile.com]]: Starting up
> >
> > Mar 22 11:11:26  sssd[nss]: Starting up
> >
> > Mar 22 11:11:26  sssd[pam]: Starting up
> >
> > Mar 22 11:11:26 sssd[pac]: Starting up
> >
> > Mar 22 11:11:26  sssd[ssh]: Starting up
> >
> > Mar 22 11:11:26 sssd[sudo]: Starting up
> >
> > Mar 22 11:11:32  [sssd[ldap_child[19468]]]: Failed to initialize
> > credentials using keytab [default]: Decrypt integrity check failed. Unable
> > to create GSSAPI-encrypted LDAP connection.
>
> This means your /etc/krb5.keytab contains the key from old IPA setup,
> most likely. This key is unknown to your new KDC (IPA master) so it is
> not able to successfully authenticate your client.
>
> Please show two things:
>
> On IPA master, do
> kinit admin
> kvno -S host client.host.name
>
> On the client itself, do
> klist -k
>
> The key version number (KVNO) in both cases should be the same. If you
> fully reinstalled your IPA master, it might actually be the same but the
> key would be totally different. In such case you need to regenerate the
> key again, but first show the result of these two operations.
> > *:/var/log/sssd # *tail -f  ldap_child.log
> >
> > (Sun Mar 22 10:52:10 2020) [[sssd[ldap_child[19122]]]]
> > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
> > integrity check failed
> >
> > (Sun Mar 22 11:04:53 2020) [[sssd[ldap_child[19332]]]]
> > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
> > integrity check failed
> >
> > ^C
> >
> > On Sun, Mar 22, 2020 at 3:54 PM Alexander Bokovoy 
> > wrote:
> > > On su, 22 maalis 2020, Faraz Younus wrote:
> > > > Its not helping can you elaborate specifically ?
> > >
> > > You are literally providing zero details about your problem.
> > >
> > > SSH server on Linux clients typically is configured to allow PAM
> > > authentication. If your client is enrolled into IPA, then it is
> > > configured to run SSSD and authenticate your users through PAM stack. It
> > > means that your ways of debugging are along the following lines:
> > > look into existing system log to get an exact message SSH server is
> > > giving for a login attempt
> > > enable SSH server debug log level to see what causes the issue if
> > > that is not clear
> > > enable debugging for SSSD if you consider the issue is from pam_sss
> > >
> > > Your original email has no details on either of these steps.
> > >
> > > In any case, it is the work that nobody else can do for you. If you have
> > > not gathered this information, nobody will able to help you, so we need
> > > *your* help in order to be able to help *you*.
> > >
> > > This is a community mailing list, there are no obligations to solve
> > > any problems you are reporting, even if more detailed information is
> > > available. However, people here could help to diagnoze a problem if
> > > there would be any way to help. Without any substantiated details the
> > > only way to do that is to speculate which is not something that, in my
> > > opinion, should be done.
> > >
> > > --
> > > / 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 su, 22 maalis 2020, Faraz Younus wrote:
> Thanks for your swift replies. below are output
>
> ipamaster# kvno -S host england-web-dev.fixedandmobile.com
>
> host/[e-mail]: kvno = 1
>
> client# klist -k
>
> Keytab name: FILE:/etc/krb5.keytab
>
> KVNO Principal
>
> 1 host/[e-mail]
>
> 1 host/[e-mail]
>
> 1 host/[e-mail]
>
> 1 host/[e-mail]

ok, does

KRB5_TRACE=/dev/stderr kinit -k

work on the client?

I think it should produce an error in a way similar to what SSSD logs
tell.

If it does fail, you need to regenerate the key on the client by using

# kinit admin
# ipa-getkeytab -s ipa.master.host -p host/england-web-dev.fixedandmobile.com -k /etc/krb5.keytab
> On Sun, Mar 22, 2020 at 4:30 PM Alexander Bokovoy 
> wrote:
> > On su, 22 maalis 2020, Faraz Younus wrote:
> > > Sorry for not sharing the error my bad. I enabled sssd but ldap child
> >
> > error
> > > on decrypt
> > >
> > > Mar 22 11:11:26  sssd[be[fixedandmobile.com]]: Starting up
> > >
> > > Mar 22 11:11:26  sssd[nss]: Starting up
> > >
> > > Mar 22 11:11:26  sssd[pam]: Starting up
> > >
> > > Mar 22 11:11:26 sssd[pac]: Starting up
> > >
> > > Mar 22 11:11:26  sssd[ssh]: Starting up
> > >
> > > Mar 22 11:11:26 sssd[sudo]: Starting up
> > >
> > > Mar 22 11:11:32  [sssd[ldap_child[19468]]]: Failed to initialize
> > > credentials using keytab [default]: Decrypt integrity check failed. Unable
> > > to create GSSAPI-encrypted LDAP connection.
> >
> > This means your /etc/krb5.keytab contains the key from old IPA setup,
> > most likely. This key is unknown to your new KDC (IPA master) so it is
> > not able to successfully authenticate your client.
> >
> > Please show two things:
> >
> > On IPA master, do
> > kinit admin
> > kvno -S host client.host.name
> >
> > On the client itself, do
> > klist -k
> >
> > The key version number (KVNO) in both cases should be the same. If you
> > fully reinstalled your IPA master, it might actually be the same but the
> > key would be totally different. In such case you need to regenerate the
> > key again, but first show the result of these two operations.
> > > *:/var/log/sssd # *tail -f  ldap_child.log
> > >
> > > (Sun Mar 22 10:52:10 2020) [[sssd[ldap_child[19122]]]]
> > > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
> > > integrity check failed
> > >
> > > (Sun Mar 22 11:04:53 2020) [[sssd[ldap_child[19332]]]]
> > > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
> > > integrity check failed
> > >
> > > ^C
> > >
> > > On Sun, Mar 22, 2020 at 3:54 PM Alexander Bokovoy 
> > > wrote:
> > > > On su, 22 maalis 2020, Faraz Younus wrote:
> > > > > Its not helping can you elaborate specifically ?
> > > >
> > > > You are literally providing zero details about your problem.
> > > >
> > > > SSH server on Linux clients typically is configured to allow PAM
> > > > authentication. If your client is enrolled into IPA, then it is
> > > > configured to run SSSD and authenticate your users through PAM stack. It
> > > > means that your ways of debugging are along the following lines:
> > > > look into existing system log to get an exact message SSH server is
> > > > giving for a login attempt
> > > > enable SSH server debug log level to see what causes the issue if
> > > > that is not clear
> > > > enable debugging for SSSD if you consider the issue is from pam_sss
> > > >
> > > > Your original email has no details on either of these steps.
> > > >
> > > > In any case, it is the work that nobody else can do for you. If you have
> > > > not gathered this information, nobody will able to help you, so we need
> > > > *your* help in order to be able to help *you*.
> > > >
> > > > This is a community mailing list, there are no obligations to solve
> > > > any problems you are reporting, even if more detailed information is
> > > > available. However, people here could help to diagnoze a problem if
> > > > there would be any way to help. Without any substantiated details the
> > > > only way to do that is to speculate which is not something that, in my
> > > > opinion, should be done.
> > > >
> > > > --
> > > > / 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

[Faraz Younus]

Yes command is working but giving this error :  Received error from KDC:
-1765328359/Additional pre-authentication required

Still cannot ssh

*:/var/log # *KRB5_TRACE=/dev/stderr kinit -k

[20249] 1584879239.63392: Getting initial credentials for host/
[e-mail]

[20249] 1584879239.64552: Looked up etypes in keytab: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac

[20249] 1584879239.64627: Sending request (227 bytes) to FIXEDANDMOBILE.COM

[20249] 1584879239.65352: Sending initial UDP request to dgram
10.163.2.114:88

[20249] 1584879239.68290: Received answer from dgram 10.163.2.114:88

[20249] 1584879239.68427: Response was from master KDC

[20249] 1584879239.68482: Received error from KDC: -1765328359/Additional
pre-authentication required

[20249] 1584879239.68568: Processing preauth types: 16, 15, 14, 136, 19,
147, 2, 133

[20249] 1584879239.68603: Selected etype info: etype aes256-cts, salt "
FIXEDANDMOBILE.COMhostengland-web-dev.fixedandmobile.com", params ""

[20249] 1584879239.68617: Received cookie: MIT

[20249] 1584879239.68746: Retrieving host/
[e-mail] from
FILE:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: 0/Success

[20249] 1584879239.68831: AS key obtained for encrypted timestamp:
aes256-cts/854B

[20249] 1584879239.68933: Encrypted timestamp (for 1584879239.68844): plain
301AA011180F32303230303332323132313335395AA1050203010CEC, encrypted
8D7992231E4A52AD8F536BA8BFFB6308B1F793078F178B1C0E0E36CA4004BD23D58038BA59470EFBC8C67659C562E9EED2E46848F4391C59

[20249] 1584879239.68960: Preauth module encrypted_timestamp (2) (flags=1)
returned: 0/Success

[20249] 1584879239.68974: Produced preauth for next request: 133, 2

[20249] 1584879239.69000: Sending request (322 bytes) to FIXEDANDMOBILE.COM

[20249] 1584879239.69396: Sending initial UDP request to dgram
10.163.2.114:88

[20249] 1584879239.72389: Received answer from dgram 10.163.2.114:88

[20249] 1584879239.72521: Response was from master KDC

[20249] 1584879239.72581: Processing preauth types: 19

[20249] 1584879239.72598: Selected etype info: etype aes256-cts, salt "
FIXEDANDMOBILE.COMhostengland-web-dev.fixedandmobile.com", params ""

[20249] 1584879239.72612: Produced preauth for next request: (empty)

[20249] 1584879239.72629: AS key determined by preauth: aes256-cts/854B

[20249] 1584879239.72747: Decrypted AS reply; session key is:
aes256-cts/97E0

[20249] 1584879239.72780: FAST negotiation: available

[20249] 1584879239.72834: Initializing FILE:/tmp/krb5cc_0 with default
princ host/[e-mail]

[20249] 1584879239.73401: Removing host/
[e-mail] -> krbtgt/
[e-mail] from FILE:/tmp/krb5cc_0

[20249] 1584879239.73424: Storing host/
[e-mail] -> krbtgt/
[e-mail] in FILE:/tmp/krb5cc_0

[20249] 1584879239.73766: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/
[e-mail]: fast_avail: yes

[20249] 1584879239.73841: Removing host/
[e-mail] ->
krb5_ccache_conf_data/fast_avail/krbtgt/FIXEDANDMOBILE.COM
@FIXEDANDMOBILE.COM@X-CACHECONF: from FILE:/tmp/krb5cc_0

[20249] 1584879239.73858: Storing host/
[e-mail] ->
krb5_ccache_conf_data/fast_avail/krbtgt/FIXEDANDMOBILE.COM
@FIXEDANDMOBILE.COM@X-CACHECONF: in FILE:/tmp/krb5cc_0

*:/var/log # *kinit admin

Password for [e-mail]:

*:/var/log # *ipa-getkeytab -s ipa1.fixedandmobile.com -p host/
england-web-dev.fixedandmobile.com -k /etc/krb5.keytab

*:/var/log # *service sssd status

sssd (pid  19460) is running...

*:/var/log # *service sssd restart

Stopping sssd:                                             [  OK  ]

Starting sssd:                                             [  OK  ]

*:/var/log # *klist

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: [e-mail]

Valid starting     Expires            Service principal

03/22/20 12:15:02  03/23/20 12:14:57  krbtgt/
[e-mail]

On Sun, Mar 22, 2020 at 5:03 PM Alexander Bokovoy 
wrote:
> On su, 22 maalis 2020, Faraz Younus wrote:
> > Thanks for your swift replies. below are output
> >
> > ipamaster# kvno -S host england-web-dev.fixedandmobile.com
> >
> > host/[e-mail]: kvno = 1
> >
> > client# klist -k
> >
> > Keytab name: FILE:/etc/krb5.keytab
> >
> > KVNO Principal
> >
> > 1 host/[e-mail]
> >
> > 1 host/[e-mail]
> >
> > 1 host/[e-mail]
> >
> > 1 host/[e-mail]
>
> ok, does
>
> KRB5_TRACE=/dev/stderr kinit -k
>
> work on the client?
>
> I think it should produce an error in a way similar to what SSSD logs
> tell.
>
> If it does fail, you need to regenerate the key on the client by using
>
> # kinit admin
> # ipa-getkeytab -s ipa.master.host -p host/
> england-web-dev.fixedandmobile.com -k /etc/krb5.keytab
> > On Sun, Mar 22, 2020 at 4:30 PM Alexander Bokovoy 
> > wrote:
> > > On su, 22 maalis 2020, Faraz Younus wrote:
> > > > Sorry for not sharing the error my bad. I enabled sssd but ldap child
> > >
> > > error
> > > > on decrypt
> > > >
> > > > Mar 22 11:11:26  sssd[be[fixedandmobile.com]]: Starting up
> > > >
> > > > Mar 22 11:11:26  sssd[nss]: Starting up
> > > >
> > > > Mar 22 11:11:26  sssd[pam]: Starting up
> > > >
> > > > Mar 22 11:11:26 sssd[pac]: Starting up
> > > >
> > > > Mar 22 11:11:26  sssd[ssh]: Starting up
> > > >
> > > > Mar 22 11:11:26 sssd[sudo]: Starting up
> > > >
> > > > Mar 22 11:11:32  [sssd[ldap_child[19468]]]: Failed to initialize
> > > > credentials using keytab [default]: Decrypt integrity check failed.
>
> Unable
> > > > to create GSSAPI-encrypted LDAP connection.
> > >
> > > This means your /etc/krb5.keytab contains the key from old IPA setup,
> > > most likely. This key is unknown to your new KDC (IPA master) so it is
> > > not able to successfully authenticate your client.
> > >
> > > Please show two things:
> > >
> > > On IPA master, do
> > > kinit admin
> > > kvno -S host client.host.name
> > >
> > > On the client itself, do
> > > klist -k
> > >
> > > The key version number (KVNO) in both cases should be the same. If you
> > > fully reinstalled your IPA master, it might actually be the same but the
> > > key would be totally different. In such case you need to regenerate the
> > > key again, but first show the result of these two operations.
> > > > *:/var/log/sssd # *tail -f  ldap_child.log
> > > >
> > > > (Sun Mar 22 10:52:10 2020) [[sssd[ldap_child[19122]]]]
> > > > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
> > > > integrity check failed
> > > >
> > > > (Sun Mar 22 11:04:53 2020) [[sssd[ldap_child[19332]]]]
> > > > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt
> > > > integrity check failed
> > > >
> > > > ^C
> > > >
> > > > On Sun, Mar 22, 2020 at 3:54 PM Alexander Bokovoy <[e-mail]
> > > > wrote:
> > > > > On su, 22 maalis 2020, Faraz Younus wrote:
> > > > > > Its not helping can you elaborate specifically ?
> > > > >
> > > > > You are literally providing zero details about your problem.
> > > > >
> > > > > SSH server on Linux clients typically is configured to allow PAM
> > > > > authentication. If your client is enrolled into IPA, then it is
> > > > > configured to run SSSD and authenticate your users through PAM
>
> stack. It
> > > > > means that your ways of debugging are along the following lines:
> > > > > look into existing system log to get an exact message SSH server
>
> is
> > > > > giving for a login attempt
> > > > > enable SSH server debug log level to see what causes the issue if
> > > > > that is not clear
> > > > > enable debugging for SSSD if you consider the issue is from
>
> pam_sss
> > > > > Your original email has no details on either of these steps.
> > > > >
> > > > > In any case, it is the work that nobody else can do for you. If you
>
> have
> > > > > not gathered this information, nobody will able to help you, so we
>
> need
> > > > > *your* help in order to be able to help *you*.
> > > > >
> > > > > This is a community mailing list, there are no obligations to solve
> > > > > any problems you are reporting, even if more detailed information is
> > > > > available. However, people here could help to diagnoze a problem if
> > > > > there would be any way to help. Without any substantiated details the
> > > > > only way to do that is to speculate which is not something that, in
>
> my
> > > > > opinion, should be done.
> > > > >
> > > > > --
> > > > > / 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

[Alexander Bokovoy]

On su, 22 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> Yes command is working but giving this error :  Received error from KDC:
> -1765328359/Additional pre-authentication required
>
> Still cannot ssh

From the output you provided, I do not see any errors anymore. Where do you see
'Received error from KDC ...'?

Could you please share more log details?

[Faraz Younus]

that's the only logs I have on client , but on master server I'm getting
this on krb5kdc.log

Mar 22 12:31:32 ipa1.fixedandmobile.com krb5kdc[7890](info): AS_REQ (4
etypes {18 17 16 23}) 10.160.253.104: NEEDED_PREAUTH: host/*england*-
[e-mail] for krbtgt/
[e-mail], Additional pre-authentication
required

Mar 22 12:31:32 ipa1.fixedandmobile.com krb5kdc[7891](info): AS_REQ (4
etypes {18 17 16 23}) 10.160.253.104: ISSUE: authtime 1584880292, etypes
{rep=18 tkt=18 ses=18}, host/*england*-
[e-mail] for krbtgt/
[e-mail]

On Sun, Mar 22, 2020 at 5:25 PM Alexander Bokovoy 
wrote:
> On su, 22 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> > Yes command is working but giving this error :  Received error from KDC:
> > -1765328359/Additional pre-authentication required
> >
> > Still cannot ssh
>
> From the output you provided, I do not see any errors anymore. Where do
> you see
> 'Received error from KDC ...'?
>
> Could you please share more log details?
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

[Alexander Bokovoy]

On su, 22 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> that's the only logs I have on client , but on master server I'm getting
> this on krb5kdc.log
>
> Mar 22 12:31:32 ipa1.fixedandmobile.com krb5kdc[7890](info): AS_REQ (4
> etypes {18 17 16 23}) 10.160.253.104: NEEDED_PREAUTH: host/*england*-
> [e-mail] for krbtgt/
> [e-mail], Additional pre-authentication
> required
>
> Mar 22 12:31:32 ipa1.fixedandmobile.com krb5kdc[7891](info): AS_REQ (4
> etypes {18 17 16 23}) 10.160.253.104: ISSUE: authtime 1584880292, etypes
> {rep=18 tkt=18 ses=18}, host/*england*-
> [e-mail] for krbtgt/
> [e-mail]

these two are not problems at all. This is correct sequence of logged
actions for normal operations.

Now that you have Kerberos key for host/.. principal working fine,
continue with SSSD logs for your ssh client access attempt.

[Faraz Younus]

I'm not getting logs on sssd while accessing ssh however I'm getting logs
in secure logs, it is looking for linux user

On Mon, Mar 23, 2020, 12:11 AM Alexander Bokovoy 
wrote:
> On su, 22 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> > that's the only logs I have on client , but on master server I'm getting
> > this on krb5kdc.log
> >
> > Mar 22 12:31:32 ipa1.fixedandmobile.com krb5kdc[7890](info): AS_REQ (4
> > etypes {18 17 16 23}) 10.160.253.104: NEEDED_PREAUTH: host/*england*-
> > [e-mail] for krbtgt/
> > [e-mail], Additional pre-authentication
> > required
> >
> > Mar 22 12:31:32 ipa1.fixedandmobile.com krb5kdc[7891](info): AS_REQ (4
> > etypes {18 17 16 23}) 10.160.253.104: ISSUE: authtime 1584880292, etypes
> > {rep=18 tkt=18 ses=18}, host/*england*-
> > [e-mail] for krbtgt/
> > [e-mail]
>
> these two are not problems at all. This is correct sequence of logged
> actions for normal operations.
>
> Now that you have Kerberos key for host/.. principal working fine,
> continue with SSSD logs for your ssh client access attempt.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

[Alexander Bokovoy]

On ma, 23 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> I'm not getting logs on sssd while accessing ssh however I'm getting logs
> in secure logs, it is looking for linux user

How did you enroll this machine? What distribution does it run?

Then you need to check your pam configuration for ssh server to see what
is there. On RHEL/Fedora it is /etc/pam.d/sshd. If it has

auth substack password-auth
auth include postlogin

then /etc/pam.d/password-auth defines what authentication is used.

There should be pam_sss mentioned.

For details see manual page for pam.d(5).

[Faraz Younus]

I enrolled my client using below command previously it was working for
other old freeipa server with 3.0 version, Now I enrolled this client 3.0
version with new IPA server with version 4.6.

ipa-client-install --mkhomedir --server=ipa1.example.com --domain=
example.com

Below are config currently on my client machine

*england-web-dev:/home/ansible # *cat  /etc/pam.d/sshd

#%PAM-1.0

auth   required pam_sepermit.so

auth       include      password-auth

account    required     pam_nologin.so

account    include      password-auth

password   include      password-auth

# pam_selinux.so close should be the first session rule

session    required     pam_selinux.so close

session    required     pam_loginuid.so

# pam_selinux.so open should only be followed by sessions to be executed in
the user context

session    required     pam_selinux.so open env_params

session    optional     pam_keyinit.so force revoke

session    include      password-auth

*england-web-dev:/home/ansible # *cat /etc/pam.d/password-auth

#%PAM-1.0

# This file is auto-generated.

# User changes will be destroyed the next time authconfig is run.

auth        required      pam_env.so

auth        sufficient    pam_unix.so nullok try_first_pass

auth        requisite     pam_succeed_if.so uid >= 500 quiet

auth        required      pam_deny.so

account     required      pam_unix.so

account     sufficient    pam_localuser.so

account     sufficient    pam_succeed_if.so uid < 500 quiet

account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=

password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass
use_authtok

password    required      pam_deny.so

session     optional      pam_keyinit.so revoke

session     required      pam_limits.so

session     [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid

session     required      pam_unix.so

On Mon, Mar 23, 2020 at 1:14 AM Alexander Bokovoy 
wrote:
> On ma, 23 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> > I'm not getting logs on sssd while accessing ssh however I'm getting logs
> > in secure logs, it is looking for linux user
>
> How did you enroll this machine? What distribution does it run?
>
> Then you need to check your pam configuration for ssh server to see what
> is there. On RHEL/Fedora it is /etc/pam.d/sshd. If it has
>
> auth substack password-auth
> auth include postlogin
>
> then /etc/pam.d/password-auth defines what authentication is used.
>
> There should be pam_sss mentioned.
> For details see manual page for pam.d(5).
>
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

[Alexander Bokovoy]

On ma, 23 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> I enrolled my client using below command previously it was working for
> other old freeipa server with 3.0 version, Now I enrolled this client 3.0
> version with new IPA server with version 4.6.
>
> ipa-client-install --mkhomedir --server=ipa1.example.com --domain=example.com

So, what is the distribution and its version?

Your configuration below doesn't have any pam_sss mentioned, this seems
unlikely to be a proper ipa-client-install on RHEL/CentOS/Fedora
systems, even for very old versions.

Can you please provide /var/log/ipaclient-install.log?
> *england-web-dev:/home/ansible # *cat /etc/pam.d/password-auth
>
> #%PAM-1.0
> # This file is auto-generated.
> # User changes will be destroyed the next time authconfig is run.
>
> auth        required      pam_env.so
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        requisite     pam_succeed_if.so uid >= 500 quiet
> auth        required      pam_deny.so
>
> account     required      pam_unix.so
> account     sufficient    pam_localuser.so
> account     sufficient    pam_succeed_if.so uid < 500 quiet
> account     required      pam_permit.so
>
> password    requisite     pam_cracklib.so try_first_pass retry=3 type=
> password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
> password    required      pam_deny.so
>
> session     optional      pam_keyinit.so revoke
> session     required      pam_limits.so
> session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
> session     required      pam_unix.so

This configuration does not have pam_sss in it which means it is simply
not using any IPA integration and is not able to authenticate users from
IPA.

Do you also 'sss' in /etc/nsswitch.conf entries?
> On Mon, Mar 23, 2020 at 1:14 AM Alexander Bokovoy 
> wrote:
> > On ma, 23 maalis 2020, Faraz Younus via FreeIPA-users wrote:
> > > I'm not getting logs on sssd while accessing ssh however I'm getting logs
> > > in secure logs, it is looking for linux user
> >
> > How did you enroll this machine? What distribution does it run?
> >
> > Then you need to check your pam configuration for ssh server to see what
> > is there. On RHEL/Fedora it is /etc/pam.d/sshd. If it has
> >
> > auth substack password-auth
> > auth include postlogin
> >
> > then /etc/pam.d/password-auth defines what authentication is used.
> >
> > There should be pam_sss mentioned.
> > For details see manual page for pam.d(5).
> >
> > / Alexander Bokovoy
> > Sr. Principal Software Engineer
> > Security / Identity Management Engineering
> > Red Hat Limited, Finland