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.
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.
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?
> 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.
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.
