Restricting Direct Login Access for System and Shared Accounts

On an audited production system it is very important to know who switched to which system or shared account. Therefore it is prudent to restrict direct logins for all system and shared account where more than one individual knows the password. All users should do a direct login using their own account and then switch to the system or shared account.

However, there are situations where you have to allow direct logins for system or shared accounts. For example, within an Oracle RAC cluster you have to enable direct ssh logins for oracle. But in such an environment you have to protect the whole cluster as a single entity against incoming ssh connection, i.e. direct oracle logins should not work if you come from a node that is not part of the cluster. In the following example I will show how to achieve this goal as well.

Usually all system and shared accounts have one thing in common, that is they are not in the "users" group. The following example assumes that all individual user accounts are in the "users" group but system and shared accounts like root and oracle are not. If you want to go a step further, a good solution would be to implement a new 'logingroup' users group which would require users to be given explicit access.

In this example I will show how to restrict direct logins for:

- SSH (/etc/pam.d/sshd)
- Console Login (/etc/pam.d/login)
- Graphical Gnome Login (/etc/pam.d/gdm
- or for all logins (/etc/pam.d/system-auth)

Find Linux CPU utilization using SYSSTAT

This package includes system performance tools for Linux (Red Hat Linux / RHEL includes these tools by default).And for Debian or Ubuntu use "apt-get"

# apt-get install sysstat

Display the utilization of each CPU individually using mpstat

If you are using SMP (Multiple CPU) system, use mpstat command to display the utilization of each CPU individually. It report processors related statistics. For example, type command:

# mpstat
Output:

Linux 2.6.15.4 (debian)         Thursday 06 April 2006

05:13:05  IST  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
05:13:05  IST  all   16.52    0.00    2.87    1.09    0.07    0.02    0.00   79.42    830.06

Mount Samba share using fstab

To mount a Samba share when Linux system comes up after reboot edit the /etc/fstab file and put entry as follows for your Windows/Samba share:

//ntserver/share /mnt/samba smbfs username=username,password=password 0 0

For example, if you want to mount a share called //ntserver/docs then you need to write following entry in /etc/fstab file:

//192.168.0.1/share /mnt/samba smbfs username=sameed,password=passwd123 0 0

Wake on LAN: Quick Way to Power Up Computer Remotely

Wake on Lan (WOL) is the implementation to power up your computer remotely from other computer within your home network or over the Internet by using special packet, called magic packet. On this article, I will show you how to power up your computer (remote computer) in your home network by using WOL implementation.

Is there any requirement? You can only do this if that remote computer's motherboard and Ethernet network card support the WOL feature!

Let say in your home network, you have computer A and computer B that are connected to network by using network cables. You wish to power up the computer B remotely (we call it remote computer in this case) from computer A, then here is how you can make it done.

Linux security tip: change your computer’s SSH port

Here's a useful tip for people that access their computer or server over the Internet using SSH. Change your SSH port from the default port 22 to something else. Although this is not a foolproof hack to secure your server, it can at least help greatly. Let's look at you this would be done on an Ubuntu machine. NOTE that this change should not be performed over a remote SSH connection, you might lose all contact with your server.

1 First, check to see if the SSH service is running at all, and if it is, then on which port. Run the following command:

# netstat -tulpn

In the output you should see an entry for port 22. This is the SSH service.

SSH Tunnel

Hi,

In previous post i explain about ssh without password. hope you tried.

This time i am showing some trick, from that you can make ssh tunnel and easily make connect to your office server from home without knowing public IP.

Scenario : Your company block access to port 22 ( i.e ssh port) and you do not know public IP or Your Server is not mapped to Public IP. You can want to work from home with ssh service.

Solution : You need to generate you customize port on your home pc from office server which you want to connect. for that you need two important things. First Internet on both end and static IP to your home PC. Finally following steps.

For consideration, Home IP is 177.177.177.177

Steps :
First on server side

1. login to server as root or super privilege
2. run following commands

# ssh -R 988:localhost:22 root@177.177.177.177

-R will generate port 988 on localhost of home pc (i.e 177.177.177.177)

After getting terminal, login on your pc and leave this terminal open.


Now Come to home pc

1. login to home server as root
2. run following command

# ssh -p 988 localhost

-p will connect to port 988 on localhost.

This will help to connect back to office server. Because ssh thinks, he is connecting to localhost on port 988 and port 988 will lead to your office server without asking IP and router mapping.

SSH without password using a secure RSA key

ssh without password is use full when implementing scheduled jobs for scripts and backups

To scp, ssh and rsync without prompting for password

# ssh-keygen -t rsa

This will prompt for a passphrase. Just press the enter key. It’ll then generate an identification (private key) and a public key. Do not ever share the private key with anyone! ssh-keygen shows where it saved the public key. This is by default ~/.ssh/id_rsa.pub:
Your public key has been saved in /.ssh/id_rsa.pub

Transfer the id_rsa.pub file to host_dest by either ftp, scp, rsync or any other method.

On host_dest, login as the remote user which you plan to use when you run scp, ssh or rsync on host_src.

Copy the contents of id_rsa.pub to ~/.ssh/authorized_keys.

# cat id_rsa.pub >> ~/.ssh/authorized_keys
# chmod 700 ~/.ssh/authorized_keys

If this file does not exists, then the above command will create it. Make sure you remove permission for others to read this file. If its a public key, why prevent others from reading this file? Probably, the owner of the key has distributed it to a few trusted users and has not placed any additional security measures to check if its really a trusted user.

Well, thats it. Now you can run scp, ssh and rsync on host_src connecting to host_dest and it won’t prompt for the password. Note that this will still prompt for the password if you are running the commands on host_dest connecting to host_src. You can reverse the steps above (generate the public key on host_dest and copy it to host_src) and you have a two way setup ready!