debathena-ssh-server-config breaks ssh logins without a keytab

[quentin]

If you install debathena-ssh-server-config without having a keytab, ssh logins become impossible:

OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/quentin/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to j-l [18.181.0.240] port 22.
debug1: Connection established.
debug1: identity file /Users/quentin/.ssh/identity type -1
debug1: identity file /Users/quentin/.ssh/id_rsa type -1
debug1: identity file /Users/quentin/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: Doing group exchange

debug1: Calling gss_init_sec_context
Connection closed by 18.181.0.240

I discovered this when I installed the package and then went to scp the keytab into place...

[broder]

debathena-ssh-server-config is pulled in by debathena-login, so this concerns be a little bit. Is there any way to work around this on the server-side other than turning off gss-keyex by default? Presumably on the client you could do ssh with -o GSSAPIKeyExchange=no?

[meeg]

Yes, -o GSSAPIKeyExchange=no works, as does connecting from a client without Kerberos tickets.

I see this problem with one server but not the other, even though both have the current debathena-ssh-server-config and no keytab - both are Debian lenny with debathena-workstation. The server that fails has the same ssh -v output as quentin's; the other gives:

OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to simpi [18.248.3.89] port 22.
debug1: Connection established.
debug1: identity file /mit/meeg/.ssh/identity type -1
debug1: identity file /mit/meeg/.ssh/id_rsa type -1
debug1: identity file /mit/meeg/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5
debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'simpi' is known and matches the RSA host key.
debug1: Found key in /mit/meeg/.ssh/known_hosts:44
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Trying private key: /mit/meeg/.ssh/identity
debug1: Trying private key: /mit/meeg/.ssh/id_rsa
debug1: Trying private key: /mit/meeg/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password: 

[broder]

I suspect that this is only failing when a Kerberos principal exists for the hostname but isn't installed. If the principal doesn't exist, you get the "Unspecified GSS failure".

[geofft]

Hmm. What if we modify the sshd initscript to test that /etc/krb5.keytab exists, and if not

• print a warning (you want a keytab anyway for multiple reasons)
• add '-o GSSAPIKeyExchange=no' to SSHD_OPTS

?

[jdreed]

alexp got bitten by this today. I like geofft's suggestion -- any reason not to proceed with this?

[broder]

Can we do this by hacking /etc/default/sshd or whatever instead of the initscript?

[jdreed]

Committed in r24787. Unless I hear convincing evidence that this is a bad idea, I'll build it later today.

This has a slight behavior change in that if you want GSSAPI, you have to restart sshd after dropping the keytab in place. I don't think we need to care, if it's documented in Hermes (and I'll document it once it's built).

[geofft]

LGTM, built and uploaded to proposed. (Note that you didn't print a warning, but meh. We can tweak it later.)

Discussion elsewhere on zephyr points out that other approaches include

• the client noticing early that it can't get a host/ keytab and dropping GSSAPIKeyExchange from the keyex types it wants to do
• the server checking for the keytab every time it gets a connection

and it might be worth sending one of these patches to upstream (Debian).

[geofft]

Replying to geofft:

LGTM, built and uploaded to proposed. (Note that you didn't print a warning, but meh. We can tweak it later.)

Uploaded to production.

Discussion elsewhere on zephyr points out that other approaches include

• the client noticing early that it can't get a host/ keytab and dropping GSSAPIKeyExchange from the keyex types it wants to do
• the server checking for the keytab every time it gets a connection

and it might be worth sending one of these patches to upstream (Debian).

Opened #653 about upstreaming this.