[FreeNX-kNX] preventing data transfers over SSH, yet still allow NX sessions.

[chris at ccburton.com]

freenx-knx-bounces at kde.org wrote on 01/02/2013 17:41:20:

> I was wondering if it is possible to configure sshd_config, possibly
> using the ForceCommand keyword, to prevent arbitrary command 
> execution/data transfers on the same host which is providing the NX 
> sessions.  For example I can configure sshd_config with:
> 
> ForceCommand /bin/bash
> 
> ..which subsequently prevents, scp, rsync over ssh, and even 


That might stop ssh xfer but doesn't stop

 cat  secretfile|mail -s "Innocent stuff" tome at mydomain 

ftp myhost

etc


> something like "ssh remoteHost 'cat /etc/passwd'", but still allows 
> interactive ssh sessions with a bash shell.



You can still cat /etc/passwd or secretfile from within an nx session.

OK, if secretfile is large then you need ftp myhost etc






I'm not quite sure what you are geting at with this question,
        but I can see two things I think you might mean.






If you are asking about the "nx" username then :- 

( do you know how it all works ?? )

because your FreeNX ssh session consists of :- 

first a remote dsa key-file based ssh connection as user nx
then within that "tunnel"
a localhost ssh password authenticated connection as your user
then
kde gome etc is launched as the user . . 

So
the remote ssh connection is always dsa-key as username "nx" 

User nx :-

1/      has its shell set (in /etc/passwd) to
                 /usr/bin/nxserver
        which is        a restricted shell
                (i.e. not listed in /etc/shells)
so
        your  ForceCommand idea won't work
         cos it uses the user shell to run the command

but also NOTE
                su -s /bin/bash nx
        from a server command line also won't work
                 due to the restricted shell


User nx :-
2/      doesn't have a password set in /etc/shadow

so also 
        su nx won't work (unless you have root access
                already)


User nx :-
3/      has its authorized_keys entry set with:-
                no-port-forwarding,no-X11-forwarding,
                no-agent-forwarding,command="/usr/bin/nxserver"
so
        whatever "command" you run with ssh will be ignored
                i.e  it will always run nxserver anyway even if you run
                ssh   nx at freenx-server /bin/bash
                ssh   nx at freenx-server -s /bin/bash



Also ( did you actually mean this ?? )
Even if you did manage to use
         ForceCommand /bin/bash
 as
         username "nx"
and
got a shell on the FreeNX server, you could almost certainly
transfer anything file which user nx can open by tftp, ftp,
email etc back to your workstation




BUT on the other hand





if you DON'T mean within the "nx" username

i.e.
Your users "user1" etc are  ssh-ing the freenx server using
         password authentication and transfering data
then

to prevent users ssh-ing as themselves you need two sshd
daemons running simultanaously:-


ssh daemon 1
 - allows incoming connections for admins and username "nx"
configured in /etc/ssh/sshd_config_external


                Port 22
                ListenAddress 0.0.0.0
                AllowUsers nx the-administrator
                RSAAuthentication yes
                PubkeyAuthentication yes
                PasswordAuthentication no
                # Well probably no password tho' allowusers
                         may be enough for you . . 


ssh daemon 2
 - allow localhost ssh for the password authenticated login as the user
configured in /etc/ssh/sshd_config_internal


                Port 900
                ListenAddress 127.0.0.1
                AllowGroups freenx-users
                PasswordAuthentication yes

** AND **

set
                SSHD_PORT=900
in
                 /etc/nxserver/node.conf


OR you could leave the
         PasswordAuthentication daemon 1 as Port 22
and
        have the dsa key daemon 2 on Port 900
                 for external connections
        provided  you update the nxclients and
                 any Firewalls along the way

 
> Does anyone have any ideas on how I can provide NX sessions to a 
> remoteHost, yet prevent any data transfers to/from that sameHost 
> over ssh?

If the issue is that your users are sshing in as themselves
the the two ssh daemon config as above will stop that . . .


NOTE
You can't easily prevent users xfering data unless you switch off
all outgoing connections (including email) too

Username nx is fairly safe even tho the users
 "in the know" can copy the client.id_dsa.key
from within the nxclient and connect with ssh


User nx shouldn't have been given access to any data at
all tho'
particularly if you have kept the default key which is
the same on every machine.



>  Using the example above can I ForceCommand the NX 
> tunneling bits, and if so what are they?


Not with username nx

>  Or can NX be configured not to use ssh?

No

> 
> Thank you for your time.
> 
> Mark Christian
 


So what actually did you mean ?????




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20130202/cc14863f/attachment.html>