> First, it is kind of foolish to assume that anyone with an
unrestricted ssh login doesn't have complete access to all the data
that account can read (or reach from either side of the connection),
but also note that this is the opposite case, where the connection
origin and tunnel destination are on the 'less secure' side and the
controlling keys are also outside.
Oh, Les, this clown was doing both and all and simply treating security as
"something that stops me from getting my important work done". It's
understandable: blindly applied policies do encourage people to simply work
around them, and encourage people to work around them. Blindly applied
workarounds are a similar problem. Simply setting up SSH tunnels, without
some serious thought about how to keep it off the radar of the script
kiddies, or keep it tied to Subversion repository mirroring alone and not
abused for other purposes is one that needs serious thought.
For example, a quick review of SSH daemon configurations allows one to set
up an SSH daemon that is dedicated to Subversion SSH tunnels, with a
restricted and forced specific SSH public key matched to the daemon that
can only be used by the specific tunnel user, tied to the Subversion
server's restricted access. But that takes significant extra work, and root
privileges to start if the daemon is going to run on low numbered ports,
and even SELinux considerations if that's enabled on either end.
Received on 2013-09-18 01:26:36 CEST