Fedora 33 SSH Access Denied But Webmin Works Fine
-
I have a bit of a strange issue.
Random business owner called for help on their Nextcloud server. The previous IT guy set it up on Fedora and added Webmin. I was told that there was no new password selected for Webmin and that it would login as root so he gave me the access password and in fact I can login to Webmin using root + password however, when I try to login through SSH using the same credentials, I get an Access Denied error. I have verified the password over a dozen times and so far I am simply not able to login to SSH as root. No other users were setup.
I can issue commands through Webmin command shell except for the passwd command to reset root password so as of right now, I am locked out of SSH but Webmin works fine.
Any ideas as to why I am locked out of SSH? The error suggests a password issue but since the owner doesn't have any other password from the previous guy, I am grasping at straws so I don't have to blow it away and start from scratch.
I ran
sudo pwck -r /etc/shadow
and I get this output related to root user.sudo pwck -r /etc/shadow
invalid password file entry
delete line 'root:$6$wMHG.3SSWjCcHHKO$9UmPtJcSyKaA/EKLWX6vhx02eaJH7yfdsDA9PRCadROMMb6Sgjggdq7V0/gNXB3q19LZK.sYshPiEyv3XYv8D.::0:99999:7:::'? No -
Root could be denied access to SSH. This is a pretty common lockdown option that people enable.
-
@Dashrender I thought that too but when I enumerate users...
cat /etc/passwd
I get this for root...
root:x:0:0:root:/root:/bin/bash
Unless I am reading this wrong, it doesn't look like that was the case. There are also no other users listed in the output besides the apache, mysql, systemd...etc.
-
Root can't login on ssh by default in most distros.
For those that changes the default and allows root login, the first option is to only allow login using ssh keys and certificates, not passwords.
Usually the console is however set to allow root login by default. But then you need to be at the server, or have IPMI setup for remote KVM.
Anyway, if you can access webmin with root can't you edit the ssh settings and restart?
-
@Pete-S I can edit any of the files, just don't know where and what edits to make.
-
@NashBrydges said in Fedora 33 SSH Access Denied But Webmin Works Fine:
@Pete-S I can edit any of the files, just don't know where and what edits to make.
OK, I got you. Please run the command below to see the contents of the ssh config file.
cat /etc/ssh/sshd_config
Or open the file
/etc/ssh/sshd_config
if there is an editor for that.You're looking for a line that says
PermitRootLogin
PermitRootLogin Specifies whether root can log in using ssh(1). The argument must be yes, prohibit-password, forced-commands-only, or no. The default is prohibit-password. If this option is set to prohibit-password (or its deprecated alias, without-password), password and keyboard- interactive authentication are disabled for root. If this option is set to forced-commands-only, root login with public key authentication will be allowed, but only if the command option has been specified (which may be useful for taking remote backups even if root login is normally not allowed). All other authentication methods are disabled for root. If this option is set to no, root is not allowed to log in.
-
@Pete-S
> cat /etc/ssh/ssh_config #$OpenBSD: ssh_config,v 1.35 2020/07/17 03:43:42 dtucker Exp $ # This is the ssh client system-wide configuration file. See # ssh_config(5) for more information. This file provides defaults for # users, and the values can be changed in per-user configuration files # or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for some commonly used options. For a comprehensive # list of available options, their meanings and defaults, please see the # ssh_config(5) man page. # Host * # ForwardAgent no # ForwardX11 no # PasswordAuthentication yes # HostbasedAuthentication no # GSSAPIAuthentication no # GSSAPIDelegateCredentials no # GSSAPIKeyExchange no # GSSAPITrustDNS no # BatchMode no # CheckHostIP yes # AddressFamily any # ConnectTimeout 0 # StrictHostKeyChecking ask # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # IdentityFile ~/.ssh/id_ecdsa # IdentityFile ~/.ssh/id_ed25519 # Port 22 # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc # MACs hmac-md5,hmac-sha1,[email protected] # EscapeChar ~ # Tunnel no # TunnelDevice any:any # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com # RekeyLimit 1G 1h # UserKnownHostsFile ~/.ssh/known_hosts.d/%k # # This system is following system-wide crypto policy. # To modify the crypto properties (Ciphers, MACs, ...), create a *.conf # file under /etc/ssh/ssh_config.d/ which will be automatically # included below. For more information, see manual page for # update-crypto-policies(8) and ssh_config(5). Include /etc/ssh/ssh_config.d/*.conf
-
@NashBrydges
The 'include' location has a single file named '50-redhat.conf'That files contains...
# The options here are in the "Match final block" to be applied as the last # options and could be potentially overwritten by the user configuration Match final all # Follow system-wide Crypto Policy, if defined: Include /etc/crypto-policies/back-ends/openssh.config GSSAPIAuthentication yes # If this option is set to yes then remote X11 clients will have full access # to the original X11 display. As virtually no X11 client supports the untrusted # mode correctly we set this to yes. ForwardX11Trusted yes # Send locale-related environment variables SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE SendEnv XMODIFIERS # Uncomment this if you want to use .local domain # Host *.local
-
You were too quick.
It's the /etc/ssh/sshd_config file you want to look at.I wrote the wrong filename but corrected it straight away.
The one you've been looking at is for the ssh client.
-
@Pete-S Ah, I see that line is commented out. I suppose I need to change that to "yes" and uncomment?
Here is the full content...
cat /etc/ssh/ssh_config # $OpenBSD: ssh_config,v 1.35 2020/07/17 03:43:42 dtucker Exp $ # This is the ssh client system-wide configuration file. See # ssh_config(5) for more information. This file provides defaults for # users, and the values can be changed in per-user configuration files # or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for some commonly used options. For a comprehensive # list of available options, their meanings and defaults, please see the # ssh_config(5) man page. # Host * # ForwardAgent no # ForwardX11 no # PasswordAuthentication yes # HostbasedAuthentication no # GSSAPIAuthentication no # GSSAPIDelegateCredentials no # GSSAPIKeyExchange no # GSSAPITrustDNS no # BatchMode no # CheckHostIP yes # AddressFamily any # ConnectTimeout 0 # StrictHostKeyChecking ask # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # IdentityFile ~/.ssh/id_ecdsa # IdentityFile ~/.ssh/id_ed25519 # Port 22 # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc # MACs hmac-md5,hmac-sha1,[email protected] # EscapeChar ~ # Tunnel no # TunnelDevice any:any # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com # RekeyLimit 1G 1h # UserKnownHostsFile ~/.ssh/known_hosts.d/%k # # This system is following system-wide crypto policy. # To modify the crypto properties (Ciphers, MACs, ...), create a *.conf # file under /etc/ssh/ssh_config.d/ which will be automatically # included below. For more information, see manual page for # update-crypto-policies(8) and ssh_config(5). Include /etc/ssh/ssh_config.d/*.conf > cat /etc/ssh/sshd_config # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. # To modify the system-wide sshd configuration, create a *.conf file under # /etc/ssh/sshd_config.d/ which will be automatically included below Include /etc/ssh/sshd_config.d/*.conf # If you want to change the port on a SELinux system, you have to tell # SELinux about this change. # semanage port -a -t ssh_port_t -p tcp #PORTNUMBER # #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no #KerberosUseKuserok yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no #GSSAPIEnablek5users no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. # WARNING: 'UsePAM no' is not supported in Fedora and may cause several # problems. #UsePAM no #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server
-
@NashBrydges Yep, changed it to yes and now I can access via SSH!!! Thank you for the help!
-
@NashBrydges said in Fedora 33 SSH Access Denied But Webmin Works Fine:
@NashBrydges Yep, changed it to yes and now I can access via SSH!!! Thank you for the help!
Good man! You got the job done!
If the ssh server is accessible from the internet make sure the root password is long enough and random. At least 16 characters preferably.
-
@Pete-S No external access so they are golden. Password has been changed to a 20 character one as well.
-
@NashBrydges said in Fedora 33 SSH Access Denied But Webmin Works Fine:
@Pete-S No external access so they are golden. Password has been changed to a 20 character one as well.
Make a new user for this and disable root in
ssh
again anyway. -
@NashBrydges said in Fedora 33 SSH Access Denied But Webmin Works Fine:
The previous IT guy set it up on Fedora and added Webmin. I was told that there was no new password selected for Webmin and that it would login as root so he gave me the access password and in fact I can login to Webmin using root + password however, when I try to login through SSH using the same credentials, I get an Access Denied error.
Root is disabled by default in SSH configs most of the time.
-
@NashBrydges said in Fedora 33 SSH Access Denied But Webmin Works Fine:
I ran sudo pwck -r /etc/shadow and I get this output related to root user.
sudo pwck -r /etc/shadow
invalid password file entry
delete line 'root:$6$wMHG.3SSWjCcHHKO$9UmPtJcSyKaA/EKLWX6vhx02eaJH7yfdsDA9PRCadROMMb6Sgjggdq7V0/gNXB3q19LZK.sYshPiEyv3XYv8D.::0:99999:7:::'? Noroot isn't impacted by sudo
-
@NashBrydges said in Fedora 33 SSH Access Denied But Webmin Works Fine:
@Dashrender I thought that too but when I enumerate users...
cat /etc/passwd
I get this for root...
root:x:0:0:root:/root:/bin/bash
Unless I am reading this wrong, it doesn't look like that was the case. There are also no other users listed in the output besides the apache, mysql, systemd...etc.
It's the SSH config, not the password that is the issue. You know the /etc/passwd file is working great since WebMin is using it and verifying that for you. So you know the issue is limited to SSH.
-
@NashBrydges said in Fedora 33 SSH Access Denied But Webmin Works Fine:
@NashBrydges Yep, changed it to yes and now I can access via SSH!!! Thank you for the help!
This is expected behaviour. The former IT just didn't change it. They might have installed WebMin because they didn't know how to do this. WebMin is a pretty weird thing for an IT shop that knows Linux to install. So my guess is that they were so lost that they attempted a workaround.
-
@NashBrydges said in Fedora 33 SSH Access Denied But Webmin Works Fine:
@Pete-S No external access so they are golden. Password has been changed to a 20 character one as well.
Switch to a key
-
@scottalanmiller said in Fedora 33 SSH Access Denied But Webmin Works Fine:
Root is disabled by default in SSH configs most of the time.
Not until the last couple years. Sure we always disabled it, but it was not default that way until recently.