Archive for the ‘linux’ Category

Securing SSH Sessions The Easy Way

By: Terry Bytheway

Recently I’ve had a good deal of people ask me about SSH connections, and how they can better secure them, and I’ve been shocked at the sheer number of people that still use keyboard-interactive password authentication to log into SSH daemons. This article will explain the use of SSH keys and OpenSSH options to speed up and secure your SSH connection.

SSH options

There are a few useful options you can pass to OpenSSH to increase your verbosity, compress and speed up your ssh connection, and change your SSH cipher to something faster and more secure;

‘-v’ switch. This option will allow you to see debug output for outgoing SSH connections. Specifying ‘-v’ multiple times increases the verbosity level (maximum level 3).

‘-C’ switch. This option compresses all of your SSH data. Passing this option to OpenSSH may speed things up dramatically on slow networks, but on high-speed networks it will only slow things down.

‘-c’ switch. This option will allow you to change your cipher method. The default is 3des, which is a 3-way encryption method that is believed to be secure – however, blowfish is also available, which is a fast block cipher which also believed to be very secure and is far faster than 3des.

For example, let’s say I want to log in as user ‘foo’ to an ssh daemon on host ‘example.com’. I want maximum verbosity level, I want to compress all my data, and I want to change my SSH cipher to blowfish. The command would look like this:

ssh -vvv -C -c blowfish -l foo example.com

(Note: the higher your verbosity level, the more text you will get on your terminal while OpenSSH goes through the process of logging in to the remote SSH daemon. Even specifying only one -v can get you a veritable flood of information. Fiddle around with -v until you find a debug level that you’re comfortable with.)

SSH keys

OpenSSH supports a method of authentication far more secure than keyboard-interactive password authentication using a combination of public/private key cryptography. A pair of keys is generated, one on the remote machine to authenticate you and let you in. The other is a private key to match the key on the remote machine.

To generate a pair of cryptographic keys, you would use the ssh-keygen(1) utility on both the machine you intend to log in to, and the machine you intend to log in from. For example;

ssh-keygen -t rsa

The -t option specifies the type of key to be generated. Available options are dsa and rsa.

Inputting this command on either of your UNIX machines should give you an output like this:

$ ssh-keygen -t rsa

Generating public/private rsa key pair.

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

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

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

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

Setting a passphrase is highly recommended to maximize security. Good passphrases are between 10 and 30 characters long, and are not easily guessable in any way. If you do not enter a passphrase, you will be able to login to your remote system without entering any password on login.

The next step is to authorize your keys on the remote machine you intend to log in to. You can do this using a file named authorized_keys on your target machine. Copy your ~/.ssh/id_rsa.pub file onto your remote machine using scp(1)

scp ~/.ssh/id_rsa.pub example.com:.ssh/authorized_keys

Now log in to your target machine using ssh(1) with a debug level of 1

as previously shown;

ssh -v -C -c blowfish -l foo example.com

You will see debug messages like so;

debug1: Authentications that can continue: publickey,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering public key: /home/example/.ssh/id_rsa

debug1: Server accepts key: pkalg ssh-dss blen 435

debug1: read PEM private key done: type rsa

You should then be prompted for your key passphrase (if you entered one) and then let into the system. If you didn’t enter a passphrase upon generating your public/private keys, you will be passed through without having to enter any. If you encounter errors, you should check the permissions of your ~/.ssh directories on both machines.

If you wish to change your key passphrase at any time, you can do so by passing the -p flag to the ssh-keygen utility;

ssh-keygen -p

About the Author

LinksJuice Security Directory for related websites with tips & advice on security. The security directory is located under the Computers & Internet directory.

(ArticlesBase SC #172422)

Article Source: http://www.articlesbase.com/ – Securing SSH Sessions The Easy Way

Understanding Linux and Windows Towards Web Hosting

Author: WebHostingGeek

A Linux based hosting service can be appreciated if you have a true understanding about it. Linux is an open source operating system. There are no licensing fees for it. So, compared to windows, Linux is very cheap. Windows have software activation rights. A single copy of windows can be installed only on one computer. In the case of Linux once you have owned the software copy, you are free to install the software as many times as you wish on various computers.

On the other hand, Windows has a monolithic design, whereby it creates a sort of interdependence between the various parts of the server. A practical example can be seen in windows media player and Microsoft Internet explorer. In the case of Linux, it is known for its open source community development. Due to its group oriented approach method, Linux can easily oppose the monolithic based design concept by creating an operating system made up of parts that are freely independent of each other.

Linux and windows can successfully run popular web technologies such as HTML, CSS DHTML, XHTML, XML, JAVA Script, JAVA, CGI and Perl. They can also support Email, FTP, reporting and other basic features too. Also, both the operating systems (Linux and windows ) can do a good job when it comes to interfacing with Microsoft front page. Linux deals with open source development method, such as PHP nad RUBY on rails. Mostly, the Linux based databases use MYSQL. On the other hand, windows deal with ASP and other Microsoft proprietary applications such as Microsoft exchange. Window based databases mostly rely on MS SQL. When it comes to talking about the security risks involved on servers, one must be aware of the fact that one cannot ensure a 100 % risk free security service. I am saying this because even today there exist unskilled server administrators; people involved in brute force password crackers, unsecured PHP or ASP scripts etc.

In a windows based system, it becomes easy for hackers to compromise and entire server. The IIS web server is deeply interconnected with the core of the windows. Hence, if a security threat is found in the IIS web server, it could lead to compromising the entire windows server. That is why, external browsers such as Mozilla, Fire Fox are considered to be safer for a window PC than the integrated Microsoft Internet Explorer. Now in the case of a Linux security based system, there exists a large as well as an educated security team. However, one must also be aware of the fact that there exists a group of educated community of hackers too.

Linux is mainly used for database servers and Internet servers. Many companies prefer to use Linux on their servers as an alternative to other operating systems. Linux can be considered as a very efficient, multi-user multitasking operating system. Linux is popular on the internet as well as by many small companies. Linux is very stable and it uses the resources very efficiently. Linux is compatible with Microsoft windows, whereby it can support fully access to windows file system. Linux runs efficiently on your present hardware. Your older machines can also work on Linux.

In other words, your old hardware which might have discarded just because it was in adequate for the latest software upgrades can now be a valuable resource for your company. You can put your hardware back in service with Linux. Web hosting service based on Linux is easy and cheaper than windows hosting. It is a better choice over windows.

Article Source: http://www.articlesbase.com/web-hosting-articles/understanding-linux-and-windows-towards-web-hosting-383663.html

About the Author

Web Hosting Rating – the top web hosting on internet have web hosting reviews and scores of stuff on hosting.

Installing and Configuring the Secure Shell Server

Author: Christopher Pace

The Secure Shell (SSH) Server is a secure replacement for telnet and rlogin, etc. SSH uses encryption from the point the client connects to a server, to the time the connection is terminated. SSH uses encryption to hide passwords, usernames, and other sensitive information that is normally sent “in the clear” in servers such as telnet and rlogin. SSH as of this writing supports the following encryption algorithms: 3DES, Twofish, Blowfish, Arcfour, CAST128, AES (Rijndael), and DES. SSH now comes with a variety of distributions, so downloading the server and the client should be a pinch. If, however, your distribution lacks a SSH server package, you may download it from the SSH website. SSH is one of the more easier to install packages, so installation should be a breeze. Install the package from your distribution using the appropriate package manager (for example use rpm -i packagename for Redhat-based systems, and dpkg -i packagename for Debian-based systems).

Once installed, SSH should work properly. To test it, you may login to your server by issuing the following command:

ssh -l username 127.0.0.1

Replace “username” with your desired user name. If all is working correctly, you will be prompted for a password, and then connected. If this does not work, if you installed SSH from source, and don’t have an /etc/init.d or /etc/rc.d file for the SSH daemon, you can build one from scratch following the guidelines for Pro-FTPD. The SSH config file (normally located in /etc/ssh or /etc/ssh2) is sshd_config or sshd2_config. An example configuration file looks like the following:

# sshd2_config
# SSH 2.0 Server Configuration File

*:
Port 22
ListenAddress 0.0.0.0
Ciphers AnyStd
# Ciphers AnyCipher
# Ciphers AnyStdCipher
# Ciphers 3des
IdentityFile identification
AuthorizationFile authorization
HostKeyFile hostkey
PublicHostKeyFile hostkey.pub
RandomSeedFile random_seed
ForwardAgent yes
ForwardX11 yes
PasswordGuesses 1
MaxConnections 50
PermitRootLogin no
# AllowedAuthentications publickey,password,hostbased
AllowedAuthentications publickey,password
# RequiredAuthentications publickey,password
ForcePTTYAllocation no
VerboseMode no
PrintMotd yes
CheckMail yes
UserConfigDirectory “%D/.ssh2″
SyslogFacility AUTH
# SyslogFacility LOCAL7
Ssh1Compatibility yes
Sshd1Path /usr/sbin/sshd1
# AllowHosts localhost, foobar.com, friendly.org
# DenyHosts evil.org, aol.com
# AllowSHosts trusted.host.org
# DenySHosts not.quite.trusted.org
# NoDelay yes
KeepAlive yes
RequireReverseMapping yes
/ UserKnownHosts yes
# subsystem definitions
subsystem-sftp sftp-server

Most of these settings you shouldn’t have to change from the default. One notable exception is the port that SSH will use. You can change this to any port within the 65535 limit. Also, you might want to change PasswordGuesses from its default (3) to 1. The reason for this is that it deters cracking attempts (the cracker has to make a new connection for each failed password). MaxConnections is a very important setting if this server is going to have any other services on it. MaxConnections helps keep your connections down, so that SSH requests and processes don’t take up 90% of the server’s resources. However, there is a downside to it- someone can login to your server the amount of times allowed in MaxConnections, then just leave the sessions logged in, which will prevent other users from logging in. PermitRootLogin is also an important setting, *ALWAYS* set this to no (the default is yes). If you need to login as root, simply create a user with a GID of 0 and UID of 0. This is known as a suid root account. Leaving root with the ability to login leaves a small chance that someone may crack root. SSH1 compatibility is crucial, many people have not yet upgraded (or are aware of the upgrade) to SSH2. AllowHosts and DenyHosts really shouldn’t be used as a security measure in my opinion. Instead, ipchains or a similar kernel-level firewall should be used instead. However, you may elect to use them, but be warned that when using a application level security measure, exploits in the application can allow denied (or blocked) hosts from connecting anyways. One great thing about SSH is that it comes with the sftp server, which allows encrypting of FTP sessions. Also, no FTP daemons are needed on the server, just the SSH daemon. However, the client must have a SSH package, in order to take advantage of the sftp server.

SSH is an extremely valuable service. It allows encryption of what were traditionally non-traditional services (such as telnet and FTP). This section has only briefly touched on the subject of the SSH server. For more information, read the FAQs and HOW-TOs available at ssh.org, or feel free to visit my website below.

About the Author:

Christopher J. Pace is a freelance Linux consultant who has worked with Linux since 2001. He provides remote Linux consulting services for Linux servers.

Article Source: ArticlesBase.com – Installing and Configuring the Secure Shell Server

As a Debian Linux user, administrator, and integrator, I found it absolutely necessary to research, try, and implement the best solution necessary to harden or secure my Linux server. Although I have often used multiple web sites in the past, I have found the following writeup to be one of the best single compilations of how to harden a Debian system in my internet travels. If you need to install a secure version of Linux you need to do two important things:

1. Install Debian Linux
2. Review the wonderful document below

This is a very nice tutorial on a basic setup of Linux iptables for a server. It is great to watch if you are a Linux admin but don’t know much about Linux firewalls! I run Debian and CentOS Linux on different servers and this will come in handy. I just wanted to share with the community at large. Enjoy!