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

Tue Feb 5 23:51:34 UTC 2013

> From: freenx-knx-bounces at kde.org [mailto:freenx-knx-bounces at kde.org] On
> Behalf Of chris at ccburton.com
> Sent: Saturday, February 02, 2013 1:17 AM
> To: User Support for FreeNX Server and kNX Client
> Subject: Re: [FreeNX-kNX] preventing data transfers over SSH, yet still
> allow NX sessions.
>
>
> 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 ?? )
No, not really, see my response to your suggestion to run 2 ssh daemons.

> 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:-
>
This is exactly what I was looking for.  Thank you for your patience and managing to decipher my cryptic requirements ;)
>
> 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
I plan to run a firewalling blocking outgoing ports from the NX host.

> 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 ?????
>
>

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution,  or copying  of this message, or any attachments, is strictly prohibited.  If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments.  Thank you.