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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
