Archive for the ‘Unix’ Category

Advanced SSH security tips and tricks

Change SSH listening port

By default, SSH listens for connections on port 22. For security reason person can change the port for listening. Then other person connecting from the network have to specify the port number otherwise connection will be refused.

Open the /etc/ssh/sshd_config file and look for the line that says:

Port 22

Change the port number and restart the SSH service:

/etc/init.d/ssh restart

Suppose new port number is 222. Then only those person can connect to my PC who knows my new PORT number. Then person have to specify the port number while connecting via SSH

mishu@mishu:~$ ssh picklu@
ssh: connect to host port 22: Connection refused // as I made change in the listening port.

mishu@mishu:~$ ssh -p 222 picklu@
picklu@’s password: // when particular port number is given then it gives the password prompt.

Allow only SSH protocol 2

There are two versions of the SSH protocol. Using SSH protocol 2 only is much more secure.

Edit /etc/ssh/sshd_config and look for the line that says:

Protocol 2,1

Change the line so it says only protocol 2.

SSH with graphical interface

If any one is willing to access the remote PC with graphical interface then user have to use a switch -Y.

command is like this

picklu@picklu:~$ ssh -Y mishu@mishu

Allow only specific users to log in via SSH

User should not permit root logins via SSH, because this is a big and unnecessary security risk. Configure SSH server so that root user is not allowed to log in. Find the line that says:

PermitRootLogin yes

Change yes to no and restart the service. You can then log in with any other defined user and switch to user root if you want to become a superuser.

If you would like to have a list of users who are the only ones able to log in via SSH, it can also be specified in the sshd_config file. For example, let’s say I want to allow users mishu, and rumee to log in via SSH. At the end of sshd_config file I would add a line like this:

AllowUsers mishu rumee

Using DSA/RSA public key authentication

Instead of using login names and passwords for SSH authentication, user can use DSA/RSA public keys for authentication. Note that user can have both login names and DSA/RSA public key authentication enabled at the same time. User need a pair of DSA/RSA keys — one public and one private. User keep the private key on your machine and copy the public key to the server or other machine where s/he wants to login. When user wants to log in to an SSH session, the server checks the keys, and if they match, you are dropped into the shell. If the keys don’t match, you are disconnected.

In this example the private machine (from which I will connect to the server/other machine) is station1 and the server machine is server1. Procedure is following:

First I need to create a pair of keys on my private machine.

picklu@picklu:~$ ssh-keygen -t rsa

There will be prompted for a pass-phrase for your private key, but it can be blank because this is not a recommended method. A key pair is generated: private key is located in ~/.ssh/id_rsa and your public key is located in .ssh/

Next, copy the contents of ~/.ssh/ to server1 into the ~/.ssh/authorized_keys file.

If the file ~/.ssh/authorized_keys already exists, append the contents of the file ~/.ssh/ to the file ~/.ssh/authorized_keys on server1 by following command.

cat >> .ssh/authorized_keys

The only thing left to do is to set the correct permissions of ~/.ssh/authorized_keys file on server1:

~$ chmod 600 ~/.ssh/authorized_keys

Now, configure the sshd_conf file to use the DSA/RSA keys authentication. Make sure you have the following three lines uncommented:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Restart the service. If everything configured correctly, user should now be able to SSH to the server without any interaction.

If you would like to use DSA/RSA authentication only, make sure you uncomment and change the PasswordAuthentication line in sshd_config from yes to no:

PasswordAuthentication no

If anyone tries to connect to your SSH service and doesn’t have a public key on the server, he will be rejected without even seeing the login prompt with this error:

Permission denied (publickey).

N. B. If .ssh or its parent directory is group writable then this will not work.

Create a custom SSH banner

If you would like any user who connects to your SSH service to see a specific message, you can create a custom SSH banner. Simply create a text file (in my example in /etc/ssh-banner.txt) and put any kind of text message in it; for example:

*This is a private SSH service. You are not supposed to be here.*
*Please leave immediately. *

When done editing, save the file. In the sshd_conf file, find a line that says:

#Banner /etc/

Uncomment the line and change the path to your custom SSH banner text file.

Categories: Unix


In computing, a shebang (also called a hashbang, hashpling, or pound bang) refers to the characters “#!” when they are the first two characters in a script file. Unix-like operating systems take the presence of these two characters as an indication that the file is indeed a script, and attempt to execute that script using the interpreter specified by the rest of the first line in the file. For instance, Bourne shell scripts always start with the first line:


More precisely, a shebang line consists of a number sign and an exclamation point character (“#!“), followed by the (full) path to the interpreter program that will provide the interpretation. The shebang is looked for and used when a script is invoked directly (as with a regular executable), and largely to the end of making scripts look and act similarly to regular executables, to the operating system and to the user.

Example shebang lines

Some typical interpreters for shebang lines:

  • #!/bin/bash — Execute using the Bourne-again shell
  • #!/bin/bash -c '/bin/bash' — Execute using bash in the /bin/ directory, and calls bash inside the /bin/
  • #!/bin/csh — Execute using csh, the C shell
  • #!/bin/ksh — Execute using the Korn shell
Categories: Unix

remote copy using rsync

Sometimes its better to use rsync then scp command for copying file from remote machine where bandwidth is one of the issue. You can specify the bandwidth usage in the rsync but this facility is not available in scp.

command format:

rsync [OPTION]…bwlimit=XX [USER@]HOST:SRC DEST

-v, –verbose increase verbosity
-a, –archive archive mode; same as -rlptgoD (no -H, -A)
-u, –update skip files that are newer on the receiver
-r, –recursive recurse into directories
-e ssh = specify the remote shell to use
–bwlimit=KBPS limit I/O bandwidth; KBytes per second

e.g.: rsync -av bwlimit=XX -e ssh user@host:/path_of_the_SRC_file /path_where_it_will_stored

Some times you will find error like rsync: fatal: open failed: No such file or directory
i.e. no libgcc found on /usr/local/lib and rsync always look for on /usr/local/lib
Then simply make a soft link
ln -s /usr/sfw/lib/ /usr/local/lib/ [on Sun host only]

Categories: Ubuntu, Unix

Port forwarding through ssh

There are two kinds of port forwarding: local and remote forwarding. They are also called outgoing and incoming tunnels, respectively. Local port forwarding forwards traffic coming to a local port to a specified remote port.

For example, if you issue the command

ssh2 -L 1234:localhost:23 username@host

all traffic coming to port 1234 on the client will be forwarded to port 23 on the server (host). Note that localhost will be resolved by the sshdserver after the connection is established. In this case localhost therefore refers to the server (host) itself.

Remote port forwarding does the opposite: it forwards traffic coming to a remote port to a specified local port.

For example, if you issue the command

ssh2 -R 1234:localhost:23 username@host

all traffic which comes to port 1234 on the server (host) will be forwarded to port 23 on the client (localhost).

It is important to realize that if you have three hosts, client, sshdserver, and appserver, and you forward the traffic coming to the client’s port x to the appserver’s port y, only the connection between the client and sshdserver will be secured. See Figure Forwarding to a third host. The command you use would be something like the following:

ssh2 -L x:appserver:y username@sshdserver

Categories: Unix

Checking any particular port is listening or not

telnet IP_address port_number

Then you can see the following message if everything is OK.

Trying IP_address…
Connected to IP_address.
Escape character is ‘^]’

If we press the Escape character then we will get a promt screen to execute command in that box.

press Ctrl+d to exit.

Categories: Unix

Runing GUI package problem in another user mode

To change a user shell

chsh -s /bin/bash

you are login with user picklu and now a you want to run a GUI package with user mishu and the GUI fails. There are two ways to solve this issue:

1. cd /home/picklu

cp .Xauthority /home/mishu


2. xhost +x

export DISPLAY=:0.0

then run the package. Then you can get the GUI interface of the installer.

Categories: Unix

"sudo" without password…

If user is willing to work with sudo command without password then some change is needes in /etc/sudoers file.

# User privilege specification
root ALL=(ALL) ALL
picklu ALL=(ALL) NOPASSWD:ALL //this line is added for picklu user

Categories: Unix