Friday, 27 June 2014

Deployment of Kerberos #Redhat

Objective: Installation and configuration of Kerberos

Environment: Redhat 5.1 32-bit

Package version: 

Kerberos - 1.6
OpenLDAP - 2.3.27

I had already explained the mechanism behind kerberos in my previous article, in this article I would be kerberosing SSH/TELNET as a service.

Pre-requsites:

I had configured NTP, DNS, OpenLDAP as an authentication, I would leave it to reader to configure and would not be explaining in this article, instead would focus on kerberos.

Make sure your NTP synchronized to all the servers, as it must generate the kerberos tickets TTL,

Hostname && Services:

1. Server - OpenLDAP and KDC center [ Authentication Server (AS) && Ticket Granting Server (TGS) ]

2. Client1 - an application server generally refers to Kerberized programs that clients communicate with using Kerberos tickets for authentication.

3. Client2 - This would be an user (i.e typically would be an LDAP user)which is used for testing the kerberos.

Testing results would be the below:

Once the Client2 user logs to the application server(Client1), it should NOT prompt for the password as it would have already generated an ticket for the user from the  KDC ( AS+TGS) to authenticate SSH service to application server.

Installation:

Install the below packages, 

· krb5-libs
· pam_krb5
· krb5-workstation
· krb5-auth-dialog
. Xinetd

Config files: 
/etc/krb5.conf - file used by kerberos libraries
/var/kerberos/krb5kdc/kdc.conf - config file for KDC.
/var/kerberos/krb5kdc/kdc.conf - file defined for ACL.

Explanation of config file:


· [logging] – sets the way Kerberos component will perform there logging, the components that use the logging parameters are the KDC and Kerberos Admin Server both are used when you will use Linux as the Kerberos server, our Kerberos server is the Active Directory so we can leave the default for the logging section.

· [libdefaults] - Contains various default values used by the Kerberos V5 library. Values like default encryption type and if to use dns lookups or not.

· [realms] – list of realms and where to find there Kerberos server and some other realm related information.

· [domain_realm] – this file the mapping file from domain names to Kerberos realms.

· [appdefaults] – Contains default values that can be used by Kerberos V5 applications.

KDC SERVER

[root@server ~]# cat /etc/krb5.conf 
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes

[realms]
  kdc = server.example.com:88
  admin_server = server.example.com:749
  default_domain = example.com
 }

[domain_realm]

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }
[root@server ~]# 



[root@server ~]#  cat /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
 v4_mode = nopreauth
 kdc_tcp_ports = 88

[realms]
  #master_key_type = des3-hmac-sha1
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3
 }
[root@server ~]# 




[root@server krb5kdc]# cat kadm5.acl 

*/admin@EXAMPLE.COM *
[root@server krb5kdc]# 

[root@server ~]# ls /var/kerberos/krb5kdc/

kadm5.acl  kdc.conf
[root@server krb5kdc]#

We need to create the database containing all the principles and their passwords. An utility called kdb5_util is mainly used for low level maintenance( creation, dumping, saving, destruction of KDC DB and etc )

During creation, you will be prompted for the master password. It is the main key that is used by Kerberos to encrypt all the principals' keys in its database. Without it, Kerberos won't be able to parse it. For later convenience, this master password can be stored in a stash file, in order to avoid to retype it each time you restart Kerberos

[root@server krb5kdc]# kdb5_util create 
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: 
Re-enter KDC database master key to verify: 

[root@server krb5kdc]# ls
kadm5.acl  kdc.conf  principal  principal.kadm5  principal.kadm5.lock  principal.ok
[root@server krb5kdc]# 


Connection to administration server is done through kadmin. Since we did not create any principal yet, connecting to administration server is impossible, as KDC can not authenticate us. So, we use the "local" counterpart of kadmin, kadmin.local, to connect. It will access directly the Kerberos administration interface without password, but can only be run as root on the KDC's host.

[root@server krb5kdc]# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: 

