Bob Proulx wrote: > Bob Proulx wrote: > > AuthorizedKeysCommandUser root > > Match User root > > AuthorizedKeysCommand /bin/true > > Match all > > AuthorizedKeysCommand /root/bin/sv_get_authorized_keys > > > > I have tested that locally. Seems to do the desired thing. And that > > was what prevented me from being able to log in after a reboot > > previously. I am deploying it on vcs0. > > Actually... Upon reflection... > > Match User root > Match ALL > AuthorizedKeysCommandUser nobody > AuthorizedKeysCommand /root/bin/sv_get_authorized_keys > > Much better! And it uses a non-root user for the query.
"I missed it by _that_ much!" (Picture Max Smart holding up two fingers.) This is the cause of the breakage of that test suite. The user needs access to the sv_get_authorized_keys script and while on vcs0 it was accessible on download0 /root was restricted. I thought of this while up Poudre Canyon and called Karl and had him fix it. That part worked, had access to ssh keys again, and stopped asking for passwords. Good. But turns out that was only half the fix. The same NFS uid mapping on the back end problem existed that blocked things next. I had disabled that on both old vcs and olddownload so as not to lock me out during the IP change and hadn't put it back because why does NFS need to know this information? Well it turns out it does for the problem of someone belonging to more than 16 groups, the old hard limit. The uid mapping allows a workaround to have someone in more than 16 groups. But it requires that the NFS backend server know about all of the account information. Since I had broken and fixed that on old vcs I did the same process on olddownload. Bob
