Re: Authentication (was Re: Great SWT Program)
On Dec 7, 8:25 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
In article <e14bb93f-90ec-4681-a240-d8bc300c7...@d21g2000prf.googlegroups.com>,
Owen Jacobson <angrybald...@gmail.com> wrote:
On Dec 5, 5:11 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
In article <slrnflau0s.5i7....@gamma.logic.tuwien.ac.at>,
Andreas Leitgeb <a...@logic.at> wrote:
Come on, be fair to poor Twerpie. You know that ssh reads the
password locally, don't you? (eh, doesn't it?)
Good question. My first thought was "well, of course -- that
would make more sense, what was I thinking?" But thinking about
it more, I don't know -- when the ssh connection is up and running,
individual keystrokes are almost surely being relayed to the remote
system, aren't they? I'm not thinking, off the top of my head, how
to investigate further, without digging into source code somewhere.
The answer is, unsurprisingly, "both". The "publickey" and "password"
authentication mechanisms are challenge/response-based and handle the
password entirely on the client side. "keyboard-interactive"
authentication sets up an unauthenticated SSH connection and passes
keystrokes to a server-side authenticator.
I suppose it would be possible to set up ssh to authenticate using
login(1), but it would be perverse and extremely unusual to do so.
The more you know... :)
I can think of lots of ways to complete that sentence. Also :-)?
Eheh. Point taken. When I can let other people alone without the
dubious benefit of my store of trivia I think I will have learned
something from this thread. :)
It can indeed be interesting to examine output of "ssh -v".
Roger may have done the more appropriate experiment, using a
packet-sniffer to watch traffic on the connect (and observe that
apparently the password is *not* sent a character at a time --
but that might be system-dependent).
Configuration-dependent, anyways: the default modes do the entire auth
process in as few messages as possible, but ssh can be configured to
pass keystrokes as-is over the wire even during authentication.
When logging in through old telnet protocol, it may seem
differently,
Possible, though it seems like it also might be getting information
locally and sending it a line at a time, at least some of the time.
Most stock telnetd implementations delegate authentication to login(1)
on the server, which means that all the authentication data passes
over the wire in plain text before being interpreted by the server.
It's possible to use other authentication mechanisms with telnet, but
it's surprisingly rare and unlikely to become common at this point.
But the point here is not plain text versus encrypted -- at
least, I don't *think* it is -- but whether any editing (e.g.,
with backspace) is being done locally or remotely.
Two issues, really. That's one of them; the other was whether
prognosticating on login(1)'s behaviour was still relevant. For
remote access, I'd hold that it isn't.
Regarding backspace, I have never had a problem getting login(1) to
understand "backspace" and other terminal line buffering keystrokes
except when the terminal settings have been wrong -- at which point
backspace works nowhere and I have to remember to hit ^H if for some
reason I can't fix the terminal settings.
It occurs to me that one could probably connect to a remote
system with ssh and then attempt to run login from there, and
that *that* might be a more valid experiment. (If I try that,
with another Solaris system, it does appear that backspace "works"
when entering username and password. "Whatever"?)
It might; line buffering works pretty much the same way regardless of
where the lines are coming from, and login(1) is just another
program. The same experiment here (logging into an Ubuntu machine
from a Mac) produces a functional backspace key, both on the login:
line and the password: line.
-o