Host-based authentication using OpenSSH

Taken from http://cert.uni-stuttgart.de/doc/openssh/host-based.php

Using host-based authentication, any user on a trusted host can log into another host on which this feature is enabled. This authentication is useful in an environment with a trusted host and several untrusted systems. Passwords no longer have to be transferred to the untrusted systems.

Requirements

It is recommended that you use at least OpenSSH 3.4p1 on both clients and servers.

Scenario

We have got two hosts, trusted.example.com and untrusted.example.com. We want to perform host-based authentication from trusted.example.com to untrusted.example.com, i.e. user on trusted.example.com shall be able to login on untrusted.example.com without supplying a password.

We assume that all SSH configuration files are stored in /etc/ssh.

Configuration on the client

On trusted.example.com, the following changes are required:

1. The ssh binary (usually stored in /usr/bin/ssh or /usr/local/bin/ssh) has to be maded set-uid root:

   # chown root /usr/bin/ssh
   # chmod u+s /usr/bin/ssh
   # ls -l /usr/bin/ssh
   -rwsr-xr-x    1 root     root       230216 Jul 31 08:49 /usr/bin/ssh
   #
   

2. Host keys for protocol version 2 are required. The files are called /etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key (and the .pub variants). You can create these files using ssh-keygen.
3. Host-based authentication has to be enabled in the client. Add the following section to /etc/ssh/ssh_config:

   Host *
      HostbasedAuthentication yes 

Configuration of the server

On untrusted.example.com, these changes are needed:

1. Of course, host-based authentication has to be enabled in the server, by changing the /etc/ssh/sshd_config file and inserting the following line (or replacing an uncommented HostbasedAuthentication directive):

   HostbasedAuthentication yes 

2. The public part of the the host keys of trusted.example.com have to be added to the /etc/ssh/ssh_known_hosts file. In contrast to the authorized_keys file you might know from user-oriented public-key authentication, this file is stored in the known hosts file format, i.e. you have to prefix each line with the host name and its IP adress (separated by a comma).

   For example, if the RSA public host key on trusted.example.com looks like this:

   ssh-rsa AA lots of characters MM= root@trusted.example.com
   

   You have to add the following line to /etc/ssh/ssh_known_hosts on untrusted.example.com:

   trusted.example.com,192.0.2.1 ssh-rsa AA lots of characters MM= root@trusted.example.com
   

   A similar line should be added for the DSA host key.

3. Using the line above, untrusted.example.com can authenticate requests from trusted.example.com. It is still necessary to instruct the SSH server on untrusted.example.com to authorize host-based authentication requests coming from trusted.example.com. For this, you need to create a file /etc/ssh/shosts.equiv with the following line in it:

   +trusted.example.com 

After these changes, you should be able to use host-based authentication on trusted.example.com/CODE>.

Security considerations

• If trusted.example.com is compromised, untrusted.example.com. As a consequence, you should never enable host-based authentication unless trusted.example.com is already a trusted system (i.e. on which you completely depend), and a compromise of untrusted.example.com is a minor annoyance compared to a break-in on this trusted host.
• The SSH client on trusted.example.com is now set-uid root. (See the remarks under the previous point.)
• An additional authentication method is enabled in the client on trusted.example.com. This exposes more OpenSSH client code to attacks from malicious SSH servers.
• Similarly, on the server untrusted.example.com, more code is exposed to attacks, too.

View vpath's ESS attributes

Use command lsvpcfg to find the vpath serial number.
example:
# lsvp
# lsvpcfg vpathX
example output:
servername:/ $ lsvpcfg vpath1
vpath1 (Avail pv myvg) 00126549 = hdisk4 (Avail ) hdisk10 (Avail )

The serial number of the vpath equals the Shark LUN ID

How to add filebase swapspace on Linux

a) Login as the root user

b) Type following command to create 512MB swap file (1024 * 512MB = 524288 block size):
# dd if=/dev/zero of=/swapfile1 bs=1024 count=524288

c) Set up a Linux swap area:
# mkswap /swapfile1

d) Activate /swapfile1 swap space immediately:
# swapon /swapfile1

e) To activate /swapfile1 after Linux system reboot, add entry to /etc/fstab file. Open this file using text editor such as vi:
# vi /etc/fstab
Append following line:
/swapfile1 swap swap defaults 0 0

So next time Linux comes up after reboot, it enables the new swap file for you automatically.

g) How do I verify swap is activated or not?
Simply use free command:
$ free -m
$ swapon -s

Switch the primary group with secondary group temporarily

This command is used to switch / swap between primary group and secondary group in a session.

$ id
uid=33119(kasim) gid=33119(users) group=3333(sysadm)
$ newgrp sysadm
$ id
uid=33119(kasim) gid=3333(sysadm) group=33119(users)

Admin tools for cluster manipulation

A tool to manage and configure cluster overall:
# smitty hacmp

A tool to manage RG(s) and cluster generally:
# smitty cl_admin

A tool to start cluster:
# smitty clstart

A tool to stop cluster gracefully, fail over or force:
# smitty clstop

A command to check the cluster services:
# lssrc -g cluster

Set user ID, set group ID, sticky bit

Source taken from: http://wiki.e107.org/?title=Unix_Permissions

In addition to the basic UNIX permissions, there are also three bits of information defined for files in UNIX:

• SUID or setuid: change user ID on execution. If setuid bit is set, when the file will be executed by a user, the process will have the same rights as the owner of the file being executed.
• SGID or setgid: change group ID on execution. Same as above, but inherits rights of the group of the owner of the file. For directories it also may mean that when a new file is created in the directory it
• Sticky bit. It was used to trigger process to "stick" in memory after it is finished, now this usage is obsolete. Currently its use is system dependant and it is mostly used to suppress deletion of the files that belong to other users in the folder where you have "write" access to.

