Welcome to the most active Linux Forum on the web.
Go Back > Forums > Linux Forums > Linux - Security
User Name
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.


  Search this Thread
Old 08-12-2017, 08:33 PM   #1
LQ Newbie
Registered: Aug 2017
Posts: 2

Rep: Reputation: Disabled
Large number of failed ssh login attempts


I own a Raspberry Pi running a ssh server. As I have noticed many login attempts from different locations on earth (mainly from China), I have configured my server to accept connections from only 2 or 3 known IP addresses. I also wanted to see what passwords were used by the attackers so I wrote a small PAM module to log this information. Surprisingly, all passwords are nearly the same. They often start with the 4 ASCII characters #8, #10, #13 and #127 in this order. I havn't found information on the web about possible vulnerability of ssh to special characters. What do you think about that?
Old 08-12-2017, 09:33 PM   #2
LQ Guru
Registered: Jan 2006
Location: Virginia, USA
Distribution: Slackware, Debian, Mageia, and whatever VMs I happen to be playing with
Posts: 12,791
Blog Entries: 17

Rep: Reputation: 3317Reputation: 3317Reputation: 3317Reputation: 3317Reputation: 3317Reputation: 3317Reputation: 3317Reputation: 3317Reputation: 3317Reputation: 3317Reputation: 3317
My guess is automated random port scans.
Old 08-13-2017, 01:58 AM   #3
Senior Member
Registered: Jan 2005
Location: USA and Italy
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 3,136

Rep: Reputation: 551Reputation: 551Reputation: 551Reputation: 551Reputation: 551Reputation: 551
It looks like an automated script to search for systems vulnerable to brute force password attacks on ssh.
Old 08-13-2017, 02:42 AM   #4
Senior Member
Registered: Apr 2005
Distribution: Ubuntu, Devuan, OpenBSD
Posts: 2,645
Blog Entries: 3

Rep: Reputation: 1160Reputation: 1160Reputation: 1160Reputation: 1160Reputation: 1160Reputation: 1160Reputation: 1160Reputation: 1160Reputation: 1160
If they're coming from the same networks, you can always report them to the netblock owner. That takes a small effort even with a template but often reduces the attack.

Also, there is sshguard which can automatically add most if not all of those attackers to your firewall's block list, even for IPv6 sources.
Old 08-13-2017, 06:24 AM   #5
LQ 5k Club
Registered: Jan 2011
Location: Nowhere near you, thank God.
Distribution: OSX Sierra
Posts: 8,576
Blog Entries: 15

Rep: Reputation: Disabled
Originally Posted by Izwal View Post
What do you think about that?
Something doesn't add up, is what I think.
Old 08-13-2017, 07:50 AM   #6
Registered: Jun 2016
Distribution: any&all, in VBox; Ol'UnixCLI; NO GUI resources
Posts: 997
Blog Entries: 12

Rep: Reputation: 359Reputation: 359Reputation: 359Reputation: 359
I wrote a small PAM module to log this information. Surprisingly, all passwords are nearly the same. They often start with the 4 ASCII characters #8, #10, #13 and #127 in this order.
Welcome to LQ! Maybe "doesn't add up" means: Are you *absolutely sure* your capture works? Did you test it, with a login attempt from you, with a test pwd, to check for? I would have expected to find web-search results, but didn't, for:
password "8 10 13 127"
Or is that "bs lf cr del"? (no results for that either). What was the other "nearly the same" part?

Also, share=post some specifics (those similar pwds, 'logs', -d ,...) that we can have a look at & advise on (of course, obfuscate your publicIP!). 'Picture worth 1K words'. Tips: 4a)CODE, |nc 9999

Last edited by Jjanel; 08-13-2017 at 01:43 PM.
Old 08-13-2017, 09:30 PM   #7
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,629
Blog Entries: 4

Rep: Reputation: 2999Reputation: 2999Reputation: 2999Reputation: 2999Reputation: 2999Reputation: 2999Reputation: 2999Reputation: 2999Reputation: 2999Reputation: 2999Reputation: 2999
As long as it is possible for "anyone on the planet" to reach a login: prompt on your box, you will have no end of misery, and "no dictionary will ever protect you." But you do have an alternative: an easy-to-implement alternative will shut all of this completely down, cold, and keep it that way forever after.

Have a look at my LQ blog where I discuss How To Build a 'Dwarvish Door' With OpenVPN.

The strategy which I describe there will bring an immediate end to all such access attempts. To the outside world, your system has no "open ports," and, so far as they can detect, it's not running OpenVPN, either! (Unless they demonstrate in the initial handshake that they probably possess the proper tls-auth certificate, the OpenVPN sever won't even answer the phone.)

