SFTP jailing in RHEL

SFTP jailing in RHEL

Requirement: Users need only sftp access  and they should be limited to their home directory.

Solution : Chrooted SFTP environment  with disallowing ftp access.

I used RHEL 6.2 Operating System  for  testing

Let the user be suresh .

Create a group; let it be sftponly.

èAdd the group

# groupadd  sftponly

èAdd the users with sftponly group membership.

# useradd -g sftponly -M -d /homedir -s /bin/false suesh  

-M option will help to not create the directory while adding the user. Non-existent shell prevent from interactive logins(SSH/telnet/rsh/rlogin etc)

# passwd suresh

èNow edit SSH server configuration file and comment the default Subsystem entry for sftp and add  “Subsystem                sftp        internal-sftp”  . Append Match block also.

# vi /etc/ssh/sshd_config

#Subsystem       sftp        /usr/libexec/openssh/sftp-server

Subsystem          sftp        internal-sftp

Match Group sftponly                                         

ChrootDirectory /chroots/%u          

AllowTcpForwarding no

ForceCommand       internal-sftp             

X11Forwarding no                                          

Match block matches the group sftponly and applies  below settings to  its members alone.

%u  stands for user_name  ; chrooted directory becomes /chroots/suresh   for  user suresh.

èCreate the directories and set sufficient permissions. 

# mkdir -p /chroots/suresh;chmod 755 /chroots/suresh

# mkdir /chroots/suresh/homedir
# chown suresh:sftponly /chroots/suresh/homedir

To secure from other users reading /chroots/suresh/homedir  contents.

# chmod 750 /chroots/suresh/homedir          

èNow restart SSH service.

# service sshd restart

To block ftp access …add the user name to /etc/vsftpd/ftpusers.

Now suresh has only sftp access (no ssh/telnet/rlogin/rsh/scp/ftp……) and his visibility is limited to /homedir only. For suresh   “/chroots/suresh” becomes the root directory ,ie; “/”. So this kind of setup is pretty secure.

Xlib: PuTTY X11 proxy: wrong authentication protocol attempted

GUI installer fails to launch when executed with sudo

Problem:

 Application GUI installer fails to launch by throwing X related error messages when executed with sudo.

Scenario:

Application team has to install application with root privilleges but security policy does n't allow sharing root password.Here we provided necessary privilleges to the application user via sudo.But when the application user tried to start the install script which invokes a gui

got the following error messages:

Xlib: connection to "localhost:10.0" refused by server

Xlib: PuTTY X11 proxy: wrong authentication protocol attempted

Error: Can't open display: localhost:10.0

Reason:

To get remote display exported to our local machine we need to have proper DISPLAY variable and X authentication for our X server(xming in our case).When the user logs in via ssh client,putty...DISPLAY variable will be set according to the putty X11forwarding configuration,and proper X authentication will be set up by adding entry to ~user/.Xauthority file.When we use sudo to get root privilleges X authentication will be expected from root user's configuration file(/.Xauthority).As the X authentication is updated to ~user/.Xauthority file while logging in to the OS directly via ssh; root user's Xauthority file will not have this information.This is why we get "Xlib: connection to "localhost:10.0" refused by server" message.

Work around:

I just created a softlink from ~user/.Xauthority to ~root/Xauthority.

eg:

# ln -s ~user/.Xauthority  /.Xauthority

This enabled root user to have proper X authentication to connect to xserver(xming) on the local machine.

Note:

When we switch to root user we have to set DISPLAY variable additionally by looking into the DISPLAY variable of the first login.

Eg:

$ echo $DISPLAY

localhost:10.0

$su -

# export DISPLAY=localhost:10.0

System time is one hour ahead of ntp server :AIX

Problem : System time is one hour ahead even ntp sync is proper.

Observation: I stoped the ntp client and set the time manually using date command .The moment i do an ntpdate to the time server system time jumps to one hour ahead.All other ntp clients were fine and were showing proper time.So this should be a problem with this particular client.

Client OS details: AIX 7.1

From the problematic client:

-------------------------------------

bash-4.2# date

Mon Mar 17 19:51:33 IST 2014           =>Time showing 19:51 which was 1 hour ahead that of  ntp server.

bash-4.2# date 031718512014             =>Set time manually.

Mon Mar 17 18:51:33 IST 2014          

bash-4.2# ntpdate  192.168.1.100             where 192.168.1.100 is my ntp server.

17 Mar 19:51:34 ntpdate[12386500]: adjust time server 192.168.1.100 offset  3600.479108

Please notice time is getting set to one hour ahead.

bash-4.2#date

Mon Mar 17 19:51:35 IST 2014

IST  word at the date command output gave an impression that Time zone is IST(GMT+5:30). But it was not true when checked the time zone.

bash-4.2# echo $TZ

IST-5:30IST

So changed the time zone to Asia/Kolkata(GMT+5:30) using smitty and restarted the system to effect the new Time zone.

smitty-->System Environments-->Change / Show Date and Time-->Change Time Zone Using System Defined Values-->Select Asia/Kolkata from the list-->Enter-->Enter -->Exit (F10)

Then took a reboot.

bash-4.2# shutdown -Fr

Once the system is back everything will be fine.

An event was unable to invoke any of the subscribers:virtual router

Problem: Error message while starting Virtual Router "An event was unable to invoke any of the subscribers"

Reason: The problem happens when the Virtual Router isn't closed properly (ie when your connection disconnects or your computer locks up and needs to be restarted). The shared internet connection still has a lock on the share Virtual Router created, and so it can't create a new one.

In my case i have two  internet connections earlier i was using a data card which was shared and virtual router was using it .once the laptop woke up from hiberation i tried to connect via lan connection ,as the lock from data card was still there i ot into this issue.

Solution:
In Windows 7

Go to your Network and Sharing center -->Change adapter settings. Select the Internet adapter whose Internet connection you share with other devices.

Go to Internet Sharing. Break the lock on the old share by setting the adapter to share its connection with something else (whatever you have handy; network adapter, wireless, anything). You'll get a warning about the old share still being in effect. Break the old share, click OK until the settings for your adapter closes.

Open up your adapter's settings again, and remove the shared connection you just created. Keep clicking OK to close the adapter's settings.

Start up Virtual router again, and enjoy.

This isn't a problem specific to Virtual router, any similar app you try won't be able to create a share until you break the old one that Virtual router had.