Using the default OpenSSH sshd package for Debian, is there any way to configure it to treat every username as being the same?

For instance, if someone connected with a random username (ie: 8LaRiQRd8Qjh), which did not exist as a Linux user, could I configure sshd to treat that as some consistent username like "testuser"?

I know how this could be done from the SSH client perspective, but I want the SSH server itself to accept any connection credentials (allowing my shell to handle authentication at that level).

Ideally what I want is a rule like "If there is no existing username, use this one instead". Even "always use this username" is okay, just less ideal.

It would be nice to find a simple solution using the default OpenSSH sshd service, rather than running my own sshd service.

  • I don't know the answer but you could grep the openssh sources for "Invalid user" to find the sources where this case is handled. Could be easy to add a hardcoded fallback username. – rudimeier Sep 1 '16 at 21:06
  • @rudimeier I haven't looked into it, but I'm less than optimistic it would be that simple. – GoldenNewby Sep 2 '16 at 0:04
  • 1
    You could do that with an LDAP server that returns account information for any user name. – Gilles 'SO- stop being evil' Sep 2 '16 at 7:03

I have no idea why you're trying to do this, and it seems like a terrible idea.

That said, for some reason the question got me hooked and I needed to find an answer.

The short answer is that this can't readily be done by simply configuring the available packages in debian.

If you want to do this you have to write two modules: one for NSS and one for PAM.

For the NSS module you will need to provide at least _getpwbynam_r. For the PAM module there's a lot more boilerplate.

This seems like a lot of work and not what you're looking for, but since you mention that you want to take care of authentication yourself, this is the way to do it.

A much simpler option (and probably a lot less secure) would be to use paramiko to setup a Python SSH server and customize/hook the authentication functions.

Fortunately, the guys at paramiko have already done most of the heavylifting in this demo server they have at their repo.

By replacing the check_auth_password or check_auth_publickey you can accept any user as valid. An example for password auth(*):

# pip install pam
import pam
MYUSER = 'testuser'

class Server(paramiko.ServerInterface):
    def check_auth_password(self, username, password):
        if password and pam.authenticate(username=MYUSER, password=password):
            return paramiko.AUTH_SUCCESSFUL
        return paramiko.AUTH_FAILED

Since this isn't StackOverflow I'm gonna stop there :)

This will create an ssh server that will ignore usernames for password authentication and will check the given password against testuser.

By default this server will prompt for a name and exit. You might want to replace that with a shell or your custom app.

I hardcoded the username, but you could just as easily get it from a config file or a database lookup or whatever.

You might also want to replace the host_key variable and perhaps the port number.

There's so many ways to shoot yourself in the foot with this. You should be very very very careful. This code is not production ready, review the whole thing. If you don't find anything wrong in it you didn't do a good review ;-).

*: this is simply replacing a function in the Server class in demo_server.py and adding some stuff at the top

  • I'm really just trying to get terminal users into my shell over SSH in the most convenient possible way. The shell doesn't do anything without a secure token being provided, so rather than prompt for useless credentials (user/pass), I figured I could make the username the token for simplicity. I suppose what I am really trying to do is have an SSHD service that I can customize (and maybe not even look at user/pass at all), and paramiko might be the best way to do that. Anyway, thanks for taking the time to answer. – GoldenNewby Sep 3 '16 at 0:07
  • @GoldenNewby glad I could be of use :-). I'd like to add that usernames are for identification purposes and thus are usually less "secured" than passwords, which are for authentication. For instance, usernames will show up in sshd logs and shell history. Passwords won't. If your tokens are used for authentication you want to treat them as passwords and not as usernames. With that said, take a look at Amazon's codecommit for a scheme similar to what you seem to be doing. – GnP Sep 3 '16 at 0:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.