DevelHell

If you are connecting via SSH to multiple servers more often, it might be really annoying to enter you password everytime you want to connect to the server. Public key authentication is the right way to avoid remembering all the passwords and except of comfort it offers also much higher security level.

You can use public key authentication in two ways. You can generate key pairs without any password protection and for connection you just need to have your key on current computer, or you can use encrypted keys protected with one master password. It is possible to connect to multiple servers using one key pair, so you need to remember and enter everytime the same password. Let’s have a look how to achieve it.

Generating key pair

Just type:

If you want to encrypt your key with passphrase, type it or leave blank for no passphrase.

Handling multiple keys

What if you have to use more keys e.g. one for work and other one for you private servers? You can specify the file name even with additional comment:

But now your client does not know what key is for what server. One way is to try all keys for every connection. Execute for every key;

Of course, more elegant way is to filter keys by hostname directly in this config file, so open it and try to type something like this:

You can see that in config file you can specify even more than just your key file.

Pushing onto server

Last step is to push generated keys onto remote server.

This complicated command will connect to the server and execute given command which adds your public key to accepted keys list. Here are some parts of this command you should be aware of:

• .ssh/id_rsa.pub – your public key, use the correct file name
• mkdir -p .ssh – creates .ssh dir if it does not exist
• cat >> .ssh/authorized_keys – note that >> sign, it appends your key, so you can use multiple keys for one server

Conclusion

If you are using the same username on the server and host machine, from now you can connect with just one short command.

And that’s it, pretty simple, huh?

0

0

  

Apticron is a simple tool which generate a mail with a list of all packages which are currently pending an upgrade, as well as summary of changes to configured email address.

Installation

I will show you here how to install and configure Apticron on Debian based distros. We can install it using apt-get command:

To make Apticron working properly, we will need also some MTA client. Apticron package itself is dependent on exim4 and apt-listchanges packages. So in case that apt-get will not resolve dependencies during installation of apticron, we will install it like this:

Configuration

We will open configuration file of Apticron using our preferred editor (vim, emacs, …):

and we will edit these 2 lines with our email address where we would like to receive emails about new updates available for our system and with our FQDN (Fully Qualified Domain Name):

If we are not sure or do not know fully qualified domain name of the server, then we can find it out this way:

To be sure that we will receive email in case of new updates available, we need to check if cron entry is configured. During installation process there has been created file in /etc/cron.d and it should contain following line:

In case that there is no such file, then we need to create it and insert above line in there.
Now everything should be set and you should receive first email when new updates will be available.

0

0

  

Sometime happens, that you need to check your postfix mail queue if the email was send or maybe why it is still in the queue and was not send.

List mail queue

To list current mail queue, type:

Here is simple explanation from postqueue manpage what all fields means:

-p Produce a traditional sendmail-style queue listing. This option implements the traditional mailq command, by contacting the Postfix
showq(8) daemon.

* The message is in the active queue, i.e. the message is selected for delivery.
! The message is in the hold queue, i.e. no further delivery attempt will be made until the mail is taken off hold.

Remove mails from queue

You can either remove specific message from queue specified by message queue ID:

or you can remove all messages from queue:

Deferred queue

In case that Postfix is not able to deliver message to recipient, then this message is placed in so called deferred queue. Postfix is regularly checking deferred queue if some of those messages can be placed back in active queue for sending to recipient. Deferred queue can be listed as shown above by postqueue -p command. You can also find these messages stored in following directory:

To remove all messages only from deferred queue, type:

Now we can check and see that mail queue is empty:

0

0

  

Denyhosts is used by sysadmins very often, mostly with default configuration. And usually it is really enough, but when you are using your server as git repository and tons of users are accessing server via SSH, you probably have to tune it a little bit up.

Let’s think about some school server used for git repositories accessed via SSH. We will make some changes in denyhosts configuration file located under /etc/denyhosts.conf.

We recommend to set purging hosts.deny to 1 day, it’s enough to eliminate some attacks, but not to much for student without access.

Default value for max login attempts might be OK.

Admin email is very useful setting, you can be notified everytime a new record to hosts.deny is added. Note that you need to have set mail server correctly or use dedicated one. And also don’t forget to make a filter in your email client, you can be easily lost in hundreds of mails, setting custom sender and subject may help you with this task.

It is really good to set resetting on success, because if there are regular users with failed attempts (caused e.g. by wrong keyboard layout), they really aren’t trying to hack your server.

Everything else might be enough for now. We especially recommend to be aware of root logins – root should never log into system directly, so every attemt to login should be considered as possible attack.

And last note – be sure you have some machine with static IP where you can access your server from. You can always cut off yourself, so put your trusted IPs into /etc/hosts.allow and you will never be banned (enabled by default).

+5

0

  

For security purpose it is recomended to make at least some minor changes in SSH server configuration file, default ssh server config file is located under /etc/ssh/sshd_config.

We will change/add these lines:

Changing default SSH port can drasticly decrease login attempts to your server. Even better is to use port above 1000, scanning all available ports whether there is a running SSH server is very expensive, so attackers usually scan only up to port 1000 or just use standard one. If you have ever had public SSH server on port 22, you could see thousands of unsucessful logins a day in your auth.log file.

It is also strongly recomended to not allow root to login remotly. It is usually said, that the attacker has to guess not only password, but also the username. In my opinion, if root is allowed, you will use root for everything, not only for tasks what root is really needed for and that is really bad practice.

Last setting allows you to control what user can log into your system. There might be some user in your system without password (e.g. ftp, postgres etc.), using white list you don’t need to be worry anymore whether there is such user or not.

+1

0