Archive for the tag 'SSH'

SBDavid

Disabling SSH Login for root user

Disabling SSH Login for root user

Below are instructions for disabling the root user and allowing another user to assume the root users permissions. This adds another layer of security because an additional username and password must now be entered before gaining the root user privileges.

Before you disable root logins you should add an administrative user that can ssh into the server and become root with su.

In the following example we are using buddy for the username, but can be replaced with any username you wish to use.

root@dell:~# useradd buddy
root@dell:~# id buddy
uid=1005(buddy) gid=1007(buddy) groups=1007(buddy)

Set the password for the buddy user. When prompted type and then retype the password.

root@dell:~# passwd buddy
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

SSH to the server with the new admin user and ensure that the login works.
Verify that you can su (switch user) to root with the admin user.

buddy@dell:/$ su
Password:
root@dell:/# whoami
root

Edit /etc/ssh/sshd_config with your favorite text editor.

#vi /etc/ssh/sshd_config

Change this line:

#PermitRootLogin yes

to this:

PermitRootLogin no

Ensure that you are logged into the box with another shell before restarting sshd to avoid locking yourself out of the server.

# /etc/init.d/sshd restart
SBDavid

SSH Security On cPanel Servers

SSH Security On cPanel Servers.

1. Change SSH port number.

Edit your ssh configuration file under /etc/ssh/sshd_config and add/replace this line:

# What ports, IPs and protocols we listen for
Port 22

2. Allow only the IP’s that you would like to have access to SSH through your firewall.

iptables -A INPUT -i eth0 -s 192.168.1.1 -p tcp –dport 22 -j ACCEPT

3. Use a utility like BFD, BlockHosts and DenyHosts

denyhosts - a utility to help system admins thwart ssh crackers

4. Use iptables to limit the rate of incoming connections to SSH.

iptables -I INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 -j DROP

This will limit incoming connections to port 22 to no more than 3 attempts in a minute. Any more will be dropped.

The latest CentOS 5.3/RHEL 5.3 updates for openssh (openssh-4.3p2-36) introduce the dependency on the libfipscheck.so.1 library supplied by fipscheck-1.0.3-1 RPM, but this RPM is missing in default file system template for ssh.

Log in as root to your PPCPL box.

Open the /etc/virtualhosting/filelists/ssh.sh file using a text editor:

vi /etc/virtualhosting/filelists/ssh.sh

Make sure that the file looks like:

$RPM_BIN -q nss nspr > /dev/null 2>&1 && \
cat <<EOF
S,rpm:nss
S,rpm:nspr
EOF

Reference: http://parallels.com

SBDavid

Email Alert on Root SSH Login

Email Alert on Root SSH Login

Login to your server as root user

vi /root/.bashrc

Add the following to the end of the file.

echo ‘ALERT - Root Shell Access on $hostname:’ `date` `who` |
mail -s “Alert: Root Access from `who | cut -d”(” -f2 | cut -d”)” -f1`” admin@serverbuddies.com
SBDavid

SSH Public key authentication

SSH Public key authentication

SSH Public key authentication works as follows:

The scheme is based on public-key cryptography, using cryptosystems where encryption and decryption are done using separate keys, and it is unfeasible to derive the decryption key from the encryption key. The idea is that each user creates a public/private key pair for authentication purposes.

The server knows the public key, and only the user knows the private key. ssh implements public key authentication protocol automatically, using either the RSA or DSA algorithms. Protocol 1 is restricted to using only RSA keys, but protocol 2 may use either. The HISTORY section of ssl(8) contains a brief discussion of the two algorithms.

The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept the account.

The user creates his/her key pair by running ssh-keygen(1). This stores the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol 2 DSA), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the users home directory.

The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. After this, the user can log in without giving the password.

The most convenient way to use public key authentication may be with an authentication agent. See ssh-agent(1) for more information.

« Prev - Next »