[openssh-unix-dev] Re: Creating users "on - the - fly"
Jakub Jelen
jjelen at redhat.com
Tue Feb 10 23:29:07 AEDT 2015
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
More information about the openssh-unix-dev
mailing list