Bug 7372 - Smart card authentication doesn't work when SSH banner is used
Summary: Smart card authentication doesn't work when SSH banner is used
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Smart card (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.19.0
Assignee: Alexander Zeijlon
URL:
Keywords: relnotes, samuel_tester
Depends on:
Blocks:
 
Reported: 2019-08-28 11:10 CEST by Samuel Mannehed
Modified: 2025-05-15 16:17 CEST (History)
5 users (show)

See Also:
Acceptance Criteria:
MUST: * Users should be able to authenticate with a smart card on a system that uses SSH-banner. EXTRA: * Users should be able to abort the connection if they are deterred by the SSH-banner message.


Attachments

Description Samuel Mannehed cendio 2019-08-28 11:10:00 CEST
When banner is enabled on the server, authenticating with a smart card in the ThinLinc client won't work.

We never get the PIN prompt for the smart card and only see the banner message. When closing the banner message the login process is cancelled as if we never started it in the first place. Happens when using the client on all client platforms; Linux, Windows and macOS.

Looking at the flow of things in tlclient.log it seems like things are happening in a sort of wierd order:

2019-08-28T11:05:06: SSH pid is 28860
2019-08-28T11:05:06: ssh[E]: CONFIRM HOST KEY: localhost ::1 22 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBE29XA4X2q6vsUwOsmJa/XJwe5IyN6mKxfOyIXDYdEwq7LXPkZgqT0KawgODygKB7zr7RXT8cl7+7GnWTw+LRgM=
2019-08-28T11:05:06: Host key previously known.
2019-08-28T11:05:06: ssh[E]: NEXT AUTHMETHOD: none
2019-08-28T11:05:06: ssh[E]: BANNER: banner\ntest\n
2019-08-28T11:05:06: Unable to open card session
2019-08-28T11:05:06: Querying user for passphrase...
2019-08-28T11:05:06: Signature operation aborted by user
2019-08-28T11:05:07: Process 28860 exited with code 255

It seems like when tlclient is handling the banner, ssh keeps on going and sending other stuff on the line. Our banner code is probably written with some incorrect assumptions.
Comment 3 Pierre Ossman cendio 2024-07-25 15:52:35 CEST
The fix should hopefully be as simple as getting the ssh client to wait for tlclient to finish showing the banner. E.g. turning it in to a prompt instead of just a message.
Comment 4 Jim Nicolini 2024-12-05 17:17:06 CET
We are facing this same issue and have customer requirement to display the banner, is there any workaround for this while we can still display the banner?
Comment 5 Jim Nicolini 2024-12-05 17:17:23 CET
We are facing this same issue and have customer requirement to display the banner, is there any workaround for this while we can still display the banner?
Comment 12 Alexander Zeijlon cendio 2025-05-14 08:42:47 CEST
> MUST:
> * Users should be able to authenticate with a smart card on a system that
>   uses SSH-banner.
They can now.
> EXTRA:
> * Users should be able to abort the connection if they are deterred by the
>   SSH-banner message.
This is outside the scope of this bug. See bug 8585.
Comment 14 Samuel Mannehed cendio 2025-05-15 16:17:51 CEST
Looks good. First I verified that I could see the issue with 4.18.0, it just gave up after accepting the banner - not allowing the user to log in.

Using client build 3949 on Fedora 42, and build 3950 on Windows 11, I tested the following:

* Login to a single-server setup
  - without a banner using password auth
  - without a banner using smart card auth
  - with a banner using password auth
  - with a banner using smart card auth
* Login to a cluster with one agent and one master
  - with a banner only on master using password auth
  - with a banner only on master using smart card auth
  - with a banner on both master and agent using password auth
  - with a banner on both master and agent using smart card auth

All worked as expected!

I also checked the code and release notes, both good.

Note You need to log in before you can comment on or make changes to this bug.