Category Archives: SSh

Background Noise on the Internet

Not too long ago there was a reasonable amount of press ( in the IT world anyhoo, meatspace pretty much ignored it ) regarding attacks against the SSh protocol. The “SShPsychos” group has been responsible for a large number of coordinated brute force attempts against well known usernames with a variety of common passwords. This isn’t long term targeted attempts against a particular target – rather a scatter-gun approach at anything that’s running an SSh daemon on Port 22 using a short-ish list of dumb passwords.SSh "hack" from the Matrix

To be honest, I’d known about this sort of background level for a long time – and it came as no great surprise to me. It’s been going on as long as I’ve had an SSh server running on a public IP, and to be fair the volume _has_ increased. It has been a great example to students though when I’ve been teaching Linux security – pointing out the reasons for carrying out the basics of securing SSh:

  1. No remote root login
  2. Complex passwords
  3. Specific IP firewall rules if/where possible

And also some of the more complicated ones:

  1. Fail2Ban
  2. Chroot Jails
  3. Multi-Factor Authentication

Even now, logging into my webserver ( “” ) via SSh on Port 22 there are approximately 2000 illegitimate login attempts over the last 20 hours. Quite often when I re-connect after a weekend or more than a few days, this number is in the 10s to even 100s of thousands. I’ll be honest, it doesn’t particularly bother me – it is much rattling of windows and testing of locks – there are much easier fish to fry on the interwebs than that particular machine.

It did cause me to ask two particular questions though:

1) Where are all the attacks coming from ?

2) What usernames and passwords are they trying ?

Turns out that question 1 is easy, and question 2 is half easy …

On any Linux server, the connections made against SSh are logged. These go into /var/log/secure and here is a prime example:

May 15 14:35:55 ts-one sshd[23429]: Invalid user bankid from
May 15 14:35:55 ts-one sshd[23429]: input_userauth_request: invalid user bankid [preauth]
May 15 14:35:55 ts-one sshd[23429]: pam_unix(sshd:auth): check pass; user unknown
May 15 14:35:55 ts-one sshd[23429]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=
May 15 14:35:57 ts-one sshd[23429]: Failed password for invalid user bankid from port 59470 ssh2
May 15 14:35:57 ts-one sshd[23429]: Received disconnect from 11: Bye Bye [preauth]

This is one connection attempt – the source ( from ) is, and it has presented the invalid user “bankid” – this has actually failed at this point – but SSh won’t let the attacker know that, it will still allow them to enter three password attempts before terminating the connection. This inability to tell if it is the username or the password that has failed is actually quite important – realise that if you can tell if an account is valid, then you can easily stop wasting time and effort on ones which are not. This non-specific failure method “Either the username or the password is wrong” leaves the whole possible space open requiring a far greater number of attempts to find a valid username _and_ password combination. – great IP address – I’m sure that there are some savants out there who can look at that and tell me where it is from – but I assure you, I am _not_ one of them. I have to look it up – and even then the sources occasionally disagree ( not that it actually really matters as I’m not sending a drone over to wreak revenge ).  For the purposes of the remainder of this process I’ll be using the MaxMind database, and, for the sake of legal compliance:

This product includes GeoLite2 data created by MaxMind, available from
Creative Commons Licence
This data is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

There is a direct interface to the data that is available on the front page of the MaxMind website which allows for the query of a single IP address, and, for us in the case above, this tells us:

IP Address =
Country Code = FR
Location = France, Europe
Coordinates = 48.86, 2.35
Organization = OVH SAS

So it is a French IP address hosted with the OVH Company.

Our friends in France ...

Our friends in France …

As a hosting company, they aren’t directly responsible for the attack, rather it is just being launched from a machine that has been allocated an IP address within their scope. However, having said that, a quick glance at a Google search about them suggests that this is far from the first time that they have been used as a stepping stone onto other things …

The IP address lookup also gave us the Lat / Long ( estimated – by a long shot ! ) of the address. We can plug these into Google Maps to have a look-see at the rough area of operation _of the IP address_. This isn’t, most likely, where our perpetrator is sitting – more likely the recorded head office of the company …

Our location in Paris...

That’s great one IP address down – 2000 to go …

In the next articles in this series, I’m going to extract all of the IP addresses & usernames from the logs ( across multiple servers ! ), and then plot these against a map to show both historic and real-time data … And then we’re going to move on to finding out what passwords are being attempted using a “honeypot” !

Tagged , , , ,

SSh Tunnelling for fun and profit …

Firewalls are good – firewalls that are outside of your control, aren’t. I’ve been working with a client to install a network monitoring device within their network – unfortunately they have no sensible way of giving me access to it through the firewall – no available routable IPs, no port forwarding, nothing useful what so ever. This has somewhat cramped my style – making it a pain to get to the device in any way other than being in their offices. Well, I had to be there for a few days anyway – but I finally got round to implementing the solution to the problem today. I’ve used SSh tunnels for over 15 years now, originally between university Unix boxes and Linux servers at the ISP that I worked for part-time so that I could do things all round ( Uni work in the office, office work from Uni … both from home via dial-up to work … nothing from the student union because mobile computing hadn’t been invented & the beer was cheap … ) – and every so often I end up revisiting them to either (a) bypass other people’s security controls or (b) to tunnel unencrypted protocols over a secure channel. The really nice thing about SSh tunnelling is that it is actually pretty platform agnostic – PuTTY & Cygwin on Windows, MacOS X, Linux, UNIX and even Android – all have support for it one way or another.

I have always admired the programmers virtues, despite not being a programmer myself much – I feel that they should apply to all who work in IT – laziness, impatience and hubris. And in the spirit of the first, on this occasion, rather than reading the man pages and trying to recall how it all hangs together – I went to the ultimate lazy resource ( Google ) and found this script here:


# $REMOTE_HOST is the name of the remote system

# $REMOTE_PORT is the remote port number that will be used to tunnel
# back to this system

# $COMMAND is the command used to create the reverse ssh tunnel
COMMAND="ssh -q -N -R $REMOTE_PORT:localhost:22 $REMOTE_HOST"

# Is the tunnel up? Perform two tests:

# 1. Check for relevant process ($COMMAND)
pgrep -f -x "$COMMAND" > /dev/null 2>&1 || $COMMAND# 2. Test tunnel by looking at "netstat" output on $REMOTE_HOST
ssh $REMOTE_HOST netstat -an | egrep "tcp.*:$REMOTE_PORT.*LISTEN" \
   > /dev/null 2>&1
if [ $? -ne 0 ] ; then
   pkill -f -x "$COMMAND"

This, coupled with a cron job to run it every five minutes and shared keys mean that my tunnel now remains open on my server, allowing me to get in remotely, fiddle with things move files etc. etc. etc.

Ironically, though, rather than making my life easier this now means that I can worry about what it is doing at 3am _and find out_ !

Tagged , , , , , , , , ,