Authentication (was Re: Great SWT Program)

On Dec 5, 5:11 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
In article <slrnflau0s.5i7....@xxxxxxxxxxxxxxxxxxxxxxxx>,
Andreas Leitgeb <a...@xxxxxxxx> wrote:

blmblm myrealbox.com <blm...@xxxxxxxxxxxxx> wrote:
Huh. I have an account on a machine that claims to be running
SunOS 5.8, which is Solaris (as I understand it) but not very
recent, and when I log in remotely with ssh,
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.

Very few servers use keyboard-interactive, in my experience; the
distro's stock configuration is often publickey,password. You can see
what methods your server allows (and much more) using 'ssh -v
username@host' and reading the debug output. On my machine at home, I
get:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/ojacobson/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).

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... :)

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

Relevant Pages

  • [SLE] Slow SSH login
    ... A> ssh B ... second delay no matter the authentication mechanism ... debug1: Authentication succeeded. ...
    (SuSE)
  • Login and ssh hang after password, before logging
    ... I have a nice new server, ... I was able to log in through the console and ssh fine ... results for password authentication and public-key authentication: ... debug1: read PEM private key done: type DSA ...
    (alt.linux)
  • LDAP Authentication via SSH
    ... authenticate via SSH to the LDAP server. ... debug1: Connecting to ldapclient.domain port 22. ... debug1: Next authentication method: keyboard-interactive ... # rlogin service (explicit because of pam_rhost_auth) ...
    (SunManagers)
  • SSH and LDAP
    ... We are installing an LDAP server for AIX and Solaris login ... "Too many authentication failures for " ... debug1: ssh_rsa_verify: signature correct ... debug3: preferred publickey,keyboard-interactive,password ...
    (comp.unix.aix)
  • LDAP and OpenSSH
    ... We are installing an LDAP server for AIX and Solaris login ... "Too many authentication failures for " ... debug1: ssh_rsa_verify: signature correct ... debug3: preferred publickey,keyboard-interactive,password ...
    (comp.security.ssh)