ssh: Permission denied

[Geoffrey Leach]

From-scratch Fedora 32 install. sshd enabled. ssh to new install fails
on password (which is correct)

ssh  root@webster
root@webster's password: 
Permission denied, please try again.

* sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled;
vendor preset: enable> Active: active (running) since Wed 2020-07-15
13:14:57 EDT; 5s ago Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 2419 (sshd)
      Tasks: 1 (limit: 19062)
     Memory: 1.2M
        CPU: 10ms
     CGroup: /system.slice/sshd.service
             `-2419 /usr/sbin/sshd -D
-oCiphers=[e-mail],chacha20-poly1305@>

Jul 15 13:14:57 webster.mtranch.com systemd[1]: Starting OpenSSH server
daemon... Jul 15 13:14:57 webster.mtranch.com sshd[2419]: Server
listening on 0.0.0.0 port 22. Jul 15 13:14:57 webster.mtranch.com
sshd[2419]: Server listening on :: port 22. Jul 15 13:14:57
webster.mtranch.com systemd[1]: Started OpenSSH server daemon.

The new install (webster) is able to ssh out. It's ssh to webster
that's the problem.

ping and traceroute find webster. ssh to non-root account has the same
problem.

ssh-copy-id root@webster also fails. ssh-copy-id on webster works.

Suggestions would be appreciated.

[Richard]

> Date: Wednesday, July 15, 2020 10:33:35 -0700
> From: Geoffrey Leach
>
> From-scratch Fedora 32 install. sshd enabled. ssh to new install
> fails on password (which is correct)
>
> ssh  root@webster
> root@webster's password: 
> Permission denied, please try again.

I don't have a f32 handy to double check, but I believe that root ssh
logins now default off in /etc/sshd_config . The message you show is
what one gets of they are off. Try using a user other than root.

- Richard

[Tom Horsley]

On Wed, 15 Jul 2020 10:33:35 -0700
Geoffrey Leach wrote:
> Suggestions would be appreciated.

I believe the default sshd_config in fedora 32 has been changed
to say "PermitRootLogin: prohibit-password", so you can only
get it with public keys. If you change it to "yes" and restart
sshd, it will allow password login again.

[Geoffrey Leach]

This resolves the problem with root login, thanks.

The problem with non-root login getting Permission denied remains.

On Wed, 15 Jul 2020 13:46:19 -0400
Tom Horsley  wrote:
> On Wed, 15 Jul 2020 10:33:35 -0700
> Geoffrey Leach wrote:
> > Suggestions would be appreciated.
>
> I believe the default sshd_config in fedora 32 has been changed
> to say "PermitRootLogin: prohibit-password", so you can only
> get it with public keys. If you change it to "yes" and restart
> sshd, it will allow password login again.

[bruce]

geoffry..

can you post the current sshd_config file.. I forget exactly what the
file has for the diff attributes

On Wed, Jul 15, 2020 at 2:52 PM Geoffrey Leach  wrote:
> This resolves the problem with root login, thanks.
>
> The problem with non-root login getting Permission denied remains.
>
> On Wed, 15 Jul 2020 13:46:19 -0400
> Tom Horsley  wrote:
> > On Wed, 15 Jul 2020 10:33:35 -0700
> > Geoffrey Leach wrote:
> > > Suggestions would be appreciated.
> >
> > I believe the default sshd_config in fedora 32 has been changed
> > to say "PermitRootLogin: prohibit-password", so you can only
> > get it with public keys. If you change it to "yes" and restart
> > sshd, it will allow password login again.
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]

[Geoffrey Leach]

Further info on this. The problem appears to be with the user account
that was being used for testing.

The user account that was created with Anaconda permits ssh login. The
problem account is using a directory that was leftover from the Fedora
30 install.

On Wed, 15 Jul 2020 11:51:34 -0700
Geoffrey Leach  wrote:
> This resolves the problem with root login, thanks.
>
> The problem with non-root login getting Permission denied remains.
>
> On Wed, 15 Jul 2020 13:46:19 -0400
> Tom Horsley  wrote:
> > On Wed, 15 Jul 2020 10:33:35 -0700
> > Geoffrey Leach wrote:
> > > Suggestions would be appreciated.
> >
> > I believe the default sshd_config in fedora 32 has been changed
> > to say "PermitRootLogin: prohibit-password", so you can only
> > get it with public keys. If you change it to "yes" and restart
> > sshd, it will allow password login again.

[Samuel Sieb]

On 7/15/20 12:00 PM, Geoffrey Leach wrote:
> Further info on this. The problem appears to be with the user account
> that was being used for testing.
>
> The user account that was created with Anaconda permits ssh login. The
> problem account is using a directory that was leftover from the Fedora
> 30 install.

You created that user again after the install?  It most likely has the 
wrong permissions since the user will most likely have a different 
userid than it did before.  Do "ls -l /home" to check that.  And if the 
permissions are wrong, then run "chown -R user: /home/user" (replacing 
"user" in all cases with the real username").

[Tom Horsley]

On Wed, 15 Jul 2020 12:29:29 -0700
Samuel Sieb wrote:
> > The user account that was created with Anaconda permits ssh login. The
> > problem account is using a directory that was leftover from the Fedora
> > 30 install.

Another possibility is that you have selinux enabled and
the leftover directory isn't labeled correctly. In theory
you can create a /.autorelabel directory in the root of the
filesystem and reboot to get all the selinux labels fixed.

[Geoffrey Leach]

On Wed, 15 Jul 2020 16:19:40 -0400
Tom Horsley  wrote:
> On Wed, 15 Jul 2020 12:29:29 -0700
> Samuel Sieb wrote:
> > > The user account that was created with Anaconda permits ssh
> > > login. The problem account is using a directory that was leftover
> > > from the Fedora 30 install.
>
> Another possibility is that you have selinux enabled and
> the leftover directory isn't labeled correctly. In theory
> you can create a /.autorelabel directory in the root of the
> filesystem and reboot to get all the selinux labels fixed.

Life is too short for selinux :-) But, thanks.

[Geoffrey Leach]

On Wed, 15 Jul 2020 12:29:29 -0700
Samuel Sieb  wrote:
> On 7/15/20 12:00 PM, Geoffrey Leach wrote:
> > Further info on this. The problem appears to be with the user
> > account that was being used for testing.
> >
> > The user account that was created with Anaconda permits ssh login.
> > The problem account is using a directory that was leftover from the
> > Fedora 30 install.
>
> You created that user again after the install?  It most likely has
> the wrong permissions since the user will most likely have a
> different userid than it did before.  Do "ls -l /home" to check that.
>  And if the permissions are wrong, then run "chown -R user:
> /home/user" (replacing "user" in all cases with the real username").

More than likely that was the problem. I recreated the user and copied
the non-dot files over and did the chown thingy,

[Bill Shirley]

Back when I migrated to Fedora 24, all the user/group ids changed.
At that time I discovered rsync's --usermap and --groupmap.  Its format is:
old_uid:new_username
old_gid:new_groupname
rsync -axAXv --delete --numeric-ids --usermap=400:bob,391:smbguest --groupmap=400:bob,391:smbguest  rsync://oldserver.com/home/ 
/home/

Of course there were many more users that just the two so I created a bash script:
#! /usr/bin/bash
USERMAP=400:bob,301:smbguest,501:bill,600:fred,....
GROUPMAP=400:bob,301:smbguest,501:bill,600:fred,435:staff,....
rsync -axAXv --delete --numeric-ids  --usermap=$USERMAP  --groupmap=$GROUPMAP rsync://oldserver.com/home/ /home/

Hope this helps someone,
Bill

On 7/15/2020 5:04 PM, Geoffrey Leach wrote:
> On Wed, 15 Jul 2020 12:29:29 -0700
> Samuel Sieb  wrote:
> > On 7/15/20 12:00 PM, Geoffrey Leach wrote:
> > > Further info on this. The problem appears to be with the user
> > > account that was being used for testing.
> > >
> > > The user account that was created with Anaconda permits ssh login.
> > > The problem account is using a directory that was leftover from the
> > > Fedora 30 install.
> >
> > You created that user again after the install?  It most likely has
> > the wrong permissions since the user will most likely have a
> > different userid than it did before.  Do "ls -l /home" to check that.
> >   And if the permissions are wrong, then run "chown -R user:
> > /home/user" (replacing "user" in all cases with the real username").
>
> More than likely that was the problem. I recreated the user and copied
> the non-dot files over and did the chown thingy,
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]