savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[savannah-help-public] [sr #109618] SSH authentication failure to dl.sv.


From: Bob Proulx
Subject: [savannah-help-public] [sr #109618] SSH authentication failure to dl.sv.nongnu.org
Date: Sat, 5 Jan 2019 19:28:18 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36

Update of sr #109618 (project administration):

                  Status:                    None => Done                   
             Assigned to:                    None => rwp                    
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

Thank you for the problem report.  They are appreciated it.  As you know all
of the GNU & FSF machines are moving ISPs now.  The entire collection of
inter-working Savannah systems were moved over the last two days. It's been a
long two days.

I literally called in a fix through Karl earlier today when I remembered
something and realized why part of it was broken and had Karl fix it over the
phone for me.  I was almost out of cell phone coverage and no keyboard. 
Thanks Karl! Here is the full story on this problem.

Thursday I had been locked out of the system because the configuration
required a working database connection even for root to log in.  I modified
the sshd_config to avoid that for root.  On download I copied the
configuration from vcs0 which was the first to run the new sshd_config.  And
made a gratuitous change of AuthorizedKeysCommandUser user from root to nobody
on both systems because it seemed it should not be needed.  However the
program itself lived in /root/bin and /root on download0 was restricted while
it was not on vcs0, allowing it to work on vcs0 as nobody but causing it to
break on download0 as nobody.  The quick fix was to restore it to running as
root so it can read the directory.  It's a very short perl program and not
scary but seemed reasonable to run it as non-root if possible.

However that was only half of the problem.  It fixed the ssh key problem.  But
the backend NFS server was not mapping uids.  Because in order to avoid being
locked out there when the db connection was severed I had removed the
nss-msyql module from /etc/nsswitch.conf for the IP migration.  I didn't think
it had needed to be there on the NFS backend.  But I was wrong. It is used on
the NFS backend to map uids.

Confusingly the nfs kernel server apparently needs nss working at nfs start
time and does not pick up the working configuration later.  This required the
nss mysql module to be restored, the nfs kernel restarted, and the mount point
umount/re-mount (yes the mount needed re-mounting) in order to have uid
mapping working.

All of that done I am now able to upload files to download.

Please try it now.  I think it should be working for you.  Thank you again for
the problem report.  I will add a test in our regression suite for upload to
download.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?109618>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]