Pass-through authentication? - SSH

This is a discussion on Pass-through authentication? - SSH ; Folks, 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Pass-through authentication?

  1. Pass-through authentication?

    Folks,

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

    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,

    Galhod


  2. Re: Pass-through authentication?

    oldhag@gmail.com writes:
    >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.

    [...]

    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.

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


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

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


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

  3. Re: Pass-through authentication?

    Jacob,

    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.

    Galhod


  4. Re: Pass-through authentication?

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


    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.

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


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

    --
    Richard Silverman
    res@qoxp.net


+ Reply to Thread