12:33 p.m.
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=aes256-gcm@openssh.com,chacha20-poly1305(a)>
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.
12:45 p.m.
Date: Wednesday, July 15, 2020 10:33:35 -0700
From: Geoffrey Leach <geoff(a)hughes.net>
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
12:46 p.m.
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.
1:51 p.m.
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 <horsley1953(a)gmail.com> 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.
1:58 p.m.
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 <geoff(a)hughes.net> 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 <horsley1953(a)gmail.com> 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 -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> 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/users@lists.fedoraproject.org
2 p.m.
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 <geoff(a)hughes.net> 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 <horsley1953(a)gmail.com> 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.
2:29 p.m.
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").
3:19 p.m.
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.
4:06 p.m.
On Wed, 15 Jul 2020 16:19:40 -0400
Tom Horsley <horsley1953(a)gmail.com> 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.
4:04 p.m.
On Wed, 15 Jul 2020 12:29:29 -0700
Samuel Sieb <samuel(a)sieb.net> 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,
7:07 a.m.
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 <samuel(a)sieb.net> 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 -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
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/users@lists.fedoraproject.org
1383
days inactive
1386
days old
10 comments
6 participants
participants (6)
-
Bill Shirley -
bruce -
Geoffrey Leach -
Richard -
Samuel Sieb -
Tom Horsley