A nice and easy solution which works best for me is to use sudo. This will allow to run rsync via ssh and sudo. To get it running you have to add an entry into your sudoers config file:

/etc/sudoers

backup_user ALL=(root)NOPASSWD:/usr/bin/rsync

This will allow the user backup_user to run the command rsync as root.

Next step is to add an rsync-path parameter to the remote rsync call:

rsync --rsync-path="sudo rsync" backup_user@myhosttobackup.net:/root /backup_directory

Finally rsync will automatically do an sudo to root on the remote server and all to backup all files owned by root as well.

Links:

• Rsync and sudo over SSH

The message appears every time rsync or just ssh is called. In my case the reason is that ssh tries to connect via IPv6 first and afterwards with IPv4. Since I’ve not setup IPv6 on my NAS the connect fails and the message above appears. It’s not a big harm but it’s nicer to remove this message.

Removing the message is esay, just add -4 as command line parameter to ssh:

-4 Forces ssh to use IPv4 addresses only.


For ssh or rsync the usage looks like:


ssh -4
rsync -e "ssh -4"


And the message disappears.

The reason seems that the IP address of my server has been added to a bot network which tries to hack servers using SSH brute force attacks. As far as I know such bot networks are built up  with Viruses and Trojans. I think there is no reason why your server may have also been added to such a list, somehow IP addresses seem to added.

But the question is how to defend against such brute force attacks from bot networks?

Known Methods

• Install a tool like denyhosts
• Always keep the SSH daemon up to date!
• Move the SSH port from 22 to some other port
• Disable password authentication and use key authentication
• Slow down the amount of connections from the same IP using iptables and module “recent”
• Open the SSH port after a trigger on a different port using iptables

I think there is one additional easy method to defend against such attacks. Why I think so? Read on..

Another Simple Method

When checking the auth.log we see that the user names of the attacks are taken from a dictionary:

Failed keyboard-interactive/pam for invalid user aderes from 195.xxx.xxx.xx port 39566 ssh2
Failed keyboard-interactive/pam for invalid user aderyn from 203.xxx.xxx.xx port 44099 ssh2
Failed keyboard-interactive/pam for invalid user adi from 78.xxx.xxx.xx port 42748 ssh2
Failed keyboard-interactive/pam for invalid user adia from 89. port 51028 ssh2
Failed keyboard-interactive/pam for invalid user adiel from 217. port 33861 ssh2
Failed keyboard-interactive/pam for invalid user adila from 77. port 52867 ssh2
It seems that the bots are not adding digits to the user names. So I think one easy method to defend against such attacks is:

• add at least one digit to user names on your server if you have the possibility

And definitely never ever add a user “admin”. In my logs the user “admin” is always used for brute force attacks:

Failed keyboard-interactive/pam for invalid user admin from 203.xxx.xxx.xx port 39711 ssh2
Failed keyboard-interactive/pam for invalid user admin from 203.xxx.xxx.xx port 55493 ssh2
Failed keyboard-interactive/pam for invalid user admin from 220.xxx.xxx.xx port 34502 ssh2
Failed keyboard-interactive/pam for invalid user admin from 80.xxx.xxx.xx port 51846 ssh2
Failed keyboard-interactive/pam for invalid user admin from 80.xxx.xxx.xx port 53934 ssh2

Definitely a useful tool for network administrator or people dealing with Linux servers: TouchTerm. Two versions are available: light and pro. I’ve running the light version on my iPhone. The pro version comes with gestures, additional plug ins and many more.

TouchTerm supports the landscape mode as well. SSH connections are managed with a session manager, which makes in unnecessary to enter host names for every connection.

Links:

• TouchTerm homepage
• TouchTerm SSH (iTunes link)
• TouchTerm Pro SSH (iTunes link)

Your desktop is running with Windows and you often need to connect remote servers using SSH then you will already know PuTTY. You will also know that it’s getting frustrating to enter the passoword every time. There is a simple way to login to remote machines using RSA/DAS keys.

What is needed?

First of all you will need to download the PuTTY.exe. And to generate the keys on your Windows desktop you’ll need to download  PuTTYgen.exe as well.

Key Generation

Start PuTTYgen.exe after download and press the Generate button. Now follow the instruction and move the mouse cursor over the desired area. I’ve used the default parameter [x] SSH-2 RSA with a key length of 1024 bits.

I leave the Key passphrase empty because I don’t want to enter any passwords during login.

To have the key later available for other servers use the “Save public key” and “Save private key” button. My private key is saved as haifisch.ppk and my public key as haifisch. By the way, haifisch is German and means shark.

Now mark the generated public key, copy it to the clip board and paste it into ~/.ssh/authorized_keys file on the remote server of the user you want to login as.

PuTTY Configuration

Keys have been generated and stored on the remote server, therefore PuTTYgen can be closed now and the PuTTY.exe is needed now.

In PuTTY under the item “Session” enter the host name of the remote server and connection type SSH. Next choose “Connection/Data” and enter the remote user name. Also the previously defined private key is needed, it is given in “Connection/SSH/Auth” using the “Browse” button. In my case it’s haifisch.ppk.

When all settings are done go back to “Session”, enter a name for this session and press “Save”.

That’s it. Try it by double clicking on the saved session.

Login via Desktop Icon

If you want to have a desktop icon which opens putty and logs into a remote server generate a file e.g. www.myserver.com.bat with the content:

start C:\temp\putty\putty.exe -load "Session Name in PuTTY"

Now generate a link to this batch file on your desktop and login in by double clicking.

Using debian Etch installation is really simple:

apt-get install denyhosts

Next edit /etc/denyhosts.conf and change:

PURGE_DENY = 1w
PURGE_THRESHOLD = 0

and start the daemon:

/etc/init.d/denyhosts start

That’s all. Sure it’s not a perfect solution which helps for everything, but nevertheless it will increase your security.

All you have to to now is wait and check the /etc/hosts.deny Depending on your configuration denyhosts will automatically delete expired entries.