Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
Someone on comp.security.ssh said their login banner did not appear when PuTTY prompted for a username, but did appear when they specified the username ahead of time in the configuration.
This looks worryingly plausible, in fact: the loop on
process_userpass_input() appears to be throwing away
all incoming SSH messages, presumably because I didn't expect to be
receiving any; and that includes USERAUTH_BANNER. I didn't notice
this before because I tested against OpenSSH, which appears to delay
sending the banner until after the first (usually null)
USERAUTH_REQUEST. However, the poster was using WinSSHD, which sends
the banner as soon as the userauth protocol commences (which seems a
lot more sensible in retrospect!).
So in order to fix this in PuTTY I would have to spot USERAUTH_BANNER during username input, and respond to it by doing something thoroughly unpleasant, such as erasing the username input line from the terminal, printing the banner, and redisplaying the username input line after that. This is nasty, but it would have the nice feature that if the banner was sent immediately, it would be displayed before the user finished entering their username.
I've labelled this bug "tricky" because I'm not sure what to do about Plink. Plink will call ssh_get_line and ignore ssh.c's own username/password input function, which means that on the one hand the banner won't be dropped on the floor in the current version, but on the other hand it would be hard to display it ahead of the username prompt in the fixed version.
If only the working group had listened to my suggestion of having a ping message I could send during userauth and expect a reply. Then I could send the ping, get a reply back, and if the banner had been sent immediately on commencement of userauth then it would appear before the ping response, and so I'd know whether there was a banner to be displayed before beginning username input. Bah.
An alternative solution that would also work with Plink would be to collect all banner messages seen while the user was typing a username, and spit them out immediately afterward. The user wouldn't of course see the banner before they'd entered a username, but the protocol design is such that that can't be guaranteed anyway; and at least the banner wouldn't be dropped on the floor, which might be important for things like legal notices.
Update: this should now be fixed (using the "alternative solution" above). Our original correspondent (using the WinSSHD server) has confirmed the fix.
Audit trail for this bug.