How to prevent polkit and authentication failure further
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How to prevent polkit and authentication failure further
I have brand new server setup. I have permanently close the root login and password. Everything is key based but yet I get below.
I dont understand about the polkit-1 and how can I further harden the system ?
Polkit is asking for an authorisation password. What that means in practice depends on your polkit rules. You'll find these under /etc/polkit or possibly /etc/polkit-1 (I'm not sure of the exact name on your system).
Usually the root password is included by default. Other passwords may also be recognised, for example those of people in the sudo group or the wheel group. There may be individual users whose passwords are authoritative. It's up to the system administrator to tailor these rules to local requirements.
If you have removed the root login password then you will have to edit the polkit rules to accept some other password for authorisation, such as one of the possibilities I have suggested.
I have brand new server setup. I have permanently close the root login and password. Everything is key based but yet I get below.
I dont understand about the polkit-1 and how can I further harden the system ?
Those appear to be reports of many attempts to ssh to your server as the root user.
(All of those IP addresses are in China -- sigh)
If you've disabled root login via ssh, you are blocking them successfully.
Polkit is asking for an authorisation password. What that means in practice depends on your polkit rules. You'll find these under /etc/polkit or possibly /etc/polkit-1 (I'm not sure of the exact name on your system).
Usually the root password is included by default. Other passwords may also be recognised, for example those of people in the sudo group or the wheel group. There may be individual users whose passwords are authoritative. It's up to the system administrator to tailor these rules to local requirements.
If you have removed the root login password then you will have to edit the polkit rules to accept some other password for authorisation, such as one of the possibilities I have suggested.
Hi Hazel,
I found this etc/polkit-1 and in it I got localauthority localauthority.conf.d rules.d so which files should I touch? I notice localauthority.conf.d is empty. So next time I setup a new system I should set polkit-1 cause I never touch in Centos 6 before on this? So site even suggest it can be remove I am not sure to do that or not ?
Those appear to be reports of many attempts to ssh to your server as the root user.
(All of those IP addresses are in China -- sigh)
If you've disabled root login via ssh, you are blocking them successfully.
Hi scacey,
Actually beside that there are many other username attempt too e.g as below. I know we cant completely avoid this what else can I harden. I have also attached my sshd settings maybe you could suggest anything further.
One more method I am going to do is change the port 22 but the rest I am not too sure what could help to further harden the system.
Code:
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
MaxAuthTries 2
#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
PasswordAuthentication no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes
# GSSAPI options
GSSAPIAuthentication no
GSSAPICleanupCredentials no
#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 Red Hat Enterprise Linux and may cause several
# problems.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
Banner none
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
# 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
Hi Tshikose,
Yes I have enabled it but I still get some funny connection like preauth etc. How to further harden to minimise all these hacking attempts.
If you can access your server from an internal connection (or VPN), you better add that network in the white list to never lock yourself our for.
I usually ban failures on SSH for a full day (24 hours), so it will be desastrous for me to have to wait 24 hours to fix a problem.
Didn't receive an ident from these IPs:
103.99.2.170 port 49301: 1 Time(s)
Disconnecting after too many authentication failures for user:
<unknown> : 7 Time(s)
Illegal users from:
undef: 31 times
[preauth]: 1 time
Management [preauth]: 1 time
a [preauth]: 1 time
a2 [preauth]: 1 time
admin [preauth]: 1 time
fake [preauth]: 1 time
The Couldn't resolve these IPs: to me seems to be reverse DNS failures. They should not really be a problem. They just eat up your bandwidth. Some shut down that feature.
For the others, I will really want to know from you get them. /var/log/messages
/var/log/secure
journalctl -u sshd Just few I thought of.
Hi,
I actually got this from daily logwatch which is email to me. Can I sptop the reverse dns failure totally ? What else can I shut down to minimise my bandwidth usage and improve security more.
I do think you can do several things.
But for me to be able to guide more effectively, I need some information that you have not provided yet.
To stop the DNS querying I need to know which service is doing that.
I am not really familiar with logwatch email, but I think it give section headers that identify to what the report part is related. So what is the section of those DNS queries?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.