• 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
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

  • iptables Basics : Chapter 1

    IPTables Basics Chapter 1 is Intended For the New Blank Cloud Server or Dedicated Server Users. It is Must to Read Before Executing Commands.

  • iptables Basics : Chapter 2, Fail2Ban

    This is Era of Automation. iptables Rules Can Be Automated With Interactive Package Fail2Ban Which iptables Basics Chapter 2 Will Explain.

  • Join/Merge Multiple Log Files For Big Data Analysis

    Here Are The Ways To Join/Merge Multiple Log Files For Big Data Analysis, Store Them To OpenStack Based Cloud Storage And Delete Old Files.

  • Limit SSH Access By Country To Save From SSH Brute Force

    SSH Brute Force is Known Way to Blow Away. Here is How To Limit SSH Access By Country To Save From SSH Brute Force & Filter With Fail2Ban.

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

  • Affordable Earphone/IEM for Audiophiles: HiFiMan RE-400 WaterlineOctober 2, 2023
  • What is Hardware Security Module (HSM)September 30, 2023
  • Transducer Technologies of HeadphonesSeptember 28, 2023
  • What is Analog-to-Digital Converter (ADC)September 27, 2023
  • Comparison of Tube Amplifiers and SemiconductorsSeptember 26, 2023
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