Making your SSH days easier

Article was written on 4th march 2015

This article was originally posted in the old site during 2013 and may not reflect some changes in the more modern Linux and SSH versions. Use with caution.

If you are a admin like me who spends his days upkeeping one or more linux servers, you can easily become bored of a endlessly repeating tasks with the linux shells, repeating this and that from one day to another.

Here are my useful tips and tools to make your SSH’ing days less annoying and nicer.

Using aliases for host names and IP – addresses

One of the most annoying things I have encountered is to remember all the server IPs when doing maintenance work in the shell. I myself have several scripts across my servers which I need to keep sync, so from time to time I jump between servers and trying to remember all the IP addresses.

Replace red text with your server’s information, where aliasname can be anything you desire, shell-user is a username of the shell’s user, server-host-or-ip is a server’s hostn ame or IP address and server-ssh-port is a server port you want to use, usually defaults to 22.

Here is a example setup of above:

Host beta-server
User root
HostName 127.0.0.1
Port 22

After a setup above, I could easily SSH or SCP to the “beta-server” just by using it’s name on any SSH commands such as:

If you do not have password-free login (see below), you may need to add password parameters to any SSH commands you perform.

My password-less days: Login into SSH without a password

Logging into a server without a password firsts sounds like a terrible idea.. after a short inspection, you realize that it is actually a much safer than using passwords.

Generally making a SSH login without password means that you generate a RSA key-pair in your computer/server and send it to the shell you wish to login without a password. Authentication is done by verifying your RSA key with the key in the server, without needing to give chance to any brutal attacks which eventually may find out your server’s shell password.

Login to your computer / server from where you want to contact to another server / remote-host

Create public and private keys by entering command:

ssh-keygen -t rsa

Press enter to any/all questions it asks, such as passphrase question.

Copy the public key to the remote-host with command:

ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host

Replace remote-host with your target server’s IP or host name

Enter password to your target server for the last time ever

Test your newly made password-less SSH connection

ssh remote-host

Should work just fine If you have created aliases for hosts as described earlier, you can use aliases instead of host names. In the light of the alias-tutorial’s example, you could just “ssh beta-server” and need to do nothing more. No password. No IPs – just the feeling of being an awesome administrator.

Be safe – Change your SSH port

Most of the linux based servers with SSH shell still use the port 22 for connection, passwords or not. In every case, specially with password – based logins, this is a MAJOR security risk because there are “tenth-thousands” bots online and even more “hackers” trying to break into your system.

Best way to fix this is simply to change the SSH port where you make your connections. This is done VERY easily with the following instructions:

Edit your SSH daemon config:

pico /etc/ssh/sshd_config

Replace port 22 with any port number you desire

port 22 -> port 789

Remember that certain ports are reserved for other use, such as 25 for SMTP, 143 for IMAP, 80 for web-service .. and the list goes on. DO NOT use reserved port

Save file, restart SSH daemon

/etc/init.d/ssh restart

Done and done Was not too hard was it

Extra-tip: If you SSH between your servers and they all have non-standard SSH port in use, you can avoid entering annoying -p or -P parameter in SSH commands by editing /etc/ssh_config file and enabling/changing port 22 to something else. By doing this you do not need to enter custom port everytime to jump between servers.

Copying files between your servers in shell using SCP

If you have read earlier instructions above, you already know that you can make SSH connections between servers password-less and make aliases for your host names so you do not have remember .. basically .. almost anything specific .. with your servers.

Normally, if you have a basic password-authenticated normal IP-based setup, also known as “I have not tuned my server at all” – setup, you can use SCP to send files between servers with the following ways:

1. Sending a file /datafile from THIS server to a remote server 127.0.0.1 to folder /files with user shellusername can be done by this command:

SCP /datafile shellusername@127.0.0.1:/files

2. Getting a file /anotherfile from remote server 127.0.0.1 to the folder /home with user shellusername can be by this command

SCP shellusername@127.0.0.1:/anotherfile /home

With both above cases, you may need to enter password when asked if you do not have setup password-less login. If you have, as described above, setup up aliases for servers, use login without password between servers, you may just do as I do:

SCP /thislocalfile otherserver:/folder

No need to remember users, passwords, host names or IP addresses– you simply use alias for server name and transfer files easily.

Nice shell script for people with several servers and syncing

There are several ways to deploy files, scripts and basically everything between several different servers, but I like to do things my may: If I am to use a command or a tool to transfer critical files between servers, I want to know exactly what it does and how .. And that’s why, my friend paranoia, I created a shell scripts which just does that.

Following shell script, which you may freely use, custom or just throw into wall, copies file stated as a first parameter $1 to all servers to the folder stated in second parameter $2. Script uses previously setup password-less login, host aliases and SCP. Script structure is simply this:

Simple script and does all the work I need I know there are better, more reliable and better working solutions by I just like to keep things simple.

Conclusion

Phew.. This might be just a little bit longer post than I planned to write but at least it got all the common solutions you would need in a package .. and who knows, maybe I’ll even add some more tips for later use. Ta-ta for know.