-
Notifications
You must be signed in to change notification settings - Fork 803
-
I am testing different authentication method to our linux servers.
I noticed that we could use kerberos TGT which is pretty neat.
Our company is also transitioning to a secondary AD elevated account for administrative purposes.
On my company workstation ( Windows 11 Enterprise - 23H2 - 22631.5909 with OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 ) with my personal AD account I am able to ssh into our linux server with a TGT I am assuming is from the workstation itself when I first sign in . Is this true?
> klist
Credentials cache C:\Users\XID\krb5cc_XID not found.
> ssh -K servername
> # im in server shell here
log from sshd
Oct 13 08:33:55 servername sshd[2917227]: Accepted gssapi-with-mic for domain\\xid from x.x.x.x port 52075 ssh2: xid@DOMAIN.COM
Now when I attempt to generate a TGT with my secondary AD (XIDA) account I am not able to ssh into the server that easily.
> kinit xida
Password for xida@DOMAIN.COM:
New ticket is stored in cache file C:\Users\XID\krb5cc_XID
> klist
Credentials cache: C:\Users\XID\krb5cc_XID
Default principal: xida@DOMAIN.COM, 1 entry found.
[1] Service Principal: krbtgt/DOMAIN.COM@DOMAIN.COM
Valid starting: Oct 13, 2025 08:45:45
Expires: Oct 13, 2025 18:45:45
Now doing a simple ssh using the secondary account
> ssh -Kv -l xida servername
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: sspi delegation was requested but not fulfilled
debug1: Delegating credentials
debug1: sspi delegation was requested but not fulfilled
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: publickey
When i look at the debug logs KRB5_TRACE=/tmp/ssh-krb5trace /sbin/sshd -d i see it is trying to use the regular XID principal. Not the XIDA principal.
[2922318] 1760359639.048649: Decrypted AP-REQ with server principal host/servername@DOMAIN.COM: aes256-cts/E91A
[2922318] 1760359639.048650: AP-REQ ticket: XID@DOMAIN.COM -> host/servername@DOMAIN.COM, session key aes256-cts/7989
[2922318] 1760359639.048651: Negotiated enctype based on authenticator: aes256-cts
[2922318] 1760359639.048652: Authenticator contains subkey: aes256-cts/F89E
[2922318] 1760359639.048653: Creating AP-REP, time 1760359639.405, subkey aes256-cts/EC7B, seqnum 852788356
I also tried setting the KRB5CCNAME environment variable but got the same result above:
> $env:KRB5CCNAME = "C:\Users\XID\krb5cc_XID"
The ONLY way i was able to auth with GSSAPIAuth using the secondary account was using runas
> runas /user:domain\xida "ssh -Kv servername"
Enter the password for domain\xida:
Attempting to start ssh -Kv severname as user "domain\xida" ...
sshd log
Oct 13 08:54:00 servername sshd[2925037]: Authorized to domain\\xida, krb5 principal XIDA@DOMAIN.COM (ssh_gssapi_krb5_cmdok)
Why is that?
How can i have my local ssh client use the principal from the TGT i generated?
What could i be missing?
Any input is much appreciated!
Best,
Dave
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment
-
When i try to ssh from a linux (rhel) server I am able to use different TGT for a different user principal
[xid@servername Development: /home/xid] whoami
xid
[xid@servername Development: /home/xid] klist
klist: Credentials cache keyring 'persistent:1000:1000' not found
[xid@servername Development: /home/xid] ssh -o StrictHostKeyChecking=no servername -v -l xida exit &>/dev/stdout | grep Authen
debug1: Authenticating to servername:22 as 'xida'
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
(xida@servername) Password:
The above fails, as expected.
Then i create a ticket for the xida account and I can access with GSSAPI.
[xid@servername Development: /home/xid] kinit xida
Password for xida@DOMAIN.COM:
[xid@servername Development: /home/xid] klist -f
Ticket cache: KEYRING:persistent:1000:1000
Default principal: xida@DOMAIN.COM
Valid starting Expires Service principal
10/13/2025 14:44:06 10/14/2025 00:44:06 krbtgt/DOMAIN.COM@DOMAIN.COM
renew until 10/20/2025 14:44:05, Flags: FRIA
[xid@servername Development: /home/xid] ssh -o StrictHostKeyChecking=no servername -v -l xida exit &>/dev/stdout | grep Authen
debug1: Authenticating to servername:22 as 'xida'
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
Authenticated to servername ([x.x.x.x]:22) using "gssapi-with-mic".
So at least it seems that ssh client in linux respects the local TGT that was created while in windows the ssh client defaults to the xid TGT which is stored somewhere in the workstation.
How can something similar be done in windows?
Beta Was this translation helpful? Give feedback.