The only time I had something like that happen was when the user's file system wasn't properly labeled for SElinux. sshd from the command line doesn't source or use /lib/systemd/system/sshd.service nor /etc/sysconfig/sshd You can also use -vvv from the client side to see what it doesn't like.
On Tue, Jun 11, 2019 at 9:35 PM Russell Senior <[email protected]> wrote: > oh, hmm. it works when you start sshd manually. That makes my permissions > theory less likely. I'd turn up verbosity and capture the results in the > failing and not failing scenarios and diff them for clues. > > On Tue, Jun 11, 2019 at 9:32 PM Russell Senior <[email protected]> > wrote: > > > I've never used ssh-copy-id (presumably adding a public key to an > > authorized_keys file). Have you checked the permissions on the .ssh > > directory and contents? > > > > On Tue, Jun 11, 2019 at 9:10 PM Ken Stephens <[email protected] > > > > wrote: > > > >> Fedora 29 both systems. > >> Laptop does not challenge for password after ssh-copy-id from atlas. > >> atlas challenges after ssh-copy-id from laptop. > >> stopped sshd service on atlas and started on command line as root with > >> /usr/sbin/sshd &. atlas does not challenge for password, accepts key. > >> > >> Where and what do I need to change to get atlas not to challenge for > >> password after "normal" startup by systemd? > >> > >> Ken > >> _______________________________________________ > >> PLUG mailing list > >> [email protected] > >> http://lists.pdxlinux.org/mailman/listinfo/plug > >> > > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
