• 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 849 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 (22.1K 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

  • Cutting Out The Coding: Serverless Computing In Action May 24, 2022
  • Types of Blackjack Variants: Discover the Different Versions of the Game May 23, 2022
  • How Cloud, Robotics And Sensor Technologies Are Changing The Business Landscape May 23, 2022
  • Modernizing Your Business With a Hybrid Cloud Strategy May 22, 2022
  • Big Data in Sports May 20, 2022

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, May 24, 2022, https://thecustomizewindows.com/2016/09/fix-pam_unixsushiauth-authentication-failure-ssh-flood/.

Source:The Customize Windows, JiMA.in

This website uses cookies. If you do not want to allow us to use cookies and/or non-personalized Ads, kindly clear browser cookies after closing this webpage.

Read Privacy Policy.

PC users can consult Corrine Chorney for Security.

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

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

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