To be able to connect to Xvnc over the encrypted SSH channel, we create a SSH TCP forwarding to Xvnc. This requires that the ssh daemon is configured with AllowTcpForwarding. This also means that it is possible to request forwarding to other ports and services, in addition to Xvnc. In some cases, this is unwanted. One solution could be to dynamically add and remove local iptables firewall rules. Another solution, which is likely better, is to use the OpenSSH daemon configuration option "PermitOpen". In this case, we need to dynamically add and remove such lines, then send a SIGHUP so the daemon, so that it reloads the configuration. This needs to be done on the agent, as root. It could either be done by vsmagent or tl-session. One advantage with the latter is that it can more easily clean up when the session is finished. One advantage with doing it in (the non-forked portion of) vsmagent, though, is that we would avoid locking/concurrency problems. Also, tl-session is written in C, while vsmagent is written in Python.
There are also two possible approaches when updating sshd_config: 1) We could just add and remove the session that is started/ended. However, vsmagent cannot easily detected an ended session. or 2) We could re-generate all PermitOpen lines, so that it reflects the current status of the system. tl-limit-printer uses this approach. However, vsmagent is stateless and thus does not have any information about current sessions on the machine, but I guess it could enumerate the existing Xvnc processes running on the system.
Implemented in 27390.
Shadowing issues documented in 27391. Closing.
Tested using 3966 on SLED11 Sp2 and connection fails... Client side: 2013-05-30T14:03:15: vncviewer[E]: CConn: connected to host 127.0.0.1 port 34000 2013-05-30T14:03:15: ssh[E]: channel 2: open failed: administratively prohibited: open failed 2013-05-30T14:03:15: vncviewer[E]: CConn: End of stream 2013-05-30T14:03:15: Process 18427 exited with code 0 2013-05-30T14:03:15: Process 18432 exited with code 0 Server side: 2013-05-30 14:02:45 INFO vsmagent: VSM Agent version 4.0.0post build 3966 started 2013-05-30 14:02:45 INFO vsmagent: My public hostname is dhcp-254-187.lkpg.cendio.se 2013-05-30 14:02:46 ERROR vsmagent: Unable to read sshd pid from /var/run/sshd.pid localhost:/etc/ssh # cat /var/run/ss sshd.init.pid sssd.pid
(In reply to comment #8) > Tested using 3966 on SLED11 Sp2 and connection fails... > > Client side: > 2013-05-30T14:03:15: vncviewer[E]: CConn: connected to host 127.0.0.1 > port 34000 > 2013-05-30T14:03:15: ssh[E]: channel 2: open failed: administratively > prohibited: open failed > 2013-05-30T14:03:15: vncviewer[E]: CConn: End of stream > 2013-05-30T14:03:15: Process 18427 exited with code 0 > 2013-05-30T14:03:15: Process 18432 exited with code 0 > > > Server side: > > 2013-05-30 14:02:45 INFO vsmagent: VSM Agent version 4.0.0post build 3966 > started > 2013-05-30 14:02:45 INFO vsmagent: My public hostname is > dhcp-254-187.lkpg.cendio.se > 2013-05-30 14:02:46 ERROR vsmagent: Unable to read sshd pid from > /var/run/sshd.pid > localhost:/etc/ssh # cat /var/run/ss > sshd.init.pid sssd.pid Re-fixed in 27467.
Verified following tests on ubuntu 12.04 and it works as expected. - ssh anyuser@host -L [5999/10000]:localhost:10000 and tried to telnet to local port, got connection refused and following debug output was shown by ssh "administratively prohibited: open failed". - logged on using thinlinc and verified that an entry corresponding to user showed up in sshd_config, also verified that it was cleared at normal logout and by killing tl-session process.
When testing with multiple session for same user, it fails because it seems several PermitOpen rules should be whitespace seperated instead of several rows as current implementation does. It should be: Match User cendio PermitOpen 127.0.0.1:5901 127.0.0.1:5901 instead of. Match User cendio PermitOpen 127.0.0.1:5901 PermitOpen 127.0.0.1:5902
(In reply to comment #11) > When testing with multiple session for same user, it fails because it seems > several PermitOpen rules should be whitespace seperated instead of several rows > as current implementation does. > > > It should be: > > Match User cendio > PermitOpen 127.0.0.1:5901 127.0.0.1:5901 > > > instead of. > > Match User cendio > PermitOpen 127.0.0.1:5901 > PermitOpen 127.0.0.1:5902 Fixed in 27471.
(In reply to comment #12) > (In reply to comment #11) > > When testing with multiple session for same user, it fails because it seems > > several PermitOpen rules should be whitespace seperated instead of several rows > > as current implementation does. > > > > > > It should be: > > > > Match User cendio > > PermitOpen 127.0.0.1:5901 127.0.0.1:5901 > > > > > > instead of. > > > > Match User cendio > > PermitOpen 127.0.0.1:5901 > > PermitOpen 127.0.0.1:5902 > > Fixed in 27471. Verified using build 3970 on ubuntu 12.04.
Reviewed the documentation and it looks good but it raised the following questions. If using the port forwarding restriction it will break the shadowing functionality due to shadow'er wont have access and must explicitly been added to sshd_config to allow all port forwarding to sessione he wants to shadow. Couldn't this been done using same semantics as for normal sessions, somthine like; if new session is created, update all shadowers PermitOpen with the new session port ?
(In reply to comment #14) > Reviewed the documentation and it looks good but it raised the following > questions. > > If using the port forwarding restriction it will break the shadowing > functionality due to shadow'er wont have access and must explicitly been added > to sshd_config to allow all port forwarding to sessione he wants to shadow. > Couldn't this been done using same semantics as for normal sessions, somthine > like; if new session is created, update all shadowers PermitOpen with the new > session port ? Apprently this is not doable due to shadowers are defined in vsmserver.hconf and might not be availble on the agent where the specific sshd configuration lives.
Verified functionality in a cluster setup using ThinLinc build 3970 and i could break the functionality, closing hereby this issue.
