<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapfrom="Skype on Fedora 13 64 bit (x86 64)" />
  </query-continue>
  <query>
    <pages>
      <page pageid="111" ns="0" title="Redirecting Linux console messages to another machine">
        <revisions>
          <rev xml:space="preserve">Here I am going to present how to redirect console messages from virtual machine to physical (base) machine. We used, in our lab, one physical machine running Linux OS and created one virtual machine in it.

&lt;b&gt;Requirement:&lt;/b&gt;
*One physical machine running Linux OS
*Created one virtual machine (Linux OS)
 
Here are the steps we followed in our lab to accomplish this assignment.

Before we begin, it is important to know that your Serial Ports (COM1 and COM2) are named as /dev/ttyS0 and /dev/ttyS1 respectively and so on.

Check if Linux detects your serial port or not. One way you could do is to give the following command:

&lt;pre&gt;
#dmesg |grep ttyS
&lt;/pre&gt;

You should see something like this:

Example:

&lt;pre&gt;
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550
&lt;/pre&gt;

The above output shows that your COM1 and COM2 ports are available and Linux recognizes them.

Another way to test is to give the following command:

&lt;pre&gt;
# ls &gt; /dev/ttyS0
&lt;/pre&gt;

If the command does not return any error message then your Serial Ports are recognized by your Linux system.
In case, Linux does not detect your Serial Port, then try giving the following command:

&lt;pre&gt;
#setserial /dev/ttyS0 autoconfig auto_irq
&lt;/pre&gt;

Well, above we just discussed only basics of how to find serial ports installed in our machine.

Here, the actual work starts. On guest machine, we need to make few changes in the grub file which was created in our lab.

Add the following line to grub.conf file of guest machine. Open the grub.conf file using VI editor and append the following lines to it.

&lt;pre&gt;
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
&lt;/pre&gt;

And also in the grub.conf file, append the following parameters right after the kernel value as shown below.

&lt;pre&gt;
#vi /etc/grub.conf
kernel /vmlinuz-2.4.9-21 ro root=LABEL=/ console=tty0 console=ttyS0,115200
:wq
#
&lt;/pre&gt;

Create a copy of the inittab file and add the following line to it.

&lt;pre&gt;
#cp /etc/inittab /etc/inittab.orig
#vi /etc/inittab
co:23:respawn:/sbin/agetty ttyS0 115200 linux
:wq
#init q
&lt;/pre&gt;

Well, now we need to reboot our guest machine and check whether it is accessible using the following command.

&lt;pre&gt;
#Virsh console Node1
&lt;/pre&gt;</rev>
        </revisions>
      </page>
      <page pageid="120" ns="0" title="SFTP chroot">
        <revisions>
          <rev xml:space="preserve">&lt;pre&gt;
[root@lnxlan215 ~]# tail /etc/ssh/sshd_config 
Subsystem	sftp	/usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs server

Match Group webmasters 
	ChrootDirectory %h
[root@lnxlan215 ~]# 

service sshd restart


[root@bilaltest ~]# ssh web1@192.168.122.1
web1@192.168.122.1's password: 
Read from remote host 192.168.122.1: Connection reset by peer
Connection to 192.168.122.1 closed.
[root@bilaltest ~]# 



[root@lnxlan215 ~]# tail -f /var/log/secure
May 21 11:20:54 lnxlan215 sshd[23458]: pam_unix(sshd:session): session opened for user kamran by (uid=0)
May 21 11:20:58 lnxlan215 sshd[23458]: pam_unix(sshd:session): session closed for user kamran
May 21 11:21:09 lnxlan215 sshd[23502]: Accepted password for web1 from 192.168.122.119 port 40135 ssh2
May 21 11:21:09 lnxlan215 sshd[23502]: pam_unix(sshd:session): session opened for user web1 by (uid=0)
May 21 11:21:09 lnxlan215 sshd[23511]: fatal: bad ownership or modes for chroot directory &quot;/home/web1&quot;
May 21 11:21:09 lnxlan215 sshd[23502]: pam_unix(sshd:session): session closed for user web1
May 21 11:21:39 lnxlan215 sshd[23554]: Accepted password for web1 from 192.168.122.119 port 40136 ssh2
May 21 11:21:39 lnxlan215 sshd[23554]: pam_unix(sshd:session): session opened for user web1 by (uid=0)
May 21 11:21:39 lnxlan215 sshd[23562]: fatal: bad ownership or modes for chroot directory &quot;/home/web1&quot;
May 21 11:21:39 lnxlan215 sshd[23554]: pam_unix(sshd:session): session closed for user web1
^C
[root@lnxlan215 ~]# 



---------

Right, this is on purpose. We ban this because allowing a user write
access to a chroot target is dangerously similar to equivalence with
allowing write access to the root of a filesystem.

If you want the default directory that users start in to be writable
then you must create their home directory under the chroot. After
sshd(8) has chrooted to the ChrootDirectory, it will chdir to the
home directory as normal. So, for a passwd line like:

djm:*:1000:1000:Damien Miller:/home/djm:/bin/ksh

Create a home directory &quot;/chroot/djm/home/djm&quot;. Make the terminal &quot;djm&quot;
directory user-owned and writable (everything else must be root-owned).
Set &quot;ChrootDirectory /chroot&quot; in /etc/config.

The directory specified for “ChrootDirectory” and all its parents up to / should be :
# owned by root
# not group or other writable

A variant of this that yields less deep directory trees would be to set
the passwd file up as:

djm:*:1000:1000:Damien Miller:/upload:/bin/ksh

Create &quot;/chroot/djm/upload&quot;, with &quot;upload&quot; the only user-owned and writable
component. 

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



[root@lnxlan215 ~]# mkdir /ssh-chroot/home/web1 -p


man 5 sshd_config

     ChrootDirectory
             Specifies the pathname of a directory to chroot(2) to after authentication.  All components of the pathname must be root-owned directories
             that are not writable by any other user or group.  After the chroot, sshd(8) changes the working directory to the user's home directory.

             The pathname may contain the following tokens that are expanded at runtime once the connecting user has been authenticated: %% is replaced
             by a literal '%', %h is replaced by the home directory of the user being authenticated, and %u is replaced by the username of that user.

             The ChrootDirectory must contain the necessary files and directories to support the user's session.  For an interactive session this
             requires at least a shell, typically sh(1), and basic /dev nodes such as null(4), zero(4), stdin(4), stdout(4), stderr(4), arandom(4) and
             tty(4) devices.  For file transfer sessions using “sftp”, no additional configuration of the environment is necessary if the in-process sftp
             server is used, though sessions which use logging do require /dev/log inside the chroot directory (see sftp-server(8) for details).

             The default is not to chroot(2).

----------

http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229
-----------

Notice that if any of the following is missing the users will not be able to logon to the chroot:

    *The /proc filesystem needs to be mounted in the users' chroot.

    *The necessary /dev/pts/ devices need to exist. If the files are generated by your running kernel automatically then you have to manually create them on the chroot's /dev/.

    *The user's home directory has to exist in the chroot, otherwise the ssh daemon will not continue.




&lt;/pre&gt;</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>