First, we will list the content of the database, through the listprincs command. You will notice that the database contains already some principals. They are needed for Kerberos to work,during ticket negotiations.


I would go on to add an user 'user1' and admin principles to a DB.

kadmin.local:  addprinc user1
WARNING: no policy specified for user1@EXAMPLE.COM; defaulting to no policy
Enter password for principal "user1@EXAMPLE.COM": 
Re-enter password for principal "user1@EXAMPLE.COM": 
Principal "user1@EXAMPLE.COM" created.
kadmin.local:  
kadmin.local:  addprinc root/admin
WARNING: no policy specified for root/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "root/admin@EXAMPLE.COM": 
Re-enter password for principal "root/admin@EXAMPLE.COM": 
Principal "root/admin@EXAMPLE.COM" created.
kadmin.local:

kadmin.local:  addprinc -randkey host/client1.EXAMPLE.com
WARNING: no policy specified for host/client1.EXAMPLE.com@EXAMPLE.COM; defaulting to no policy
Principal "host/client1.EXAMPLE.com@EXAMPLE.COM" created.
kadmin.local:  listprincs

kadmin.local:  

Start the kerberos and admin services  

[root@server ~]# service krb5kdc start
[root@server ~]# service kadmin start

APPLICATION SERVER

Install the package krb5-workstation.
Sync the time.
Make sure your GSSAPI authentication is enabled in /etc/ssh/sshd_config
 74 GSSAPIAuthentication yes
 75 GSSAPICleanupCredentials yes

[root@client1 ~]# service sshd restart

Execute authconfig-tui in the client to add the required PAM modules.

[root@client1 ~]# authconfig-tui

​

​
On application server, run kadmin authenticating as root/admin after making the machine as a client of kerberos server.

[root@client1 ~]# kadmin -p root/admin
Authenticating as principal root/admin with password.
Password for root/admin@EXAMPLE.COM: 
kadmin:  
kadmin:  listprincs
kadmin:  

Extract KDC host principal in local key tab file using kadmin service.

kadmin:  ktadd -k /etc/krb5.keytab host/client1.EXAMPLE.com
Entry for principal host/client1.EXAMPLE.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/client1.EXAMPLE.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/client1.EXAMPLE.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/client1.EXAMPLE.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:  
kadmin:  quit
[root@client1 ~]# 


CLIENT SERVER

- client authenticate to the application server without password as the ticket was granted for the server for communication.

-bash-3.1$ kinit
-bash-3.1$ klist
Ticket cache: FILE:/tmp/krb5cc_505
Default principal: user1@EXAMPLE.COM

Valid starting     Expires            Service principal
06/27/14 09:11:26  06/28/14 09:11:26  krbtgt/EXAMPLE.COM@EXAMPLE.COM
06/27/14 09:11:47  06/28/14 09:11:26  host/client1.EXAMPLE.com@EXAMPLE.COM


Kerberos 4 ticket cache: /tmp/tkt505
klist: You have no tickets cached
-bash-3.1$ 

-bash-3.1$ ssh user1@client1
Could not create directory '/home/user1/.ssh'.
The authenticity of host 'client1 (192.168.10.101)' can't be established.
RSA key fingerprint is 19:6b:9c:62:02:be:07:a9:0b:d9:72:86:f1:73:14:59.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/user1/.ssh/known_hosts).
Last login: Fri Jun 27 09:15:19 2014 from client1.EXAMPLE.com
Could not chdir to home directory /home/user1: No such file or directory
-bash-3.1$ 

-bash-3.1$ id
uid=505(user1) gid=505(user1) groups=505(user1)
-bash-3.1$ hostname
client1
-bash-3.1$ 

TELNET was also made as a service for authentication

I was able to telnet to the user 'user1' without password.