Numeric representation

Octal digit Binary value Meaning

• 0 000 setuid, setgid, sticky bits are cleared
• 1 001 sticky bit is set
• 2 010 setgid bit is set
• 3 011 setgid and sticky bits are set
• 4 100 setuid bit is set
• 5 101 setuid and sticky bits are set
• 6 110 setuid and setgid bits are set
• 7 111 setuid, setgid, sticky bits are set

Textual representation

SUID

• If set, then replaces "x" in the owner permissions to "s", if owner has execute permissions, or to "S" otherwise. Examples:
• -rws------ both owner execute and SUID are set
• -r-S------ SUID is set, but owner execute is not set

SGID

• If set, then replaces "x" in the group permissions to "s", if group has execute permissions, or to "S" otherwise. Examples:
• -rwxrws--- both group execute and SGID are set
• -rwxr-S--- SGID is set, but group execute is not set

Sticky

• If set, then replaces "x" in the others permissions to "t", if others have execute permissions, or to "T" otherwise. Examples:
• -rwxrwxrwt both others execute and sticky bit are set
• -rwxrwxr-T sticky bit is set, but others execute is not set

What are the SUID, SGID and the Sticky Bits?

Source taken from http://www.codecoffee.com/tipsforlinux/articles/028.html

Linux has some special attributes associated with all files. Often in X Windows when you check the properties of any file (by right clicking on it and viewing its properties) you would get to see 3 special attributes besides the common read/write/execute rights for the owner/group/others. The 3 extra attributes are known as SUID, SGID and Sticky Bits

Sticky Bit

Lets start with Sticky bit first. Since this is the most simplest to explain. Setting the sticky bit tells Unix that once the concerned application is executed, it should remain in memory. Remember that Unix is a multi-user OS and was mainly designed so that multiple users can work simultaneously. Thus the logic used is that a program that exists in memory requires lesser time to start when a new user requests for the same program. Thus when one user has just used a program and then a new user wants to use the same program, the second user doesn't have to face a time delay for the program to initialize itself. It would be readily available to him. The concept of the sticky bit was a very useful one, long back when fast disk access and other memory access technologies weren't around. But in today's age the concept of sticky bit is obsolete, since modern day technology is advanced enough to reduce the time delay while loading applications into the memory. Thus currently the sticky bit is of very little significance. Sticky bit is only associated with executables.

SUID (Set User ID) Bit

Sometime you may faced an error while trying to run any application stating that the application must be 'SUID root' . You might have been confused that time, but now once you read this article you would no longer find it confusing.

SUID stands for Set User ID. This means that if the SUID bit is set for any application then your user ID would be set as that of the owner of application/file rather than the current user, while running that application. That means in case I have an application whose owner is ' root ' and it has its SUID bit set, then when I run this application as a normal user, that application would still run as root. Since the SUID bit tells Linux that the the User ID root is set for this application and whenever this application executes it must execute as if root was executing it (since root owns this file).

In case you have really understood the above you may be wondering - isnt this a major security risk? If users are able to run applications as root, then it must be definitely posing as a threat to the security of the system. Actually the SUID is used to increase the security in a way. Let me explain this with my own example I use on my machine.


One way I use SUID on my machine

I have a few files that I modify through Linux and then before I shutdown Linux I have to transfer them to my Windows partition for further use there. As a normal user I do not have write access to the Windows partitions that I have mounted. So I have to be the superuser to be able to write to that partition. I have created a simple shell script that copies my files to the Windows partitions. This script was created by root user and the SUID bit was set. Access rights to this script have been given to all users. Now whenever I want to copy my files I simply run this script. Even though I have logged in as a normal user, the SUID bit which is set causes this script to execute as if the root was executing it and it allows me to write to the Windows partitions.

Had the SUID bit not been set, I would have to type ' su ' at the prompt and get temporary superuser access to get write access to the Windows partitions. Hope you got the point..

You may be thinking that since these applications would run as root they can do harmful things and destroy the system. The concept behind SUID bit is that you as the superuser would be able to allow certain applications / scripts to be run by the users as if they were the superuser for the time being. What these application / scripts do when they execute should be completely known to you. Even though the users would be allowed to execute these programs as root they would be able to do ONLY THOSE things that these programs were designed to do. So in case a script was designed to copy 5 files from one place to another. Then the user who would run that script would be able to ONLY copy those 5 files from one place to another. He would not be able to modify that script in any way since he would not have write access to the script. He would only be having execute rights for that script. Hence its an excellent idea to allow users to do some important backup using a script that does only that and by setting the SUID bit for that script. This way the users don't have to know the superuser password but can still use some facilities that are only available to the superuser

Important : Think twice before setting the SUID bit for scripts (owned by root) that take arguments at the command line. Since you never know what parameters a malicious user may pass to your script. Since the script would run as root it could do great damage if misused.


SGID (Set Group ID) bit

Just like SUID, setting the SGID bit for a file sets your group ID to the file's group while the file is executing. IT is really useful in case you have a real multi-user setup where users access each others files. As a single homeuser I haven't really found a lot of use for SGID. But the basic concept is the same as the SUID, the files whose SGID bit are set would be used as if they belong to that group rather than to that user alone.

Note : Making SUID and SGID programs completely safe is very difficult (or maybe impossible) thus in case you are a system administrator it is best to consult some professionals before giving access rights to root owned applications by setting the SUID bit. As a home user (where you are both the normal user and the superuser) the SUID bit helps you do a lot of things easily without having to log in as the superuser every now and then.