Bug 730851

You can't switch to root even if you type in the correct ssh passphrase?

Is your passphrase empty?

My root user does not have a passphrase.

More importantly, the module is listed as pam _optional_ - which means it's success or failure is not binding.

I can't reproduce this.

Also, there were no major changes in pam_ssh between 11.4 and 12.1.

Could you try to downgrade pam or pam_ssh to 11.4 version to see if it works correctly with them?

I was able to reproduce it easily.

Step 1. Test without ssh:

pam-config --delete --ssh

As normal user, run 'su -'. Note that it doesn't ask for an SSH passphrase.

Step 2. Test with ssh:

pam-config --add --ssh 

As normal user, run 'su -'. Note that it /does/ ask you for an SSH passphrase (after your normal password).  Hint enter.  Note that it says 'incorrect password'. 


Example of Step 2's 'su -' output:

jnelson@worklaptop:~> su -
Password: 
SSH passphrase: 
su: incorrect password
jnelson@worklaptop:~>



NOTE: The root user *DOES NOT* have a $HOME/.ssh directory. Perhaps that makes a difference.

Indeed, now I can reproduce it.
Thanks.

This looks like it's the expected behaviour.

The /etc/pam.d/su-l includes /etc/pam.d/common-auth,
which on my machine looks something like this:

auth	required	pam_env.so	
auth	optional	pam_gnome_keyring.so
auth	optional	pam_ssh.so debug
auth	sufficient	pam_unix2.so debug
auth	sufficient	pam_krb5.so	use_first_pass 
auth	required	pam_deny.so

What happens is that pam_gnome_keyring asks for a password.
(The first "Password:" prompt)

Then pam_ssh asks for SSH key password
(prompting with "SSH passphrase:")

Next is pam_unix2, which by default uses the password from the previous module,
in this case from pam_ssh.
So it tries to authenticate with the ssh passphrase.
And fails.

So if you enter your unix password for the second prompt (SSH passphrase:), it lets you through.

Correction: The first prompt comes from su itself, which passes the password to the pam.

According to this:
http://oss.sgi.com/LDP/HOWTO/User-Authentication-HOWTO/x101.html

optional means just that -- whether it succeeds or fails is only important *if* it's the only module listed for it's type (which, in this case, it isn't).

Yes, but I think that the overall authentication failure isn't caused by pam_ssh failure, but rather by the pam_deny, which is reached in the end.

That's because previous modules pam_unix2 and pam_krb5 (in my case) fail with the inherited ssh-passphrase as a password.

Let's ask pam maintainer.

Michael,
could you comment on what is happening here?

optional really only execute the module and let the pam stack continue with 
the next module independent what the result is.

sufficient means, if the module return PAM_SUCCESS, that the stack is finished with success. No other module listed behind is executed.
On error it continues with the next in the stack, but it does not store the error.

This is the reason, why the last module is pam_deny, which always return an error. It is "required", which means, that this store the error for the whole stack.

It maybe that the configuration with pam_ssh is not correct.
But we cannot put it after the real authentication modules, because they are sufficient.

The question is, for what is pam_ssh good for?

Is it really an authentication module (I think not), than it can be "sufficient" too.

Is it only there to call ssh-agent with the password?
Than it may require the same password as the real authentication password and should be configured only in "session", not in "auth".

Using pam for this kind of configuration is not really for what pam was made for.

Maybe you need an individual configuration matching your special usecase.

(In reply to comment #12)
> The question is, for what is pam_ssh good for?
> 
> Is it really an authentication module (I think not), than it can be
> "sufficient" too.
> 
A lot of people use it for single sign-on like this.

> It maybe that the configuration with pam_ssh is not correct.
> But we cannot put it after the real authentication modules, because they are
> sufficient.
> 
So I guess we can say it's a bug in pam-config (this configuration was created with pam-config --add --ssh),
which adds pam_ssh as optional to both common-auth and common-session.
For auth stack, it should be either sufficient or not there at all.

Anyway, there's nothing to be fixed on pam_ssh side here.
It's more a configuration issue.

Michael, unless you want to do something with pam-config about this,
I'll close this.

*** Bug 772479 has been marked as a duplicate of this bug. ***

Thorsten,

Current pam-config setup adds pam_ssh.so as optional to auth group.
So it has to be listed above sufficient modules.
The ssh passphrase gets passed to next modules in stack,
however if the passphrase is different from the unix password,
the authentication fails.
(pam_unix2 takes by default the password from a previous module,
as does pam_krb5 in our current setup)

Therefore I would suggest changing optional to sufficient.
If someone wants to enable pam_ssh, he likely wants to use
it directly to authenticate
(despite it probably not being really a authenticaton module as Michael pointed out)

I'll submit the change if you like it.
Or do you prefer any other solution?

(In reply to comment #16)

> I'll submit the change if you like it.

Fine with me.

This is an autogenerated message for OBS integration:
This bug (730851) was mentioned in
https://build.opensuse.org/request/show/131586 Factory / pam-config

Fixed in Factory.