openssh unix dev - Feb 2015 - Re: Creating users "on - the - fly"

On Fri 2015-02-06 14:30:13 -0500, Cary FitzHugh wrote:
> Hence  - maybe a NSS User Database extension which looks for the
> public keys from a webservice (and then maybe writes them to
> /tmp/<username>.
No, i'm suggesting that when you want to look up the user, use NSS to
find the username and map it to a numeric user ID and the other
information that is typically found in /etc/passwd.  this doesn't write
anything to the local disk.
> The AuthorzedKeysCommand could then just return the tmp/username
information..
Then the AuthorizedKeysCommand can return the proper key material.

     --dkg

Morning everyone,

I have put into place the lbnns extension https://github.com/hivewing/libnss-ato
It seems to always resolve every username to the same uid, with no password.
I've set the shell to bin/false, and put the home dir to /dev/null as well.

And it actually seems to work!

On a connection request, the AuthorzedKeysCommand script is called
with the right username, letting me look up the username in my
webservice, and return the list of authorized_keys.
Wonderful.

I spent a good bit of time banging my head on the wall, trying to
figure out why I could only get one connection through the sshd server
before it would crash.  It would accept one connection, every other
connection request would be ignored.  And once that one connection was
closed, sshd would exit.

I was running it like so:  /usr/sbin/sshd -D -e -d -d -d

And life was sad. very sad.

I now run it just with /usr/sbin/sshd -D
and it all seems to work.

I'm not sure if anyone cares that it doesn't work with the three
'-d's
on there.  but if anyone did care, I could try to help them get a
reproducible case.

Thanks to everyone who helped with suggestions!

Cary

On Fri, Feb 6, 2015 at 3:02 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Fri 2015-02-06 14:30:13 -0500, Cary FitzHugh wrote:
>> Hence  - maybe a NSS User Database extension which looks for the
>> public keys from a webservice (and then maybe writes them to
>> /tmp/<username>.
>
> No, i'm suggesting that when you want to look up the user, use NSS to
> find the username and map it to a numeric user ID and the other
> information that is typically found in /etc/passwd.  this doesn't write
> anything to the local disk.
>
>> The AuthorzedKeysCommand could then just return the tmp/username
information..
>
> Then the AuthorizedKeysCommand can return the proper key material.
>
>      --dkg

Hello Cary,
just for your information to the topic of problem you wanted to describe:
When you run sshd with -d argument, it will accept only one connection 
and exists, as you can read in man pages (man sshd):

      -d      Debug mode.  The server sends verbose debug output to standard
              error, and does not put itself in the background.  The server
              also will not fork and will only process one connection.  This
              option is only intended for debugging for the server. Multiple
              -d options increase the debugging level.  Maximum is 3.

It is not a bug. It is feature

Best Regards,
Jakub Jelen

On 02/09/2015 06:59 PM, Cary FitzHugh wrote:
> Morning everyone,
>
> I have put into place the lbnns extension
https://github.com/hivewing/libnss-ato
> It seems to always resolve every username to the same uid, with no
password.
> I've set the shell to bin/false, and put the home dir to /dev/null as
well.
>
> And it actually seems to work!
>
> On a connection request, the AuthorzedKeysCommand script is called
> with the right username, letting me look up the username in my
> webservice, and return the list of authorized_keys.
> Wonderful.
>
> I spent a good bit of time banging my head on the wall, trying to
> figure out why I could only get one connection through the sshd server
> before it would crash.  It would accept one connection, every other
> connection request would be ignored.  And once that one connection was
> closed, sshd would exit.
>
> I was running it like so:  /usr/sbin/sshd -D -e -d -d -d
>
> And life was sad. very sad.
>
> I now run it just with /usr/sbin/sshd -D
> and it all seems to work.
>
> I'm not sure if anyone cares that it doesn't work with the three
'-d's
> on there.  but if anyone did care, I could try to help them get a
> reproducible case.
>
> Thanks to everyone who helped with suggestions!
>
> Cary
>
> On Fri, Feb 6, 2015 at 3:02 PM, Daniel Kahn Gillmor
> <dkg at fifthhorseman.net> wrote:
>> On Fri 2015-02-06 14:30:13 -0500, Cary FitzHugh wrote:
>>> Hence  - maybe a NSS User Database extension which looks for the
>>> public keys from a webservice (and then maybe writes them to
>>> /tmp/<username>.
>> No, i'm suggesting that when you want to look up the user, use NSS
to
>> find the username and map it to a numeric user ID and the other
>> information that is typically found in /etc/passwd.  this doesn't
write
>> anything to the local disk.
>>
>>> The AuthorzedKeysCommand could then just return the tmp/username
information..
>> Then the AuthorizedKeysCommand can return the proper key material.
>>
>>       --dkg
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev