configura o OpenSSH para preferir a autenticação de chave pública, voltar para a senha de senha vazia

Question

Eu gostaria de configurar o OpenSSH 6.2p2 para uma conta de serviço (vamos chamar de "serviceacct") com uma senha vazia que faz o seguinte:

1. Primeiro, tente a autenticação de chave pública; se tiver êxito, execute o comando forçado especificado no arquivo authorized_keys.
2. Volte para a autenticação de senha vazia e execute o comando forçado especificado em algum outro lugar.

Essencialmente, isso daria um comportamento para usuários conhecidos e outro comportamento para usuários anônimos.

Em um mundo ideal, essas configurações no sshd_config fazem o que eu quero:

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

Mas estou com alguns problemas:

1. ForceCommand /my/program substitui o comando forçado que está configurado no arquivo authorized_keys.
2. O uso de uma senha vazia parece ter precedência sobre a autenticação de chave pública.

Existe alguma maneira de contornar esses dois problemas, a não ser modificar o servidor OpenSSH? Uma solução óbvia que posso imaginar é usar apenas duas contas de serviço - uma para usuários conhecidos que usam apenas autenticação de chave pública e outra para usuários anônimos que usam apenas a autenticação de senha vazia. Estou tentando evitar ter duas contas de usuário, se possível.

Editar - Por que eu gostaria desse comportamento

Estou construindo um serviço que hospeda vários tipos de repositórios de sistemas de controle de versão (Subversion, Git e Mercurial). Pense no GitHub ou no Bitbucket, mas hospedado localmente (essa é a chave, já que alguns de nossos trabalhos não podem sair do nosso site). Indiscutivelmente, o método de acesso mais simples, comum a cada um desses sistemas de controle de versão, é o SSH.

Cada repositório tem regras de acesso configuráveis para usuários conhecidos e anônimos. Gostaria de poder suportar usuários conhecidos e anônimos usando a mesma URL para qualquer um dos sistemas de controle de versão. Como o usuário que hospeda o repositório faz parte do URL (por exemplo, ssh://user@host/path ), ter dois usuários diferentes - um para usuários conhecidos e um para usuários anônimos - exigiria dois URLs diferentes.

Há um detalhe técnico que devo esclarecer: na verdade estou usando a diretiva AuthorizedKeysCommand em sshd_config, que instrui o sshd a usar a saída de um programa externo em vez de ler o arquivo ~ / .ssh / authorized_keys.