OpenSSH public key problem with Solaris 10

[Douglas E. Engert]

Darren Tucker wrote:

> On Fri, Jun 30, 2006 at 10:55:35AM -0500, Douglas E. Engert wrote:
> 
>>The Solaris 10 sshd has a nice PAM feature, in that it
>>will use a different pam service name  depending on the auth used.
>>For example: sshd-password, sshd-kdbint, sshd-pubkey, sshd-gssapi ...
>>The sshd_config can override these too.
>>
>>Thus you can skip the pam_krb5 for pubkey.
>>
>>OpenSSH might want to consider a similiar feature.
> 
> 
> I've seen that mentioned earlier (here or elsewhere) and it's also
> been listed in OpenSSH's TODO file for a long time (originally from
> Solar Designer).  It's not a bad idea, but the catch is that it would
> require either another compile or run time button and/or a migration
> hassle.
> 
> This is because there's no (sane) way to tell which PAM services are
> available: pam_get_item(handle, PAM_SERVICE, [...]) will return the
> service name you asked for, not the service name that you actually got
> (which makes it kinda useless, since you already know what you asked
> for).
> 
> Thus there is no way to, eg, try "sshd-kbdint" and fall back to "sshd"
> if it's not available (in the first instance you'll get the "other"
> service but have no way of knowing it).

Yes that's to bad and sounds like a bug. But even without this change how
do you know now that "other" is not being used? i.e. the admin did not setup
a "sshd" pam entry.


Even Solaris 10 is misleading as the man page for sshd_config
says you can change these from the default of sshd:

PamSvcForNone
PamSvcForPassword
PamSvcForKbdInt
PamSvcForOther

But the man page for sshd says it uses sshd-none, sshd-password, sshd-kdbint,
sshd-pubkey, sshd-hostbased, sshd-gssapi which it appears to do. (I have
only tried the sshd-kbdint and sshd-gssapi.)

> 
> This is the case on at least Sun and LinuxPAM implementations.  You can
> confirm this behaviour on other platforms with my PAM test tool:
> http://www.zip.com.au/~dtucker/patches/#pamtest
> 
> $ sudo ./pam-test-harness -s some-random-service
> [...]
> pam_start(some-random-service, (NULL), &conv, &pamh) = 0 (Success)
> pam_get_item(pamh, PAM_SERVICE, ...) = 0 (Success)
>     PAM_SERVICE = some-random-service (unchanged)
> 

So could OpenSSH have the sshd_config options set to sshd? This would then
allow the admin the flexability and responsibility to update both sshd_config
and pam.conf to match.

If falling back to "other" is a problem, then maybe "other" should
always fail or at least log that it is being used when not expected.

Using the bug you discribe above, A pam_other_fail.so called only from "other"
could use pam_get_item, and if did not return "other" it could fail. This would
then force the admin to explicitly setup pam for each service.


-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444