ssh server forces a command when it should not

[mistotebe]

When logging in on my home server I find it impossible to maintain both publickey and passphrase authentication. This has started happening recently, so I suspect an update might be responsible.

Set-up:
The user is set up to accept both publickey and password authentication in this order (the usual set-up). The authorized hosts looks like this (basically to allow only access to the repository and nothing more):
command="svnserver -t --tunnel-user=user",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAA...Q==...

The password login is left unrestricted.

Symptoms:
When connecting and having the key in the ~/.ssh/ directory, the client sends a notification (?) to the server about the key and it is taken as though it should succeed:

OpenSSH_4.6p1 Debian-5build1, OpenSSL 0.9.8e 23 Feb 2007
...
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.6p1 Debian-5build1
debug1: match: OpenSSH_4.6p1 Debian-5build1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6p1 Debian-5build1
...
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/user/.ssh/identity
--> debug1: Offering public key: /home/user/.ssh/id_rsa
--> debug1: Remote: Forced command: svnserver -t --tunnel-user=user
debug1: Remote: Port forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 277
--> debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/user/.ssh/id_rsa':
debug1: Next authentication method: password
user@localhost's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = cs_CZ.UTF-8
...here the svnserver takes over

does anyone have a clue what to try?

[Mathias Gug (mathiaz)]

Thank you for taking the time to report this bug and trying to help make Ubuntu better. Could you check the permission on the ssh configuration files ? Could you run the client in a more verbose mode ? Could you check there was a package upgrade on the server or the client by looking in /var/log/dpkg.log ?

[mistotebe (mistotebe)]

All the files have their permissions set to 644, also checking the /var/log/dpkg.log* did come up with only two updates:
2007-10-06 both openssh server and client (1:4.6p1-5 -> 1:4.6p1-5build1)
2007-09-17 also both (1:4.3p2-8ubuntu1 -> 1:4.6p1-5)

So I did a little more research and it looks like it is limited to the Ubuntu sshclient version 1:4.6p1-5build1 (my and friend's machines) and affects every OpenSSH server I have tried to set up this way (Ubuntu 1:4.6p1-5build1, Debian 1:4.6p1-5 and IRIX64 6.5 OpenSSH_4.3) but not the other way around.
A possible reason why I could not reproduce this using the other distros/OS's sshclients might be a certain configuration of the ssh public key authentication we have set up in Ubuntu. Yet I don't know how to tell the difference.

I append an example debug3 information from Ubuntu->Ubuntu and Ubuntu->IRIX64 communication.

[mistotebe (mistotebe)]

Is there any additional info needed to confirm or reject this as a bug? Or if there is a way I could record all the communication so that it can be replayed somehow?

[Colin Watson (cjwatson)]

Reproduced in a gutsy chroot, though not on more recent versions. I wonder what's going on ... I'd like to leave this open until I figure it out.

[Colin Watson (cjwatson)]

Ah, no, I've reproduced it with current openssh as well. It only happens if you have precisely one key available, which is why I failed to reproduce it first time round.

[Colin Watson (cjwatson)]

Gotcha. The problem is that auth_clear_options is being called in the more-privileged process rather than in the network monitor. I'll put together a patch and send it upstream.

[Colin Watson (cjwatson)]

Fixed in OpenSSH 5.1p1, which I'll be aiming to get into Intrepid.

[Colin Watson (cjwatson)]

5.1p1 doesn't seem to be working right for this. Bumping back to in-progress while I think about this.

[Jacob Torrey (ranok)]

If I understand correctly your problem, I think you can use the ssh_config setting 'PreferredAuthentications while using ssh (ssh -o PreferredAuthentications password) to have it prefer the password over the key when you don't want it to use the key. Another option is to disable the ssh-agent bg process which caches your keys and will use them automatically, if this is disabled, then I'm pretty sure you'll need to explicitly set the key with the -i command.

Hope this helps.

[Thierry Carrez (ttx)]

@Colin, any update on this one ? Maybe set back to "Triaged" if you can't work on it right now ?

[Colin Watson (cjwatson)]

No update, and no time to look at it at the moment.

[Simon Déziel (sdeziel)]

From https://bugzilla.mindrot.org/show_bug.cgi?id=1472#c3:

  Mass update RESOLVED->CLOSED after release of openssh-5.1

And Ubuntu ships version >=5.1+ since at least Precise.