-bash-3.1$ hostname
client2
-bash-3.1$ 
-bash-3.1$ telnet -Fxl user1 client1
Trying 192.168.10.101...
Connected to client1.EXAMPLE.com (192.168.10.101).
Escape character is '^]'.
Waiting for encryption to be negotiated...
[ Kerberos V5 accepts you as ``user1@EXAMPLE.COM'' ]
[ Kerberos V5 accepted forwarded credentials ]
done.
Last login: Fri Jun 27 09:40:52 from client2
No directory /home/user1!
Logging in with home = "/".
-bash-3.1$ hostname
client1
-bash-3.1$ klist
Ticket cache: FILE:/tmp/krb5cc_p5086
Default principal: user1@EXAMPLE.COM

Valid starting     Expires            Service principal
06/27/14 09:41:12  06/28/14 09:09:57  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Installed and configured successfully.

Wednesday, 25 June 2014

Kerberos mechanism explained

Objective: 
Understanding the mechanism behind kerberos.

How does kerberos work ?

This part of the article will explain the mechanisms behind Kerberos: 
Ticket exchange principles
Key Distribution Center(KDC)
Authentication mechanisms.

A commonly found description for Kerberos is "a secure, single sign on, trusted third party
mutual authentication service". It doesn't store any information about UIDs, GIDs, or home's
path. In order to propagate this information to hosts, you will eventually need yellow page
services: NIS, LDAP, or Samba

As Kerberos is only dealing with Authentication, it does neither Authorization, nor Accounting. it delegates those to the services requesting Kerberos' help for user's identification. Anyway, Kerberos being a "service" by itself, it can partially provide such functionalities, but in a very limited range.

Ticket Exchange Service

Kerberos' communication is designed to provide a distributed secure authentication service, through secret key cryptography.

For a user, the secret key is his "hashed password" (the password is reworked through a one-
way hash function and the resulted string is used as a key), usually stored in the Key
Distribution Center. For a service, the key is a random generated sequence, acting like a
password; it is also stored in Key Distribution Center, and in a file called a keytab on the
machine's service side.

The Kerberos communication is based around tickets. Tickets are a kind of encrypted data
scheme that is transmitted over the network, and stored on the client's side. The type of storage
depends on the client's operating system and configuration. Traditionally, it's stored as a small
file in /tmp, for compatibility reasons

The main central part of a Kerberos network is the the Key Distribution Center (KDC). It
consists of three parts:

• an Authentication Server, which answers requests for Authentication issued by clients.
Here, we're in the AS_REQUEST and AS_REPLY challenging part (see below for details),
where the client gets a Ticket Granting Ticket (TGT).

• a Ticket Granting Server, which issues Ticket Granting Service (TGS) to a client. This is
the TGS_REQUEST and TGS_REPLY part, where a client gets a TGS that allows him to
authenticate to a service accessible on the network.

• a database, that stores all the secret keys (clients' and services' ones), as well as some
information relating to Kerberos accounts (creation date, policies, ...).

Authentication mechanism—Ticket Granting Tickets  

AS_REQUEST & AS_REPLY, in conclusion Authentication mechanism can be represented as below which is self explanatory.

​
Service's use mechanism—Ticket Granting Service

TGS_REQUEST & TGS_REPLY in conclusion service's use mechanism can be represented as below which is self explanatory.


​

Conclusion

We can divide the Kerberos protocol into three main steps:

1. Authentication process, where the user (and host) obtain a Ticket Granting Ticket (TGT)
as authentication token,

2. Service request process, where the user obtain a Ticket Granting Service (TGS) to access
a service,

3. Service access, where the user (and host) use TGS to authenticate and access a specific
service

The service access step is not really Kerberos related, but merely depends on the service we are
authenticating to.


​
The below tutorial will explain the same in simplicity. 

I would further write an article to demonstrate deploying kerberos on Linux.

Saturday, 26 April 2014

automount configuration from NFS

Objective:  Execute shared scripts from NFS server to local server, which is configured via auto-mounts.

Environment: CentOS 6.3 32-bit

Package version:  autofs-5.0

Why do we need to use an autofs ?

