Pass-through authentication?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I am using the latest version of OpenSSH.

Is there an architecturally correct way (if at all) to bypass the
authentication layer in SSH?  For example, I have a shell that does
authentication and I would like ssh to simply secure the connection
(key-exchange) and then drop the connection into the shell.  The shell
then does authentication and will either allow further access or close
the session (and hence the connection) based on its own authentication

I was thinking of using "none" as the authentication method since it
gives me the functionality in all its simplicity and RFC 4252 seems to
corroborate that.  There are a couple of issues with this though:

1. After the transport connection is setup, it seems like all clients
send SSH_MSG_USERAUTH_REQUEST and usually include a username along with
this message.  In a lot of cases, the username is automatically
provided (e.g., running ssh on Linux) and in these cases, the
authentication layer can be hacked to simply authenticate no matter
what and drop into the authentication shell, so this works well.  Now,
there are some clients which prompt for the username and then use it to
do the authentication.  This is kind of an issue since there are two
separate Logins (one by the client for USERAUTH and the other by the
authentication shell) and I'd like to avoid this if possible.

2. Do all clients support the "none" method?  I know that the server
must, but what about the clients?  If all of them don't then it becomes
necessary to support other authentication mechanisms as well.

Any comments, suggestions appreciated,


Re: Pass-through authentication? writes:
Quoted text here. Click to load it

In SSH-2 (which you appear to be limiting your attention to), a client
can theoretically ask for the "ssh-connection" service directly, rather
than (as is more common) asking for "ssh-userauth" and getting at
"ssh-connection" through that.

The development snapshots of PuTTY support this: either as a fallback if
"ssh-userauth" is refused by the server, or by explicit configuration:
< .
However, I don't know that any existing servers react sensibly to it.

There's no such dodge for SSH-1.

Quoted text here. Click to load it

In principle, your server could refuse the "ssh-userauth" service, which
would mean that an alert client would realise it didn't need a login
name, but iit's quite likely that many clients will (a) be hardcoded to
assume that a login name is always required, and/or (b) react badly
(e.g. kill the connection entirely).
(In fact, PSFTP is still guilty of (a), oops.)

Otherwise, I can't see a way around the spurious prompt without changing
the client's configuration (to add a dummy username, or if a "bypass
userauth" feature exists, enable it).

Quoted text here. Click to load it

Since it's traditional for clients to find out what authentication
methods are available by first sending a "none" request, it's quite
likely to work. (I suppose it's possible that some clients might fall
over in surprise if they receive a SSH_MSG_USERAUTH_SUCCESS in response
to their "none", but they shouldn't.)

Re: Pass-through authentication?


Thanks for your comments.  Looks like I may have to make some changes
to the authentication shell in order to make this work properly, for
example by providing the username when invoking the shell.  This would
remove the duplicate login issue, so this seems like a way around it.

On using the "none" method for authentication, I have tried a few ssh
clients and they all seem to work fine.  So, if there is an ssh client
out there that doesn't work, we'll flag it.

I was also wondering if there are any other methods that might be more
politically correct for achieving this.  For example, could the
"hosbased" method be made to authenticate all connections without the
client requiring a key pair?  I think some clients may not even
initiate a connection if they are not configured with a host key pair.


Re: Pass-through authentication?

Quoted text here. Click to load it

I think answering "yes" to the none method is a perfectly correct thing to
do; in fact *the* right thing to do.  From the userauth RFC:

5.2.  The "none" Authentication Request

   A client may request a list of authentication 'method name' values
   that may continue by using the "none" authentication 'method name'.

   If no authentication is needed for the user, the server MUST return
   SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return
   SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of methods
   that may continue in its 'authentications that can continue' value.

   This 'method name' MUST NOT be listed as supported by the server.

Quoted text here. Click to load it

No; a hostbased request is signed with the client's hostkey.

  Richard Silverman

Site Timeline