Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to configure OpenSSH 6.2p2 for a service account (we'll call it "serviceacct") with an empty password which does the following:

  1. First try public key authentication; if it succeeds then run the forced command specified in the authorized_keys file.
  2. Fall back to empty password authentication and run the forced command specified somewhere else.

Essentially this would give one behavior for known users and another behavior for anonymous users.

In an ideal world, these settings in sshd_config would do what I want:

PubkeyAuthentication yes
PasswordAuthentication yes
Match User serviceacct
  PermitEmptyPasswords yes
  ForceCommand /my/program

But I'm running into a couple of problems:

  1. ForceCommand /my/program overrides the forced command that is set in the authorized_keys file.
  2. Using an empty password seems to take precedence over public key authentication.

Is there any way around these two problems, short of modifying the OpenSSH server? One obvious workaround that I can think of is to just use two service accounts - one for known users that only uses public key authentication, and another for anonymous users that only uses empty password authentication. I'm trying to avoid having two user accounts if possible.

Edit - Why I'd like this behavior

I'm building a service which hosts various types of version control system repositories (Subversion, Git, and Mercurial). Think GitHub or Bitbucket, but locally hosted (this is the key, since some of our work cannot leave our site). Arguably, the simplest access method which is common to each of these version control systems is SSH.

Each repository has configurable access rules for known and anonymous users. I'd like to be able to support both known and anonymous users using the same URL for any of the version control systems. Since the user that hosts the repository is part of the URL (e.g. ssh://user@host/path), having two different users - one for known users and one for anonymous users - would require two different URLs.

There is one technicality that I should clarify: I'm actually using the AuthorizedKeysCommand directive in sshd_config, which instructs sshd use the output of an external program instead of reading the ~/.ssh/authorized_keys file.

share|improve this question
I'm struggling to find a reason why you would possibly want to do this. Can you explain your actual use case (i.e. tell us something more than "I want this behavior" - like why: What practical problem are you trying to solve by doing this)? – voretaq7 Oct 3 '13 at 18:50
Did you ever figure this out? I'm hoping to do the same thing. – Mike Boers May 26 at 21:46
This is an excellent question, one that I am struggling to find an answer to. I can see why it may seem crazy (allowing a user to override a centrally-defined force command in their own authorized_keys file) however, for a service account concept it makes total sense. I want to allow new users connect without a password where a registration script would fire and demand their public key. It's a 3-year old question with no answers - I fear the answer is that it cannot be done. – starfry Jul 21 at 14:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.