Alias, making quick custom commands

Recently I placed my home computer on the Internet for a remote access but also to run a personal web page. The problem I had is while I enabled ssh access using only private keys, I was still worried that I might leave a loop hole open on the system.

So here I was constantly checking the logs for any alerts to SSHD service. The command I would run is something simple, "tail /var/log/messages | grep sshd".

The results would typically something as simple as a few lines but it would be important to keep up on. Here's an example.



$ tail /var/log/messages | grep sshd
Nov 25 03:13:59 server1 sshd[927]: error: PAM: authentication error for user from 192.168.1.100
Nov 25 03:14:06 server1 sshd[927]: error: PAM: authentication error for user from 192.168.1.100
Nov 25 05:50:25 server1 sshd[1299]: error: PAM: authentication error for illegal user root from 192.168.1.100

Now this is kinda of a long command to type out each time, I was wondering if I could just type something shorter?

Here's where the alias command comes into play. From your terminal, you can type "alias" and find out what are your current alias commands. 

$ alias

g='egrep -i'

h='fc -l'

j=jobs

l='ls -l'

ll='ls -laFo'

m=more

We're now going to add our search command as listed above, but make an alias to "searchsshd". 

$ alias searchsshd='tail /var/log/messages | grep sshd'

Now, when we type "searchsshd" we get the following. 

$ tail /var/log/messages | grep sshd
Nov 25 03:13:59 server1 sshd[927]: error: PAM: authentication error for user from 192.168.1.100
Nov 25 03:14:06 server1 sshd[927]: error: PAM: authentication error for user from 192.168.1.100
Nov 25 05:50:25 server1 sshd[1299]: error: PAM: authentication error for illegal user root from 192.168.1.100

Pretty cool! 

Rob

Hard links vs Symbolic links

Working with Linux and UNIX offers some handy extras not typically found on Windows based systems. One great feature is hard and soft links, which is somewhat like a shortcut that you can create but looks just like a normal file.

This works great when you need to share a file but do not want to give permissions to the file directly. So how does this work? Every file on a Linux or UNIX based system is mapped to an inode. Inodes are the identification of every single file and object on the system. This includes users, files, rights, etc.

To see the inode values, you can run the command "ls -i".


rob@robmint ~/sandbox $ ls -li
total 4
2098382 -rw-r--r-- 1 rob rob 5 2011-11-30 17:29 testfile

The file "testfile" has a inode value of "2098382".

Now there are two different links we can create. One is a hard link, the other is a soft link. Here's the difference.

Hard link - These are files associated to the same inode. They are duplicate files and are independent from the original file. Also as you can see below, look the same but there is a slight hint.

Let's first create the hard link using the "ln" command.


rob@robmint ~/sandbox $ ln testfile testfilehardlink

Now let's see what we created. 

rob@robmint ~/sandbox $ ls -li
total 8
2098382 -rw-r--r-- 2 rob rob 5 2011-11-30 17:29 testfile
2098382 -rw-r--r-- 2 rob rob 5 2011-11-30 17:29 testfilehardlink

Again, we see the inode information is the same, but also note the value of "2". Which tells us that the original file "testfile" is linked two times, once to "testfile" and another to "testfilehardlink". 

So we mentioned that hard links are duplicates of the original file, but what happens when we delete the original file? Let's find out. We will delete the file "testfile" and leave behind "testfilehardlink".


rob@robmint ~/sandbox $ rm testfile
rob@robmint ~/sandbox $ ls -li
total 8
2098382 -rw-r--r-- 1 rob rob  5 2011-11-30 17:29 testfilehardlink

Now let's see if we can access "testfilehardlink". 

rob@robmint ~/sandbox $ cat testfilehardlink

1234

It works! Now, even after deleting the original, you can still access the data. But this looses the benefit of using link since now the file is no longer being updated from the original file. 

So now we know hard links, what about soft links? Let's create the soft links using the "ln -s" command. 

rob@robmint / $ ln -s testfile2 testfilesoftlink

Now let's look at the soft link we created. Notice how there is a visual reminder that it's a soft link. 

rob@robmint ~/sandbox $ ls -li

total 8

2097736 -rw-r--r-- 1 rob rob 10 2011-11-30 17:41 testfile2

2098382 -rw-r--r-- 1 rob rob  5 2011-11-30 17:29 testfilehardlink

2098638 lrwxrwxrwx 1 rob rob  9 2011-11-30 17:48 testfilesoftlink -> testfile2

Here we created the the soft link, but let's see how this works if we delete the original file. 

rob@robmint ~/sandbox $ rm testfile2

rob@robmint ~/sandbox $ ls -li

total 8

2098383 -rw-r--r-- 2 rob rob 5 2011-11-30 17:50 testfile

2098383 -rw-r--r-- 2 rob rob 5 2011-11-30 17:50 testfilehardlink

2098638 lrwxrwxrwx 1 rob rob 9 2011-11-30 17:48 testfilesoftlink -> testfile2

Now the original file is deleted, let's try to access the file "testfilesoftlink".


rob@robmint ~/sandbox $ cat testfilesoftlink
cat: testfilesoftlink: No such file or directory

As you can see, once the original file is gone, so it the soft link file. This is because the soft link is a link to the inode, not a duplicate file. 

Now, why would you want to use soft links over hard links? Soft links are a path back to the file, not to the inode, which means that you can access links across partitions. It's pretty cool feature and when working with longer path names this could be extremely handy. 

Rob

SSH access with keys and no password

One of the most handy things about SSH access is setting up the secure keys, allowing to bypass the password but keep a very secure access to the host. This allows a fast connection to the host, but also since you're using a security key, no one else will have access.

For a while I was having issues setting this up, I knew that you needed to create the keys but not sure how to setup ssh access further. So I setup a home server, using FreeBSD 8.2 at home and running a port forwarding from my home router. I wanted to keep this secure as possible, but also allow access from any location, so I could access my home system remotely. 

So here's the steps I used and hoping this will be helpful. 

First, if you're on a Windows system there might be some issues creating the keys. You can make keys from Putty but there is some differences, mostly you will need to rename the files and make some additional editing. In these examples I created the keys on a Ubuntu based system and accessing a FreeBSD host. Please note "user" is your account name and "hostname" is the machine name. 

Before starting, make sure you have your remote host setup if needed. Here I'm working on a home machine so I need to first edit the SSH service file located at /etc/ssh/sshd_config. I recommend using your favorite text editor, and will be listing only the important options below. 

First, make sure root SSH login is disabled, and only allowing your account to be listed. 

AllowUsers user

We are also going to disable password authentication. 

PasswordAuthentication no

Also allow RSA keys.

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile      .ssh/authorized_keys

Save the file and restart sshd service. Now consider if you are accessing a company server the details will be different and these setup steps for the host might be already done. 

From your personal computer. 

1) Login to a host and access the terminal or console.

2) From you're home directory, run the following command.

user@hostname ~ $ ssh-keygen -t rsa

3) As seen below, you will be asked for the following details. You can take the defaults and press "enter" all the way through. If you would like added security, enter a passphrase when prompted. 

user@hostname ~ $ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/user/.ssh/id_rsa): 

Enter passphrase (empty for no passphrase): 

Enter same passphrase again: 

Your identification has been saved in /home/user/.ssh/id_rsa.

Your public key has been saved in /home/user/.ssh/id_rsa.pub.

The key fingerprint is:

[random letters and numbers] user@hostname

The key's randomart image is:

+--[ RSA 2048]----+

[random image]

4) Now check your directory and you should see the following files. The specific path is listed above as "/home/user/.ssh" directory. We are using the "a" option to view the .ssh directory since it is hidden. 

user@hostname ~ $ ls -la

drwx------  2 user  user       4096 2011-11-25 15:18 .ssh

5) So we have the directory there, now let's check for the files. We are going to change directory to .ssh and look for the files.

user@hostname ~/.ssh $ cd .ssh

6) We are looking for what files are in the directory. 

user@hostname ~/.ssh $ ls -l

total 20

drwx------  2 user user 4096 2011-11-25 15:18 .

drwxr-xr-x 57 user user 4096 2011-11-25 14:55 ..

-rw-------  1 user user 1675 2011-11-25 15:18 id_rsa

-rw-r--r--  1 user user  393 2011-11-25 15:18 id_rsa.pub

-rw-r--r--  1 user user  884 2011-11-25 15:01 known_hosts

7) We have two hosts that are important. id_rsa and id_rsa.pub, these are the two files which we created and will need to access remote hosts. 

id_rsa - This is your private key, you keep this on the computer that you are using to access other computers. This is a secure file not to be shared on remote systems but only on hosts you are using for clients. 

id_rsa.pub - This is the public key, you place this file on remote systems that you want to access remotely. 

8) Now we have the two files needed, we're going to copy the id_rsa.pub file to our remote system. This command will copy the files from your local id_rsa.pub to the remote host. 

user@hostname ~/.ssh $ cat id_rsa.pub | ssh user@192.168.1.1 'cat >> .ssh/authorized_keys'

Password:

There is a possibility this might fail. Make sure that under your home directory on the remote system you have .ssh directory and the file authorized_keys already created. If they are not there, then create them as needed. Below, run the commands from your home directory. 

user@hostname ~ $ mkdir .ssh

Now we are going to lock down the directory

user@hostname ~ $ chmod 700 .ssh

Now go inside the .ssh directory

user@hostname ~ $ cd .ssh

We are going to create a blank file to store the keys

user@hostname ~ $ touch authorized_keys

Again, we are going to lock this file down as well 

user@hostname ~ $ chmod 600 authorized_keys

Now try the command listed in step 8 again. This should work. 

9) Now try to ssh into the server again, you should not be prompted for the password and go straight to the terminal session. 

Hope this saves you time and keeps your system secure. 

Rob