https://bugzilla.mindrot.org/show_bug.cgi?id=1472
Summary: Authentication options not cleared in privileged
process
Classification: Unclassified
Product: Portable OpenSSH
Version: -current
Platform: All
URL: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug
/161047
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: sshd
AssignedTo: bitbucket@mindrot.org
ReportedBy: cjwatson@debian.org
Created an attachment (id=1509)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=1509)
call auth_clear_options in privileged process
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/161047 reports a
problem with forced commands when used with public-key authentication
but expecting password authentication also to work without the forced
command. Briefly, it may be reproduced on a single machine as follows:
1) Move all but one of your keys out of the way in ~/.ssh so that the
client won't find them.
2) Apply a forced command to this key in ~/.ssh/authorized_keys;
command="echo hello" will do.
3) If you are running ssh-agent, remove all identities from it with
'ssh-add -D'.
4) Connect to localhost. When prompted for the public key passphrase,
press Enter; then enter your normal password when prompted to do so.
Observe that "hello" is printed and no shell is given.
I believe that the problem here is that, if authentication fails after
calling auth_rsa_key_allowed or user_key_allowed in the privileged
process, authentication options are only cleared in the monitor rather
than in the privileged process. The obvious fix seems to be to clear
them in both processes. This is implemented by the attached patch.
This is only reproducible if the last key offered by the client is the
one with the forced command, since auth_parse_options calls
auth_clear_options on entry and that's called in the privileged
process.
--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
Summary: Authentication options not cleared in privileged
process
Classification: Unclassified
Product: Portable OpenSSH
Version: -current
Platform: All
URL: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug
/161047
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: sshd
AssignedTo: bitbucket@mindrot.org
ReportedBy: cjwatson@debian.org
Created an attachment (id=1509)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=1509)
call auth_clear_options in privileged process
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/161047 reports a
problem with forced commands when used with public-key authentication
but expecting password authentication also to work without the forced
command. Briefly, it may be reproduced on a single machine as follows:
1) Move all but one of your keys out of the way in ~/.ssh so that the
client won't find them.
2) Apply a forced command to this key in ~/.ssh/authorized_keys;
command="echo hello" will do.
3) If you are running ssh-agent, remove all identities from it with
'ssh-add -D'.
4) Connect to localhost. When prompted for the public key passphrase,
press Enter; then enter your normal password when prompted to do so.
Observe that "hello" is printed and no shell is given.
I believe that the problem here is that, if authentication fails after
calling auth_rsa_key_allowed or user_key_allowed in the privileged
process, authentication options are only cleared in the monitor rather
than in the privileged process. The obvious fix seems to be to clear
them in both processes. This is implemented by the attached patch.
This is only reproducible if the last key offered by the client is the
one with the forced command, since auth_parse_options calls
auth_clear_options on entry and that's called in the privileged
process.
--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs