• Home
  • Archive
  • Tools
  • Contact Us

The Customize Windows

Technology Journal

  • Cloud Computing
  • Computer
  • Digital Photography
  • Windows 7
  • Archive
  • Cloud Computing
  • Virtualization
  • Computer and Internet
  • Digital Photography
  • Android
  • Sysadmin
  • Electronics
  • Big Data
  • Virtualization
  • Downloads
  • Web Development
  • Apple
  • Android
Advertisement
You are here: Home » Fix : pam_unix(sushi:auth): authentication failure SSH Flood

By Abhishek Ghosh September 12, 2016 2:37 am Updated on October 1, 2016

Fix : pam_unix(sushi:auth): authentication failure SSH Flood

Advertisement

Normal Cloud Server, VPS etc does not face so much problem than a dedicated server or a colocation server. The possible reason is chance of success is more to get a server down in case of dedicated server or a colocation server. That pam_unix(sushi:auth): authentication failure SSH Flood is result of huge amount of continuous brute force attack on port. Here is How to Quickly Fix pam_unix(sushi:auth): authentication failure SSH Flood to Terminate Attack.We are mainly describing ready to run commands for is for Debian, Ubuntu. Find suitable of each command or location of file for other GNU/Linux distro from official documentation.

fix-pam_unixsushi-auth-authentication-failure-ssh-flood

 

pam_unix(sushi:auth): authentication failure SSH Flood : Do You Have Basic Security of Server?

 

First open 2 SSH session window and stop SSH service :

Vim
1
service sshd stop

Locate where is your server operating system’s authentication log file is located. It is /var/log/auth.log for Ubuntu. To list the unique IP addresses with number of times they appeared, run this command on the file after making the path of log correct :

Advertisement

---

Vim
1
grep "Failed password for" /var/log/auth.log | grep -Po "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" | sort | uniq -c

You will get some response like this :

Vim
1
2
3
1 167.114.0.192
3 200.63.166.32
6 218.50.4.180

Also, you can use this command :

Vim
1
cat /var/log/auth.log* | grep 'Failed password' | grep sshd | awk '{print $1,$2}' | sort -k 1,1M -k 2n | uniq -c

You will get some response like this :

Vim
1
2
3
4
5
6
7
8
    857 Aug 14
    175 Aug 15
   4696 Aug 16
    318 Aug 17
   1971 Aug 18
   1965 Aug 19
   2866 Aug 20
...

Idiots slowly increased the attack on our servers. That is the log talking about. On Aug 15, Aug 17 we made rules tight. Then on Aug 16, we allowed all.

You definitely running iptables firewall even you do not know anything. Run this format of command after correcting the IP addresses :

Vim
1
2
3
iptables -A INPUT -s 218.50.4.180 -j DROP
iptables -A INPUT -s 167.114.0.192 -j DROP
iptables -A INPUT -s 167.114.0.192 -j DROP

Save the rule :

Vim
1
iptables-save > /etc/iptables/rules.v4

You will be interested in the most recent login attempts. You can see by running the command “lastlog”. The log file is at /var/log/lastlog. Running this command will do the job of checking :

Vim
1
lastlog

There will be many IP addresses other than yours’ IP. Normally you will have log like this :

Vim
1
2
3
4
5
6
7
8
Username         Port     From             Latest
myusername             pts/0    my.ip.add.dress    Sun Sep 11 18:03:49 -0500 2016
daemon                                     **Never logged in**
...
man                                        **Never logged in**
...
www-data                                   **Never logged in**
...

Those usernames are related to installed and running services, normally their login is not enabled. If www-data logged in to system, then your system is already penetrated. It is better to take it offline in such case and perform vigorous checking and repair (which can not be covered within this small quick guide), at minimum ask on StackExchange. In normal cases, except you, there will be no record of login.

In such case we say “brute force attempt”. Your condition is not yet bad. There are servers which none ever even do SSH to get that flood. It is not abnormal to fully loss control to take any backup from such server. Now run :

Vim
1
last

The above command will show up many IP addresses for sure. last reads from a log file, usually at /var/log/wtmp and prints the entries of successful login attempts made by the users in the past. You may get some similar IP addresses like :

Vim
1
2
3
223.191.41.59
223.191.38.149
223.191.44.219

In such case, you have to block the whole subnet with the same iptables -A INPUT -s .... DROP style command. These IP are usually from China, Korea, India. In addition to /var/log/lastlog, /var/log/wtmp; there are 3 files in /var/run and /var/log: utmp, wtmp and btmp, which hold info about current logins and additional info, historical and failed logins. You can check them slowly later. You should check cron :

Vim
1
crontab -l | grep -v '^#'

The above should have entries made by you. Odd entries should be web searched to exclude man in the middle attack (MITMA). Those IP like 223.191.44.219 are probably victims of MITMA — servers has became hackers property with huge effort. You also can be on that list. If you run this command :

Vim
1
last | grep root | grep -v tty | awk '{print $3}'

You will see that attacks are more with root username.

 

pam_unix(sushi:auth): authentication failure SSH Flood : Stop Using root User to SSH

 

Never change the default port of SSH. Many on internet will suggest you so. It just can complicate and end up security scanners flagging your login attempt as suspicious or simply you can never SSH inside. It is just not usable.

Basically IPTables alone can give enough power to fight with brute force ssh attacks. But first we need to get rid of root to login. Easy commands to create a user who can SSH, we are using an easy name thecustomizewindows, do not use such easy to guess username :

Vim
1
2
3
4
5
6
7
8
9
10
11
12
13
14
adduser thecustomizewindows
# complete the steps
usermod -aG sudo thecustomizewindows
# test
su - thecustomizewindows
# test
cd /root
nano /etc/ssh/sshd_config
# do this change
PermitRootLogin no
# add this line
AllowUsers thecustomizewindows
# save the file, start SSH. We stopped it
service sshd start

Do not reboot now. Keep one shell SSH session active. From another screen, ssh as root user name which the command format of ssh roots@my.ip.add.ress. Your server will deny right password. That is what we wanted. Now use custom user name which the command format of ssh thecustomizewindows@my.ip.add.ress. Your server will accept right password for the user. Then run su root, use root’s password. So, even if someone know your password, can not easily login.

I do not know your IPTable rules, but we will say eth0.103. What is that 103? Open /etc/network/interfaces. You will see that :

Vim
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
auto lo
iface lo inet loopback
..
auto eth0
...
auto eth0.101
...
...
auto eth0.102
face eth0.102 inet static
....
auto eth0.103
iface eth0.103 inet static
        address 15.160.170.180
        netmask 255.255.255.0

We are talking about that interface. The first rule tells that the TCP packets which will to come in and attempt to establish an SSH connection mark them as SSH, only give attention to the source of the packet. The second rule saying that if a packet attempting to establish an SSH connection comes, and it’s the fourth packet to come from the same source within thirty seconds, just reject it. The third and fourth rules mean if an SSH connection packet comes in, and it is the third attempt from the same IP within thirty seconds, log it, then reject it. The fifth rule says just accept the attempts which is not done by the above rule.

You can, indeed make it more tight to 3 and 2 instead of 4 and 3, around 25 seconds instead of 30 seconds. We need to log the attempts — a time and chance have to keep wider open.

Vim
1
2
3
4
5
sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 30 --hitcount 4 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset
sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j LOG --log-prefix "SSH brute force "
sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -m recent --update --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset
sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -j ACCEPT

Save the rule :

Vim
1
iptables-save > /etc/iptables/rules.v4

SSH from the other terminal screen. If everything is fine then reboot once, check the problems. You really need to :

Restrict that SSH login only from one IP.
Use Fail2Ban
or use Port Knocking.

Intrusion detection system like psad and/or Rootkit Hunter and/or OSSEC HIDS Security like effective Free Softwares to actively, automatically block. Next important is log monitoring.

You actually understood that we are worser hackers. None of us run the scripts oddly pointing to an innocent’s server. That doing is penetration testing and is a paid service. At the end from The Matrix, it is for you :

(after first meeting with The Merovingian)
Neo: Well, that didn’t go so well.
Morpheus: Are you Certain the Oracle didn’t say anything else?
Neo: Yes.
Trinity: Maybe we did something wrong.
Neo: Or didn’t do something.
Morpheus: No, what happened, happened and couldn’t have happened any other way.
Neo: How do you know?
Morpheus: We are still alive.

Tagged With pam unix ssh auth failure , non accedo in ssh Debian 10 pam failure , pam_unix authentication failure , pam_unix authentication failure sshd , pam_unix(sshd:auth): authentication faild , ssh pam_unix authentication failure , ssh pam_unix(sshd:auth): authentication failure , sshd[37568]: pam_unix(sshd:auth): authentication failure , sshd[7583]: pam_unix(sshd:auth): authentication failure

This Article Has Been Shared 615 Times!

Facebook Twitter Pinterest

Abhishek Ghosh

About Abhishek Ghosh

Abhishek Ghosh is a Businessman, Surgeon, Author and Blogger. You can keep touch with him on Twitter - @AbhishekCTRL.

Here’s what we’ve got for you which might like :

Articles Related to Fix : pam_unix(sushi:auth): authentication failure SSH Flood

  • SELinux and Security in the Context of Cloud Servers

    SELinux Was Developed By United States National Security Agency (NSA). SELinux and Security in the Context of Cloud Servers Can Be Questionable.

  • Security Concerns of Server Virtualization and Solutions

    Recent discovery of VENOM and related critical bugs in the Xen, KVM, and native QEMU virtual machine platforms again brought the topic Security Concerns of Server Virtualization in to lime light. VENOM was unknown, from Heartbleed, what we have learned is quite clear – frankly there is nothing to do with the unknown, undiscovered bugs […]

  • Fix Nginx OCSP ERROR : OCSP Response Expired

    Here is How to Fix Nginx OCSP ERROR – OCSP Response Expired After Enabling OCSP Stapling on Nginx. Error is Due to Certain Criterion of RFC.

  • Ubuntu 14.04 Nginx HTTP/2 Directive, NPN & ALPN

    Here is a Handy Guide For the New Users Around Ubuntu 14.04 Nginx HTTP/2 Directive, NPN & ALPN. Sadly, HTTP/2 is Not Exactly Easy Like SPDY.

  • Update letsencrypt to certbot (Ubuntu letsencrypt 16.04 Error Fix)

    Here Are Steps To Update letsencrypt to certbot For the Users Who Used Former Before letsencrypt Became certbot. It is Mandatory For Ubuntu.

Additionally, performing a search on this website can help you. Also, we have YouTube Videos.

Take The Conversation Further ...

We'd love to know your thoughts on this article.
Meet the Author over on Twitter to join the conversation right now!

If you want to Advertise on our Article or want a Sponsored Article, you are invited to Contact us.

Contact Us

Subscribe To Our Free Newsletter

Get new posts by email:

Please Confirm the Subscription When Approval Email Will Arrive in Your Email Inbox as Second Step.

Search this website…

 

Popular Articles

Our Homepage is best place to find popular articles!

Here Are Some Good to Read Articles :

  • Cloud Computing Service Models
  • What is Cloud Computing?
  • Cloud Computing and Social Networks in Mobile Space
  • ARM Processor Architecture
  • What Camera Mode to Choose
  • Indispensable MySQL queries for custom fields in WordPress
  • Windows 7 Speech Recognition Scripting Related Tutorials

Social Networks

  • Pinterest (24.3K Followers)
  • Twitter (5.8k Followers)
  • Facebook (5.7k Followers)
  • LinkedIn (3.7k Followers)
  • YouTube (1.3k Followers)
  • GitHub (Repository)
  • GitHub (Gists)
Looking to publish sponsored article on our website?

Contact us

Recent Posts

  • Cyberpunk Aesthetics: What’s in it Special January 27, 2023
  • How to Do Electrical Layout Plan for Adding Smart Switches January 26, 2023
  • What is a Data Mesh? January 25, 2023
  • What is Vehicular Ad-Hoc Network? January 24, 2023
  • Difference Between Panel Light, COB Light, Track Light January 21, 2023

About This Article

Cite this article as: Abhishek Ghosh, "Fix : pam_unix(sushi:auth): authentication failure SSH Flood," in The Customize Windows, September 12, 2016, January 30, 2023, https://thecustomizewindows.com/2016/09/fix-pam_unixsushiauth-authentication-failure-ssh-flood/.

Source:The Customize Windows, JiMA.in

PC users can consult Corrine Chorney for Security.

Want to know more about us? Read Notability and Mentions & Our Setup.

Copyright © 2023 - The Customize Windows | dESIGNed by The Customize Windows

Copyright  · Privacy Policy  · Advertising Policy  · Terms of Service  · Refund Policy

We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
Do not sell my personal information.
Cookie SettingsAccept
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
CookieDurationDescription
cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytics
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Others
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
SAVE & ACCEPT