The only way to enter is to possess two one-of-a-kind digital certificates, the second one of which also has not been "revoked" by you.

Only then can one reach ssh or anything else. (ssh, which of course you have set up to require a third digital certificate and not to ever prompt for a password, becomes the second also-impenetrable layer in your outer defenses, guarding all access to a shell prompt ... a layer which will never be assaulted because it will never be found.)

Authorized users can clear these obstacles in seconds, and can carry on their communication with your system, securely, as though it were simply attached (through a (software) router) to their local network. They don't have to think further about security: it is secure, and they are certain that they are talking to the intended machine. (In like manner, your machine knows that it is communicating specifically with them. It knows them by name.)

(Digital certificates can be encrypted with a password, e.g. for use with "road warrior" machines that might get stolen in an airport bathroom, so that they can't be used until you get a chance to revoke them, which act instantly and selectively(!) renders them useless – encrypted or not.)

The number of unauthorized access attempts will immediately drop to zero and stay there ... forever.

I've deployed many public servers – I won't tell you the IP-addresses and you can't find them – that have never had an unauthorized access attempt. Ever. Nor will they. Ever.

Last edited by sundialsvcs; 08-14-2017 at 03:53 PM.
3 members found this post helpful.
Old 08-20-2017, 01:11 PM   #8
LQ Newbie
Registered: Aug 2017
Posts: 2

Original Poster
Rep: Reputation: Disabled
Hello everybody and thank you for the contributions.

I finally managed to log passwords by modifying my "sshd_config" file:
PermitRootLogin yes
AllowUsers *@*
Since this modification, the login attempts are successfully logged:
2017-08-20 18:18:24  from user="root" pass="!@"
2017-08-20 18:18:27  from user="root" pass="!@"
2017-08-20 18:18:28  from user="root" pass="123456"
2017-08-20 18:19:47  from user="root" pass="password"
2017-08-20 18:19:48  from user="root" pass="root"
2017-08-20 18:27:38  from user="root" pass="welc0me"
2017-08-20 18:27:40  from user="root" pass="rpitc"
2017-08-20 18:27:41  from user="root" pass="nosoup4u"
2017-08-20 18:27:44  from user="root" pass="default"
2017-08-20 18:27:46  from user="root" pass="rpitc"
2017-08-20 18:30:13  from user="root" pass="1q2w3e4r"
2017-08-20 18:30:16  from user="root" pass="default"
2017-08-20 18:30:18  from user="root" pass="abcd1234"
2017-08-20 18:31:09  from user="root" pass="raspberry"
2017-08-20 18:31:11  from user="root" pass="centos"
2017-08-20 18:31:14  from user="root" pass="changeme"
2017-08-20 18:41:42  from user="root" pass="1111"
2017-08-20 18:41:45  from user="root" pass="superuser"
2017-08-20 18:41:47  from user="root" pass="1qazxsw2"
2017-08-20 18:42:36  from user="root" pass="vagrant"
2017-08-20 18:42:39  from user="root" pass="power"
2017-08-20 18:42:41  from user="root" pass="Admin@123"
2017-08-20 18:53:02  from user="root" pass="qweASD123"
2017-08-20 18:53:05  from user="root" pass="rootme"
2017-08-20 18:53:07  from user="root" pass="zabbix"
2017-08-20 18:53:55  from user="root" pass="rootroot"
2017-08-20 18:53:58  from user="root" pass="123qweasdzxc"
2017-08-20 18:54:00  from user="root" pass="666666"
2017-08-20 19:04:31  from user="root" pass="qazwsx"
2017-08-20 19:04:34  from user="root" pass="1q2w3e4r5t6y"
2017-08-20 19:04:36  from user="root" pass="oracle123"
2017-08-20 19:05:26  from user="root" pass="pa55w0rd"
2017-08-20 19:05:29  from user="root" pass="abc"
2017-08-20 19:05:31  from user="root" pass="P4ssw0rd"
So my conclusion is that the "" module does not store password when login attempt is not allowed for user from IP.
Hence the data retrieved by the "pam_get_item" function is incorrect.

Of course I don't want to allow login from anywhere so I will revert my "sshd_config" file.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: How to monitor failed ssh login attempts on CentOS LXer Syndicated Linux News 0 08-25-2013 10:03 PM
[SOLVED] How to lock the users after ssh failed login attempts ? bala.linuxtech Linux - Security 7 12-07-2012 09:31 AM
Question about failed ssh login attempts natv Linux - Security 3 02-11-2007 07:46 AM
Failed SSH login attempts Capt_Caveman Linux - Security 38 01-03-2006 04:22 PM > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 10:51 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration