Friday, September 23, 2011 

Securing OpenSSH

OpenSSH (or Secure SHell) has become a de facto standard for remote access replacing the telnet protocol. SSH has made protocols such as telnet redundant due, in most part, to the fact that the connection is encrypted and passwords are no longer sent in plain text for all to see.

However, a default installation of ssh isn't perfect, and when running an ssh server there are a few simple steps that can dramatically harden an installation.

1. Use Strong Passwords/Usernames

One of the first things you'll notice if you have ssh running and exposed to the outside world is that you'll probably log attempts by hackers to guess your username/password. Typically a hacker will scan for port 22 (the default port on which ssh listens) to find machines with ssh running, and then attempt a brute-force attack against it. With strong passwords in place, hopefully any attack will be logged and noticed before it can succeed.

Hopefully you already use strong passwords, but if you are not then try to choose passwords that contains:

* Minimum of 8 characters
* Mix of upper and lower case letters
* Mix of letters and numbers
* Non alphanumeric characters (e.g. special characters such as ! " £ $ % ^ etc)

The benefits of strong passwords aren't specific to ssh, but have an impact on all aspects of systems security. Further information on passwords can be found in the CentOS documentation:

If you absolutely can't prevent your users choosing weak passwords, then consider using randomly generated or difficult to guess usernames for your user accounts. If the bad guys can't guess the username then they can't brute force the password. However, this is still security through obscurity and be aware of information leakage of usernames from things such as email sent from user accounts.

2. Disable Root Logins

SSH server settings are stored in the /etc/ssh/sshd_config file. To disable root logins, make sure you have the following entry:

# Prevent root logins:
PermitRootLogin no

and restart the sshd service:

service sshd restart

If you need root access, login as a normal user and use the su command.

3. Limit User Logins

SSH logins can be limited to only certain users who need remote access. If you have many user accounts on the system then it makes sense to limit remote access to only those that really need it thus limiting the impact of a casual user having a weak password. Add an AllowUsers line followed by a space separated list of usernames to /etc/ssh/sshd_config. For example:

AllowUsers alice bob

and restart the sshd service.

4. Disable Protocol 1

SSH has two protocols it may use, protocol 1 and protocol 2. The older protocol 1 is less secure and should be disabled unless you know that you specifically require it. Look for the following line in the /etc/ssh/sshd_config file, uncomment it and amend as shown:

# Protocol 2,1
Protocol 2

and restart the sshd service.

5. Use a Non-Standard Port

By default, ssh listens for incoming connections on port 22. For a hacker to determine ssh is running on your machine, he'll most likely scan port 22 to determine this. An effective method is to run ssh on a non-standard port. Any unused port will do, although one above 1024 is preferable. Many people choose 2222 as an alternative port (as it's easy to remember), just as 8080 is often known as the alternative HTTP port. For this very reason, it's probably not the best choice, as any hacker scanning port 22 will likely also be scanning port 2222 just for good measure. It's better to pick some random high port that's not used for any known services. To make the change, add a line like this to your /etc/ssh/sshd_config file:

# Run ssh on a non-standard port:
Port 2345 #Change me

and restart the sshd service. Don't forget to then make any necessary changes to port forwarding in your router and any applicable firewall rules.

Because ssh is no longer listening for connections on the standard port, you will need to tell your client what port to connect on. Using the ssh client from the command line, we may specify the port using the -p switch:

$ ssh -p 2345 myserver

or if you are using the fish protocol in konqueror, for example:


If you are thinking that this sounds like a pain having to specify the port each time you connect, simply add an entry specifying the port in your local ~/.ssh/config file:

# Client ~/.ssh/config
Host myserver
User bob
Port 2345

~/.ssh/config must have the following permissions:

$ chmod 600 ~/.ssh/config

6. Filter SSH at the Firewall

If you only need remote access from one IP address (say from work to your home server), then consider filtering connections at your firewall by either adding a firewall rule on your router or in iptables to limit access on port 22 to only that specific IP address. For example, in iptables this could be achieved with the following type of rule:

iptables -A INPUT -p tcp -s --dport 22 -j ACCEPT

SSH also natively supports TCP wrappers and access to the ssh service may be similarly controlled using hosts.allow and hosts.deny.

If you are unable to limit source IP addresses, and must open the ssh port globally, then iptables can still help prevent brute-force attacks by logging and blocking repeated attempts to login from the same IP address. For example,

iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource
iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT

The first rule records the IP address of each attempt to access port 22 using the recent module. The second rule checks to see if that IP address has attempted to connect 4 or more times within the last 60 seconds, and if not then the packet is accepted. Note this rule would require a default policy of DROP on the input chain.

Here's another example, this time using iptables limit module to limit the the number of connections to the ssh port to 3 per minute:

iptables -A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --syn -j DROP

The first line will accept new connections on port 22 provided that IP address hasn't made more than 3 connection attempts in the last minute. If more than 3 connection attempts have been made within the last minute, then the second line will DROP the connection.

Don't forget to change the port as appropriate if you are running ssh on a non-standard port. Where possible, filtering at the firewall is an extremely effective method of securing access to an ssh server.

7. Use Public/Private Keys for Authentication

Using encrypted keys for authentication offers two main benefits. Firstly, it is convenient as you no longer need to enter a password (unless you encrypt your keys with password protection) if you use public/private keys. Secondly, once public/private key pair authentication has been set up on the server, you can disable password authentication completely meaning that without an authorized key you can't gain access - so no more password cracking attempts.

It's a relatively simple process to create a public/private key pair and install them for use on your ssh server.

First, create a public/private key pair on the client that you will use to connect to the server (you will need to do this from each client machine from which you connect):

$ ssh-keygen -t rsa

This will create two files in your (hidden) ~/.ssh directory called id_rsa and id_rsa is your private key and is your public key.

If you don't want to still be asked for a password each time you connect, just press enter when asked for a password when creating the key pair. It is up to you to decide whether or not you should password encrypt your key when you create it. If you don't password encrypt your key, then anyone gaining access to your local machine will automatically have ssh access to the remote server. Also, root on the local machine has access to your keys although one assumes that if you can't trust root (or root is compromised) then you're in real trouble. Encrypting the key adds additional security at the expense of eliminating the need for entering a password for the ssh server only to be replaced with entering a password for the use of the key.

Now set permissions on your private key:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa

Copy the public key ( to the server and install it to the authorized_keys list:

$ cat >> ~/.ssh/authorized_keys

Note: once you've imported the public key, you can delete it from the server.

and finally set file permissions on the server:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

The above permissions are required if StrictModes is set to yes in /etc/ssh/sshd_config (the default).

Now when you login to the server you won't be prompted for a password (unless you entered a password when you created your key pair). By default, ssh will first try to authenticate using keys. If no keys are found or authentication fails, then ssh will fall back to conventional password authentication.

Once you've checked you can successfully login to the server using your public/private key pair, you can disable password authentication completely by adding the following setting to your /etc/ssh/sshd_config file:

# Disable password authentication forcing use of keys
PasswordAuthentication no

8. Frequently Asked Question (FAQ)

Q: CentOS uses version X of OpenSSH and the latest version is version Y. Version X contained a serious security flaw, should I upgrade?

A: No. The Upstream Vendor has a policy of backporting security patches from the latest releases into the current distribution version. As long as you have the latest updates applied for your CentOS distribution you are fully patched. See here for further details of backporting security patches:

9. Links

Thursday, June 09, 2011 

How to Save Flash Games & SWF

Saving Flash files from Firefox

Firefox for Newbies
a. Click Tools - Page Info
b. Click the Media Tab on the Page Info Windows
c. The media tab has a complete list (with preview) of Images, CSS Files and Shockwave Flash files that were downloaded by the Firefox browser while rendering (loading) the page.
d. Scroll down the list and locate the swf file.
e. Click the "Save As" button. Select some directory on your hard drive and save the file (No need for a third-party plug-in)

Firefox for Geeks and Power Users
a. Type about:blank in the Firefox address bar
b. Now click List cache entries or directly type about:cache?device=disk (Disk cache device)
c. Press Ctrl+F and try to location the flash file by typing some part of website URL or the flash file name or just .swf. After some hit and trial, you should be able to locate the swf file URL
d. Click the SWF URL to open the Cache Entry Information page. Right click on the link and choose "Save link as"

How to save flash in IE browser

a. Click Tools - Internet Options
b. In the General Tab, click the Settings button available in the Temporary Internet Files group.
c. Click View Files to open your Temporary Internet Files folder. Depending upon your IE settings, the Temp. folder can contain tens of thousands of files.
d. Click View - Details. Now click View - Arrange Icons By - Internet Address. Depending upon the webpage, there could one or more Flash files (Shockwave Flash Object) under the Inernet Address.
e. Once you find the right flash file, right-click and choose Copy. Then paste the swf file in any other directory. Be sure to
keep the page and IE open to avoid purging of the cache file.

For newbies, I suggest the following approaches:
1. Get a download accelerator like Flashget and tell it to automatically download the shockwave extention (*.swf)
2. Or download a free IE plug-in for saving flash files.

How to save Flash files from Opera or Google Chromebrowser
Just like IE, these browsers store the flash files in the browser cache.


Monday, January 17, 2011 

Converting 32bit RRD to 64bit RRD

Converting 32bit RRD to 64bit RRD (moving cacti between architectures)

On the 32 bit machine in /var/www/cacti/rra/ run in SSH:
for i in `find -name "*.rrd"`; do rrdtool dump $i > $i.xml; done
Transfer xml files to the other 64 bit machine and the same location.
On the 64 bit machine run in SSH:
for i in `find -name "*.xml"`; do rrdtool restore $i `echo $i |sed s/.xml//g`; done

Thursday, January 13, 2011 

Disable memory ballooning in VMWare

Connect directly to the ESX Server host where the virtual machine resides on, using Virtual Infrastructure Client (VI Client).
- Shut down the virtual machine.
- Right-click on the virtual machine listed on the Inventory panel and click Edit Settings.
- Click the Options tab and select General.
- Click Configuration Parameters.
- Click Add row and add the parameter sched.mem.maxmemctl in the text box.
- Click on the row next to it and add 0 in the text box.
- Click OK to save changes.

Thursday, August 05, 2010 

Backup Cisco IOS stored in diffent directory

1. To view flash content:

3550-SW1#dir flash:

Directory of flash:/

4 -rwx 796 Mar 01 1993 02:33:32 vlan.dat
5 -rwx 2783 Mar 01 1993 01:25:54 config.text
8 drwx 192 Mar 01 1993 00:04:30 c3550-i5q3l2-mz.121-14.EA1a
7 -rwx 2683 Mar 01 1993 02:35:26 config.old
86 -rwx 5 Mar 01 1993 01:25:54 private-config.text

2. To view sub-directory content:

3550-SW1#dir flash:/c3550-i5q3l2-mz.121-14.EA1a
Directory of flash:/c3550-i5q3l2-mz.121-14.EA1a/

9 drwx 2304 Mar 01 1993 00:03:03 html
84 -rwx 4086819 Mar 01 1993 00:04:30 c3550-i5q3l2-mz.121-14.EA1a.bin
85 -rwx 255 Mar 01 1993 00:04:30 info

3. To backup:

3550-SW1#copy flash:/c3550-i5q3l2-mz.121-14.EA1a/c3550-i5q3l2-mz.121-14.EA1a.bin tftp

Wednesday, July 21, 2010 

How to SFTP if the default ssh port is changed

Usually if the SFTP is enabled in your server, it will try to use the default port SSH port 22 even though the SSH port is changed to some other custom port.

root@localhost/~$sftp root@
Connecting to ...
ssh: connect to host  port 22: Connection refused
Couldn't read packet: Connection reset by peer

Here the SSH port is changed to 2200 instead of 22. But SFTP tries to connect it with 22. In this case we can connect to SFTP with the custom SSH port by running the following command.

root@localhost/~$sftp -oPort=2200 root@
Connecting to ...
root@'s password:


Upgrading Openssh on CentOS And Chrooting a User When Connecting via SFTP

Consider a scenario, where a user needs to connect to the server via sftp and should restrict the access only to its home directory. The OpenSSH-4.x does not support chrooting facility. We need to upgrade it to OpenSSH-5.x. Before upgrading openssh, we need to make sure that pam, openssl and kerberos packages are installed. If not, run the following command to install it.

$ rpm -qa | grep -e openssl -e krb -e openssh

$ yum install pam pam-devel krb5-devel

Yum will install all the dependency packages. Now, you are ready to upgrade OpenSSH.

Steps to Upgrade OpenSSH from 4.x - 5.x

1. Download latest OpenSSH package. You can select any mirror site from this link
     or You can use the link OpenSSH
2. Run the following commands.
$ tar -zxf openssh-5.4p1.tar.gz
$ cd openssh-5.4p1
$ ./configure --prefix=/usr/local/ssh --with-md5-passwords --with-pam --with-tcp-wrappers --with-kerberos5 --with-ssl-engine
$ make
$ make install

Prefix is important. We should not install the latest openssh to the default location.
3. Open the file "/usr/local/ssh/etc/sshd_config".
4. Change the default port to a non-standard ssh port, say 1234.
5. Save and quit.
7. Run the following command.
$ /usr/local/ssh/sbin/sshd -f /usr/local/ssh/etc/sshd_config

8. Make sure that both old and new version of SSH are running on the server.

$ ps aux | grep ssh
root     31987  0.0  0.0   7164  1032 ?        Ss   22:48   0:00 /usr/sbin/sshd
root     32280  0.0  0.0   5432   996 ?        Ss   22:48   0:00 /usr/local/ssh/sbin/sshd -f /usr/local/ssh/etc/sshd_config

9. OpenSSH  upgrade is complete.

Testing Phase

You should make sure that the upgraded version does not have any problem. Login to the server from your local konsole.

$ ssh -p 1234

You should login without any problem if the installation part went fine. Now, follow the steps given below to make the upgraded openssh to listen on default port.

1. Open /usr/local/ssh/etc/sshd_config
2. Change port to default port, i.e 22.
3. Save and quit
4. Kill or terminate all the instances of sshd running on the server.
5. Start the sshd server using the command "/usr/local/ssh/sbin/sshd -f /usr/local/ssh/etc/sshd_config"

Chrooting a User When Connecting via SFTP

To restrict a user to his home directory when he connects to the server via sftp, follow the steps given below.

1. Open the configuration file "/usr/local/ssh/etc/sshd_config".
2. Append the following lines to the configuration file.

Subsystem sftp internal-sftp
Match User testuser
        ChrootDirectory /var/www/html/test
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

3. You should comment the line: "Subsystem      sftp    /usr/local/ssh/libexec/sftp-server"
4. Save and quit.
5. Terminate the SSH server and start it again using the command:

/usr/local/ssh/sbin/sshd -f /usr/local/ssh/etc/sshd_config

6. Done

Test it using any FTP clients like WinSCP, FileZilla, CuteFTP and make sure that the user is restricted to his own home directory and he cannot access anything outside his home directory.

Note:- "/usr/local/ssh" is the prefix I used for new openssh installation. You should replace it with your prefix.

With the new openssh running on the server you should not start or restart the ssh using the init script. If you want to manage it via init script, edit the init script accordingly.

Open the file "/etc/init.d/sshd". Find the line 'prog="sshd"'. Below this line add "SSH="/usr/local/ssh". And replace the lines:


with the following lines:


Save and quit. Restart the openssh server using the command:

/etc/init.d/sshd restart

Confirm that the SSH server is started from the newly installed openssh i.e openssh 5.x.

$ ps aux | grep ssh
root     11791  0.0  0.0   5432   996 ?        Ss   Mar18   0:00 /usr/local/ssh/sbin/sshd

It will be better if you move the old ssh binaries and create a symlink to the new SSH binaries.

$ mv /usr/bin/ssh /usr/bin/ssh-bak
$ mv /usr/sbin/sshd /usr/sbin/sshd-bak
$ mv /usr/bin/ssh-keygen /usr/bin/ssh-keygen-bak
$ mv /usr/bin/ssh-agent /usr/bin/ssh-agent-bak
$ mv /usr/bin/ssh-keyscan /usr/bin/ssh-scan-bak
$ mv /usr/bin/ssh-add /usr/bin/ssh-add-bak
$ ln -s /usr/local/ssh/bin/ssh /usr/bin/ssh
$ ln -s /usr/local/ssh/sbin/sshd /usr/sbin/sshd
$ ln -s /usr/local/ssh/bin/ssh-keygen /usr/bin/ssh-keygen
$ ln -s /usr/local/ssh/bin/ssh-add /usr/bin/ssh-add
$ ln -s /usr/local/ssh/bin/ssh-keyscan /usr/bin/ssh-keyscan
$ ln -s /usr/local/ssh/bin/ssh-agent /usr/bin/ssh-agent

The upgrade and setup of OpenSSH is now complete.

Add to Google

The Author

  • Nick Perrydoo
  • Spawn at Philippines
My profile


Read Ons

Article of the Day

This Day in History

Today's Birthday

In the News

Quotation of the Day

Word of the Day

Powered by Blogger
and Blogger Templates
© Copyright 2006 Ba-zoo-ra - All Rights Reserved.