On Aug 23, 2022, at 6:15 AM, Jochen Bern <Jochen.Bern@xxxxxxxxx> wrote: > Hello everyone, I hope that it is acceptable to post an only *halfway* relevant request to the OpenSSH mailinglist ... > > These days, I was sent to do on-site maintenance on one of the Linux based appliances we make. The local admin led me to a rack and pointed to the KVM unit, with the screen showing the appliance's login prompt - no network access for my laptop, no physical access to the appliance (nowhere to be seen), please type your appliance's maintenance password into our hardware. Didn't much like that, and the surveillance camera a foot and a half above the keyboard didn't help any, either. > > So now I'm looking for a new (additional), replay-attack-safe authentication method to add to the product. Searched the web for "challenge-response" and "PAM" (so that it'll also work with sshd if needed), and so far, everything remotely acceptable seems to go back to three basic principles: > > -- Tokens like Yubikeys, which wouldn't have worked here thanks to no physical access. > > -- HOTP, which would lack the *single* strictly-(de|in)creasing counter to be replay safe (snarf response used on a "well worn" appliance, replay it on one with a "younger" counter, unless we start shipping appliances with *individual* secrets to boot). > > -- TOTP, which *would* be replay safe - if only our appliances weren't meant to sync against the customers' own NTP servers, so that their time can trivially be off or downright manipulated. > > What I'm looking for is a solution where the appliance would prompt with a *randomly chosen* challenge, random enough to make it unfeasible to try and wait for the challenge to repeat, the technician types the challenge into some device of his own (laptop, if need be), types the response displayed back into the appliance, and hey, nice camera you have there making an *entirely useless* recording. > > Would anyone here happen to know of such a beast? What you’re describing sounds like an RSA SecurID token with a keypad. Originally, these were hardware tokens with a small display and keypad. You’d enter the challenge presented by the server in via the keypad and the token would display a response to enter. There was also a time-based component to it, and explicit protection against using a response more than once. I don’t have much experience with the back-end part of this but I believe it required some kind of SecurID server that took care of initializing tokens. I’m not sure if that server also performed the challenge/response generation and validation, or if that could be done independently on the servers requesting the authentication once things were set up. These days, I think you can get either hardware or software tokens, the latter of which could run on a smart phone or laptop, if you didn’t want to have to carry around a separate physical token. These should work with standard SSH challenge/response authentication, once you have the SecurID software installed. -- Ron Frederick ronf@xxxxxxxxxxxxx _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