One drawback to using /etc/fstab is that, regardless of how infrequently a user accesses the NFS mounted file system, the system must dedicate resources to keep the mounted file system in place. This is not a problem with one or two mounts, but when the system is maintaining mounts to many systems at one time, overall system performance can be affected. An alternative to /etc/fstab is to use the kernel-based automount utility. An automounter consists of two components. One is a kernel module that implements a file system, while the other is a user-space daemon that performs all of the other functions. The automount utility can mount and unmount NFS file systems automatically (on demand mounting) therefore saving system resources.

On RPM based systems, autofs is not installed by default, hence I would assume you might be knowing on how to install the 'auotfs' package using package manager. 
All my scripts are been placed in the central server which is NFS, and I would share to my local client which is configured via auto-mounts in-order to save the system performance.

NFS config's:

The directory containing the scripts are shared in /etc/exportfs and access controls are provided to the client servers. Once your configurations are completed, make sure to start the nfs services.

#vi /etc/exporfs
/scripts    <IP address of the client>(ro,sync)

You can get the system information script from getsysinfo.sh. The same file will be shared to all the clients.

 autofs config's:

The primary configuration file for the automounter is /etc/auto.master, also referred to as the master map which may be changed. The master map lists autofs-controlled mount points on the system, and their corresponding configuration files or network sources known as automount maps.

# cat /etc/auto.master
/autofs         /etc/auto.fs    --timeout=3
#

I use a shorter time vaule common user will not recognize as a timespan or anything the user could get nervous about when waiting. 


# tail -2 /etc/auto.fs
scripts -rw,soft,intr,rsize=8192,wsize=8192     nfs.domain.com:/scripts
#

Save the file and make sure you start the service.
#service autofs start

Now, you can traverse to the directoy which will mount when in use and unmounts when not in use. 

#df -h /autofs/scripts
Filesystem            Size  Used Avail Use% Mounted on
nfs.domain.com:/scripts  8.7G  4.1G  4.3G  49% /autofs/scripts

# ls -l  /autofs/scripts
total 8
-rwxr-xr-x 1 root root 7391 Sep  1  2013 getsysinfo.sh
#

You could also use the same for the local file system. I would conclude this article here and the 'automounts' can be configured for NIS, CIFS where I may explain in coming articles.

Sunday, 6 April 2014

Configure log rotation - Solaris 10

In order to have an easy administration of systems which generates large number of log files, you can configure your log files according by an utility called logroate, which allows automatic rotation, compression, removal and also mailing of log files which can be handled daily, weekly or when it grows too large.

Objective: compress and rotate logs after certain threshold on the file size.

Environment: Solaris 10 32-bit

The system log rotation is defined in the /etc/logadm.conf file. This file includes log rotation entries for processes such as syslogd. For example, one entry in the /etc/logadm.conf file specifies that the /var/log/ciscofirewall.log file is rotated weekly unless the file is empty. The most recent ciscofirewall.log file becomes ciscofirewall.log.0, the next most recent becomes ciscofirewall.log.1, and so on. Eight previous ciscofirewall log files are kept.
The /etc/logadm.conf file also contains time stamps of when the last log rotation occurred.
# vi /etc/logadm.conf 
/var/log/ciscofirewall.log -C 9 -s 10240k -z 4 -N -a 'kill -HUP `cat /var/run/syslog.pid`'
#

where, 
     -C = expire old logs until count remain.( 9 log files created and rotated )
     -N = not an error if log file nonexistent.
     -s = only rotate if given size or greater.
     -a = execute command after taking actions.
     -z = gzip old logs except most recent count ( last 5 log files would be compressed )

- Restart the syslogd to take changes effectively.

The command is often run on a cron job, which has the effect of fully automatic log rotation.

# crontab -l 
10 3 * * * /usr/sbin/logadm

# ls -l /var/log/ciscofirewall*.log.* | wc -l
       9
#

# ls -l /var/log/ciscofirewall*.log.*.gz | wc -l
       5
# 

# ls -ltr /var/log/ciscofirewall.log*
-rw-r--r--   1 root     root       41048 Apr  6 14:38 /var/log/ciscofirewall.log.8.gz
-rw-r--r--   1 root     root       42076 Apr  6 14:39 /var/log/ciscofirewall.log.7.gz
-rw-r--r--   1 root     root       41621 Apr  6 14:40 /var/log/ciscofirewall.log.6.gz
-rw-r--r--   1 root     root       41524 Apr  6 14:41 /var/log/ciscofirewall.log.5.gz
-rw-r--r--   1 root     root       41410 Apr  6 14:42 /var/log/ciscofirewall.log.4.gz
-rw-r--r--   1 root     root     21510944 Apr  6 14:43 /var/log/ciscofirewall.log.3
-rw-r--r--   1 root     root     21139079 Apr  6 14:44 /var/log/ciscofirewall.log.2
-rw-r--r--   1 root     root     21536814 Apr  6 14:45 /var/log/ciscofirewall.log.1
-rw-r--r--   1 root     root     21399755 Apr  6 14:46 /var/log/ciscofirewall.log.0
-rw-r--r--   1 root     root     16434041 Apr  6 14:46 /var/log/ciscofirewall.log
# 

all your logs has been rotated in a discipline manner, which would be easy to troubleshoot in-case of any errors.

Monday, 10 March 2014

OpenSSH security/hardening tips #Linux/Unix

Objective: Strengthen security on SSH

Environment: CentOS-6.3 (32-bit)

OpenSSH version : OpenSSH_5.3p1

SSH Protocol version : 2

I had observed more lines which were commented in sshd_config, hence I had enabled few of the options which could possibly strengthen ssh.

Any changed made to the /etc/ssh/sshd_config would require its corresponding daemon(sshd) to be restarted. Hence I would assume the reader would probably be aware and continuing explaining below options.

1. Change the port number on which sshd listens or specify the local address along with the port number on which sshd listens.
Port XXXX
or
ListenAddress 0.0.0.0:XXXX

2. The server disconnects if the user has not successfully logged within 120 seconds.
LoginGraceTime 2m

You may receive below snap if you would continue to be without logging in.




3. Once after logging into the server, and if there is no data communication for around 5 Minutes then we could force auto-logout option.

# grep -i tmout /etc/bashrc 
export TMOUT=300
 # 

You may receive the below error incase if the session is idle for 5 Minutes.

# timed out waiting for input: auto-logout
Connection to XXX.XXX.XXX.XXX closed.

4. Use the authentication methods(RSA, DSA) to grant access to the users, i..e password less logis to the users. How to create RSA/DSA to authenticate

PermitRootLogin without-password
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
AuthorizedKeysCommand yes

# To disable tunneled clear text passwords, change to no here!
PermitEmptyPasswords no
PasswordAuthentication no

5. sshd should check file modes and ownership of the user's file and the home directories before accepting login.
StrictModes yes

6. Password attempts to be prompted would be ideally two, incase of any failures would be disconnected.
MaxAuthTries 3


7. Restricted the maximum concurrent un-authenticated connections to the SSH daemon.
MaxStartups 2



8. You can use allow/deny directives for users/groups to allow/disallow based on the primary and the supplementary groups lists matches one of the pattern.
Allowgroups sshgroup

9. Finally, you can configure chrootDirectory which specifies the pathname of a directory to jail the user after authentication. All the components of the pathname must be root owned.
If this interests you on how to jailusers Click here 

I, hereby conclude that most of the options related in securing communication between server & client by OpenSSH had been discussed.

Saturday, 4 January 2014

Automatically Chroot Jail for SSH Access - #Linux_CentOS

Objective: User to be provided with a limited system environment.

Environment: CentOS-6.3 (32-bit)

I wanted to setup a way to allow SSH access to my machine but limit their abilities heavily. This can be achieved by jailing the user and providing limited access to the system.

Change plan:

