[PATCH] Out-of-band challenge (OBC) authentication method
pgsery at swcp.com
Thu Feb 7 15:53:26 EST 2008
Daniel Kahn Gillmor wrote:
> On Wed 2008-02-06 00:47:08 -0500, paul wrote:
> Thereby proving the old adage that every program expands until it can
> send mail ;)
As they say, it seemed like a good idea at the time! I was unaware that
this was a common pitfall.
> This is a seriously neat idea, but i'm not sure why you'd want to
> limit it to sending mail, or assuming that the particular type of SMTP
> submission you've implemented here will work for everyone (port 25
> might be blocked, users might need TLS, SMTP authentication, etc).
Email seems like the most logical channel for this system. I'll adopt any
medium that proves better.
> Wouldn't it make more sense to make this a spawnable, unprivileged
> sub-process that accepts the challenge on stdin? For example, this
> could be specified as:
> ChallengeMethod mail -s 'Challenge from %h' %u
> ChallengeMethodUser nobody
> (meaning "for each challenge, as the user 'nobody', invoke
> /usr/bin/mail with these arguments")
> This would be instead of having to specify ChallengeSMTPServer.
That makes sense. I originally hard-wired an MTA/system call to do
(crudely) just what you describe. It then seemed better to fold the
function into sshd. I'll rewrite to learn the method to use from
sshd_config. This would indeed be cool since the method could be anything
including an ssh pipeline to some ssh-aware device that you carry around.
> If you'd like to remove the challenge-generating part from ssh as
> well, you could also implement it as a spawnable unprivileged
> subprocess which emits the challenge on stdout, which would probably
> be better. This would allow an external system to do things like
> buffer a single challenge for a limited duration (instead of issuing a
> dozen different challenges for a single user at once), or select its
> challenge from an alternate randomized string space.
> An administrator could also make use of the already-present Match
> functionality to avoid needing ChallengeUsers in the config file.
> This would remove the mail-sending and user-mapping functionality from
> ssh, which means it would be much more flexible for other users (who
> might prefer the OBC to be delievered to an authenticated RSS feed,
> posted to a bulletin board in steganographic form, etc).
> The patch would need to make sure that the spawned out-of-band
> challenge drops as much privileges as possible, and admins would need
> to make sure that their chosen ChallengeMethod is not dangerous or
> subject to format-string expansion in dangerous ways.
I'm all for making things simpler for my fellow admins. I'll start
thinking about how to do it. Btw, my contrib/gnome-ssh-askpass2.c patch
https://bugzilla.mindrot.org/show_bug.cgi?id=1393 does something similar
to what you describe. As you know, it generates a random string and writes
it to a fifo. A perl script reads the string and emails it to the user.
> It also occurs to me that if this is implemented, it could create a
> way for anonymous miscreants to cause a mailstorm for the targeted
> user simply by trying to log in as hir. I think this is true even in
> conjunction with MultiAuth, because it doesn't look like the MultiAuth
> patch allows the server to mandate an order in which the
> authentication flavors are run (client-chooses-auth seems to be built
> into the SSH protocol, if i'm reading my ssh -vvv output correctly).
> If those challenges are 10-penny-apiece text messages, this auth
> method could rack up quite a bill.
This must be addressed. I think Multiauth or
https://bugzilla.mindrot.org/show_bug.cgi?id=983 could be modified to
prevent this. For instance, stop overall authentication if pubkey fails.
> One last general thought: why not build this functionality as a PAM
> module instead of a patch to OpenSSH? If you did that, OpenSSH
> systems that use PAM could make use of it directly, and so could any
> other PAM-enabled systems.
On my to-do list. I know a little about how OpenSSH internals work but
nothing about PAM innards.
> Thanks for writing this up and publishing it, Paul. It's very
Thanks for taking the time to review this idea.
More information about the openssh-unix-dev