1. List the user to be jailed, and gather details on his limitation for the system environment.
2. Creating basic "chroot" environment.
3. Create chroot user group.
4. Configure SSHd to chroot your users.

1. Create a test user and the group to be jailed for users.

#groupadd jailgroup
#useradd -g jailgroup jailuser


# tail  -1 /etc/passwd
jailuser:x:501:501::/home/jailuser:/bin/bash
# tail  -1 /etc/group

jailgroup:x:501:
#

2. Setting up the jail environment.

Create the directories, which needs to emulate the / directory to a bare minimum. That is we need a dev, etc, lib, usr, and bin directory as well as usr/bin/. The bash directory has to be owned by root.
#mkdir -p /chroot/{dev,etc,lib,usr,bin,home}
#mkdir -p  /chroot/usr/bin

We need a special file to disposing of unwanted output streams of a process, hence I would add "/dev/null" to my jail environment.
#mknod -m 666 /chroot/dev/null c 1 3

3. Copy few files to /chroot/etc directory.

# cp /etc/ld.so.cache /chroot/etc

# cp /etc/ld.so.conf /chroot/etc
# cp /etc/nsswitch.conf /chroot/etc

# cp /etc/hosts /chroot/etc
# cp /bin/ls /chroot/usr/bin
# cp /bin/bash /chroot/usr/bin/

Once done, you need to figure out what command you want accessible by your limited users. I want them to get into bash and list and write using 'vim' editor.
Location can be found as below 

#which cat vim ls
/bin/ls
/bin/cat
/usr/bin/vim
#

Now that you've got all the binaries in place, you need to add the proper shared libraries. To find out what libraries are as below 
# ldd /bin/ls
        linux-gate.so.1 =>  (0x008b3000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x00101000)
        librt.so.1 => /lib/librt.so.1 (0x0012a000)
        libcap.so.2 => /lib/libcap.so.2 (0x0018e000)
        libacl.so.1 => /lib/libacl.so.1 (0x00183000)
        libc.so.6 => /lib/libc.so.6 (0x00af5000)
        libdl.so.2 => /lib/libdl.so.2 (0x00c89000)
        /lib/ld-linux.so.2 (0x00acf000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00a11000)
        libattr.so.1 => /lib/libattr.so.1 (0x00122000)
#

Since you need to manually copy each file, I had an piece of code from "linuxcareer.com". copy paste the below code and execute.

# cat chroot.sh
#!/bin/bash
CHROOT='/chroot'
for i in $( ldd $*  | grep -v dynamic |cut  -d" "  -f3  | sed  's/://' | sort | uniq )
do

#--parents - using full source file name under DIRECTORY.
cp --parents  $i  $CHROOT
done

# ARCH  i386
if  [ -f  /lib/ld-linux.so.2 ];  then
cp  --parents /lib/ld-linux.so.2 /$CHROOT
fi
echo   "Chroot jail is ready."
#

#chmod +x chroot.sh
#./chroot.sh /bin/{ls,cat,bash} /usr/bin/vim 

4. Configure SSHd to chroot your users.

Add the following line to /etc/ssh/sshd_config file
# tail -5 /etc/ssh/sshd_config
Match group jailgroup
          ChrootDirectory /chroot/./
          X11Forwarding no
          AllowTcpForwarding no
#

- Try to login to the server as the user.
# ssh jailuser@0 jailuser@0's password: Last login: Sat Jan 4 11:40:57 2014 from 192.168.56.1 [-bash-4.1:~]$ pwd /home/jailuser [-bash-4.1:~]$ ls [-bash-4.1:~]$ rm -bash: rm: command not found [-bash-4.1:~]$ touch -bash: touch: command not found [-bash-4.1:~]$    
NOTE:
If a user does not have its home user directory available in a chroot jail after login s/he will end up in /. You can create and further configure your chroot by creating a user home directory, defining bash environment i..e bashrc file which sets PS1 needs to be customized as your needs to look better. 
I hence conclude this article by providing a limited system environment to the user via SSH access.