On Tue, Dec 9, 2008 at 09:56, Thomas Koch [off-list ref] wrote:
quoted
Our admin would prefer to not open SSH at all outside our LAN, but
developers would need to have write access also outside the office.
What safer to connect to the LAN than with SSH? What _would_ your
system admin be happy with using?
telnet. I do not jest, this is our sysadmins' stated reasons for not
opening the git port and for tweaking their (mandatory) HTTP proxy to
block HTTP traffic from git.
(Telnet over some horrible impossibly slow buggy proprietary VPN.
It takes >5min to bring up a single connection.)
Do not underestimate the stupidity and hideboundedness of undertrained
system administrators, for it is vast.
On Sat, Dec 13, 2008 at 17:23, Nix [off-list ref] wrote:
telnet. I do not jest, this is our sysadmins' stated reasons for not
opening the git port and for tweaking their (mandatory) HTTP proxy to
block HTTP traffic from git.
I don't know what to say to this :P.
(Telnet over some horrible impossibly slow buggy proprietary VPN.
It takes >5min to bring up a single connection.)
I feel for you man, try and get that guy fired and have them hire some
_real_ sysadmins!
Do not underestimate the stupidity and hideboundedness of undertrained
system administrators, for it is vast.
telnet. I do not jest, this is our sysadmins' stated reasons for not
opening the git port and for tweaking their (mandatory) HTTP proxy to
block HTTP traffic from git.
Wow -- my sympathies!
But on occasion, when real or imaginary issues prevented me
from making a live connection, I have used "git bundle" to
do the job. Not as satisfactory as a real connection, but
when you have a proper, non-fast-forwarding, repo as the
"mother ship", git bundle with some custom procmail scripts
on both sides can work OK enough.
To do that with a public repo you'd have to mirror that on a
home machine and let your restricted environment work
against that.
Do not underestimate the stupidity and hideboundedness of undertrained
system administrators, for it is vast.
These same administrators also underestimate (i) the number
of well connected home machines and (ii) the idea that on
his own machine, everyone is root.
Most of these blocks are "default allow", and your home IP
is not on that list and they don't have the smarts to figure
out that you're getting around their blocks :-) Add dynamic
IP and a dyndns hostname (and dyndns has a hundred or so 2nd
level domains to choose your 3rd level hostname from!) and
clueless admins don't stand a chance.
[sorry this is so badly off-topic...]
this is really a reply to an earlier message that I deleted.
the question was asked 'what would the security people like instead of
SSH'
as a security person who doesn't like how ssh is used for everything, let
me list a couple of concerns.
ssh is default allow (it lets you run any commands), you can lock it down
with effort.
ssh defaults to establishing a tunnel between machines that other network
traffic can use to bypass your system. yes I know that with enough effort
and control of both systems you can tunnel over anything, the point is
that ssh is eager to do this for you (overly eager IMHO)
ssh depends primarily on certificates that reside on untrusted machines.
it can be made to work with tokens or such, but it takes a fair bit of
effort.
sshd runs as root on just about every system
people trust ssh too much. they tend to think that anything is acceptable
if it's done over ssh (this isn't a technical issue, but it is a social
issue)
what would I like to see in an ideal world?
something that runs as the git user, does not enable tunneling, and only
does the data transfer functions needed for a push. it should use
off-the-shelf libraries for certificate authentication and tie into PAM
for additional authentication.
the authentication would not be any better than with SSH, but the rest
would be better. I was very pleased to watch the git-daemon development,
and the emphisis on it running with minimum privilages and provide just
the functionality that was needed, and appropriately assuming that any
connection from the outside is hostile until proven otherwise.
what would I do with current tools?
I would say that developers working from outside should VPN into the
company network before doing the push with SSH rather than exposing the
SSH daemon to the entire Internet.
in the medium term, if the git-over-http gets finished, I would like to
see a seperate cgi created to allow push as well. http is overused as a
tunneling protocol, but it's easy to setup a server that can't do anything
except what you want, so this tunneling is generally not a threat to
servers (it's a horrible threat to client systems)
David Lang
Dear David.
Why do you trust VPN more than the SSH?
I ask because I have just removed the "first VPN then SSH" solution in
favor for a SSH only solution using Gitosis just to get rid of the VPN
which I believe is less secure than SSH (well until I read you comments
below).
I thought I was doing something right for once but maybe I'm not?
Thanks and best regards
Martin
david@lang.hm wrote:
this is really a reply to an earlier message that I deleted.
the question was asked 'what would the security people like instead of
SSH'
as a security person who doesn't like how ssh is used for everything,
let me list a couple of concerns.
ssh is default allow (it lets you run any commands), you can lock it
down with effort.
ssh defaults to establishing a tunnel between machines that other
network traffic can use to bypass your system. yes I know that with
enough effort and control of both systems you can tunnel over
anything, the point is that ssh is eager to do this for you (overly
eager IMHO)
ssh depends primarily on certificates that reside on untrusted
machines. it can be made to work with tokens or such, but it takes a
fair bit of effort.
sshd runs as root on just about every system
people trust ssh too much. they tend to think that anything is
acceptable if it's done over ssh (this isn't a technical issue, but it
is a social issue)
what would I like to see in an ideal world?
something that runs as the git user, does not enable tunneling, and
only does the data transfer functions needed for a push. it should use
off-the-shelf libraries for certificate authentication and tie into
PAM for additional authentication.
the authentication would not be any better than with SSH, but the rest
would be better. I was very pleased to watch the git-daemon
development, and the emphisis on it running with minimum privilages
and provide just the functionality that was needed, and appropriately
assuming that any connection from the outside is hostile until proven
otherwise.
what would I do with current tools?
I would say that developers working from outside should VPN into the
company network before doing the push with SSH rather than exposing
the SSH daemon to the entire Internet.
in the medium term, if the git-over-http gets finished, I would like
to see a seperate cgi created to allow push as well. http is overused
as a tunneling protocol, but it's easy to setup a server that can't do
anything except what you want, so this tunneling is generally not a
threat to servers (it's a horrible threat to client systems)
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear David.
Why do you trust VPN more than the SSH?
I ask because I have just removed the "first VPN then SSH" solution in favor
for a SSH only solution using Gitosis just to get rid of the VPN which I
believe is less secure than SSH (well until I read you comments below).
I thought I was doing something right for once but maybe I'm not?
Thanks and best regards
Martin
in part it's that a VPN is a single point of control for all remote
access.
If you use ssh you end up exposing all the individual machines
1. data leakage of just what machines exist to possibly hostile users.
2. the many machines are configured seperatly, frequently by different
people. this makes it far more likely that sometime some machine will get
misconfigured.
3. people who are focused on providing features have a strong temptation
to cut corners and just test that the feature works and not test that
everything that isn't supposed to work actually doesn't work. as a
result, in many companies there is a deliberate seperation (and tension)
between a group focused on controlling and auditing access and one that is
focused on creating fucntionality and features.
also from a polical/social point of view everyone recognises that if you
grant someone VPN access you are trusting them, but people don't seem to
think the same way with ssh.
David Lang
david@lang.hm wrote:
quoted
this is really a reply to an earlier message that I deleted.
the question was asked 'what would the security people like instead of SSH'
as a security person who doesn't like how ssh is used for everything, let
me list a couple of concerns.
ssh is default allow (it lets you run any commands), you can lock it down
with effort.
ssh defaults to establishing a tunnel between machines that other network
traffic can use to bypass your system. yes I know that with enough effort
and control of both systems you can tunnel over anything, the point is that
ssh is eager to do this for you (overly eager IMHO)
ssh depends primarily on certificates that reside on untrusted machines. it
can be made to work with tokens or such, but it takes a fair bit of effort.
sshd runs as root on just about every system
people trust ssh too much. they tend to think that anything is acceptable
if it's done over ssh (this isn't a technical issue, but it is a social
issue)
what would I like to see in an ideal world?
something that runs as the git user, does not enable tunneling, and only
does the data transfer functions needed for a push. it should use
off-the-shelf libraries for certificate authentication and tie into PAM for
additional authentication.
the authentication would not be any better than with SSH, but the rest
would be better. I was very pleased to watch the git-daemon development,
and the emphisis on it running with minimum privilages and provide just the
functionality that was needed, and appropriately assuming that any
connection from the outside is hostile until proven otherwise.
what would I do with current tools?
I would say that developers working from outside should VPN into the
company network before doing the push with SSH rather than exposing the SSH
daemon to the entire Internet.
in the medium term, if the git-over-http gets finished, I would like to see
a seperate cgi created to allow push as well. http is overused as a
tunneling protocol, but it's easy to setup a server that can't do anything
except what you want, so this tunneling is generally not a threat to
servers (it's a horrible threat to client systems)
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:46
david@lang.hm writes:
this is really a reply to an earlier message that I deleted.
the question was asked 'what would the security people like instead of
SSH'
as a security person who doesn't like how ssh is used for everything,
let me list a couple of concerns.
ssh is default allow (it lets you run any commands), you can lock it
down with effort.
How is VPN better than that?
ssh defaults to establishing a tunnel between machines that other
network traffic can use to bypass your system. yes I know that with
enough effort and control of both systems you can tunnel over
anything, the point is that ssh is eager to do this for you (overly
eager IMHO)
How is VPN better than that?
ssh depends primarily on certificates that reside on untrusted
machines. it can be made to work with tokens or such, but it takes a
fair bit of effort.
There probably VPN differs...
sshd runs as root on just about every system
And VPN doesn't?
[...]
The idea with using SSH was, I think, that it is easier and better to
use existing solution for authentication and authorization than roll
your own (see the case of CVS pserver, and Subversion svnserve).
--
Jakub Narebski
Poland
ShadeHawk on #git
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:46
Sitaram Chamarty [off-list ref] writes:
On 2008-12-13, Nix [off-list ref] wrote:
quoted
telnet. I do not jest, this is our sysadmins' stated reasons for not
opening the git port and for tweaking their (mandatory) HTTP proxy to
block HTTP traffic from git.
Wow -- my sympathies!
But on occasion, when real or imaginary issues prevented me
from making a live connection, I have used "git bundle" to
do the job. Not as satisfactory as a real connection, but
when you have a proper, non-fast-forwarding, repo as the
"mother ship", git bundle with some custom procmail scripts
on both sides can work OK enough.
Perhaps one would be interested in adding bundle support to gitweb.
The problem is in the interface, but I think in simplest case gitweb
could present 'bundle' link along snapshot link(s) in the 'heads' view
(showing branches), which link would generate bundle for a given
branch, starting from latest annotated tag. But this is only for
download...
Another solution would be to help with "smart" HTTP protocol,
i.e. git-over-http solution. This would hopefully change signature so
at least for some time it would pas proxy filters. Also only for
download.
BTW. is outgoing SSH transport (from network to outside) blocked as
well?
--
Jakub Narebski
Poland
ShadeHawk on #git
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:46
david@lang.hm writes:
On Sun, 14 Dec 2008, martin wrote:
quoted
Dear David.
Why do you trust VPN more than the SSH?
I ask because I have just removed the "first VPN then SSH" solution
in favor for a SSH only solution using Gitosis just to get rid of
the VPN which I believe is less secure than SSH (well until I read
you comments below).
I thought I was doing something right for once but maybe I'm not?
Thanks and best regards
Martin
in part it's that a VPN is a single point of control for all remote
access.
If you use ssh you end up exposing all the individual machines
1. data leakage of just what machines exist to possibly hostile users.
Errr... what? One of established practices is expose only _one_
machine to outside; you have to SSH to gateway.
2. the many machines are configured seperatly, frequently by different
people. this makes it far more likely that sometime some machine will
get misconfigured.
See above.
3. people who are focused on providing features have a strong
temptation to cut corners and just test that the feature works and not
test that everything that isn't supposed to work actually doesn't
work. as a result, in many companies there is a deliberate seperation
(and tension) between a group focused on controlling and auditing
access and one that is focused on creating fucntionality and features.
And that differs from VPN in what way?
also from a polical/social point of view everyone recognises that if
you grant someone VPN access you are trusting them, but people don't
seem to think the same way with ssh.
Errr... what? I think everybody knows that unrestricted SSH access
(without limiting done by shell used) means that you trust user.
--
Jakub Narebski
Poland
ShadeHawk on #git
Dear David.
Why do you trust VPN more than the SSH?
I ask because I have just removed the "first VPN then SSH" solution
in favor for a SSH only solution using Gitosis just to get rid of the
VPN which I believe is less secure than SSH (well until I read you
comments below).
I thought I was doing something right for once but maybe I'm not?
Thanks and best regards
Martin
in part it's that a VPN is a single point of control for all remote
access.
If you use ssh you end up exposing all the individual machines
1. data leakage of just what machines exist to possibly hostile users.
2. the many machines are configured seperatly, frequently by different
people. this makes it far more likely that sometime some machine will
get misconfigured.
3. people who are focused on providing features have a strong
temptation to cut corners and just test that the feature works and not
test that everything that isn't supposed to work actually doesn't
work. as a result, in many companies there is a deliberate seperation
(and tension) between a group focused on controlling and auditing
access and one that is focused on creating fucntionality and features.
also from a polical/social point of view everyone recognises that if
you grant someone VPN access you are trusting them, but people don't
seem to think the same way with ssh.
David Lang
I opened port 22 in the firewall to just those hosts that I need to
reach, which is one in this case...the rest of the machines I cannot reach.
I did a brief port scan and the thing is silent... so I don't think I
reveal any of the other hosts... but I should not say is it's secure
with your measures...
Your point two I don't understand... If you are in charge of the
firewall you also know what machines you let people reach. If these
machines are numerous then I think there is a management problem
somewhere else...
Point 3 is correct but I fail to see how this is less of a problem with
VPN than SSH.
Thanks and Best regards
Martin
On 2008-12-14, david@lang.hm [off-list ref] wrote:
On Sun, 14 Dec 2008, martin wrote:
quoted
Why do you trust VPN more than the SSH?
in part it's that a VPN is a single point of control for all remote
access.
If you use ssh you end up exposing all the individual machines
Need not be true. None of my internal servers aer even
accessible from the outside world; they're all in RFC1918
space and there's only one gateway. This *is* my single
point of control.
I can setup different port numbers to forward to different
internal servers (ssh, http, whatever I wish); that may
sound like a form of "exposing" but in reality it's a lot
*more* restrictive than setting up a VPN and granting access
to it.
I actually don't like VPNs; they imply that you're "inside"
the network in some way, and I hate blurring that
distinction. If I'm outside, I want to be acutely aware of
it, and the fact that I can't even ping one of the inside
hosts or see what's on it, or do anything other than what is
specifically allowed by the gateway, is one way of ensuring
this.
this is really a reply to an earlier message that I deleted.
the question was asked 'what would the security people like instead of
SSH'
as a security person who doesn't like how ssh is used for everything,
let me list a couple of concerns.
ssh is default allow (it lets you run any commands), you can lock it
down with effort.
How is VPN better than that?
quoted
ssh defaults to establishing a tunnel between machines that other
network traffic can use to bypass your system. yes I know that with
enough effort and control of both systems you can tunnel over
anything, the point is that ssh is eager to do this for you (overly
eager IMHO)
How is VPN better than that?
quoted
ssh depends primarily on certificates that reside on untrusted
machines. it can be made to work with tokens or such, but it takes a
fair bit of effort.
There probably VPN differs...
quoted
sshd runs as root on just about every system
And VPN doesn't?
you aren't having the VPN software running commands passed to it by the
outside world.
[...]
The idea with using SSH was, I think, that it is easier and better to
use existing solution for authentication and authorization than roll
your own (see the case of CVS pserver, and Subversion svnserve).
I'm not saying that it's good to roll your own from scratch, you need to
use libraries that have been examined and validated, but SSH is a swiss
army knife, it's designed to do lots of things, and when you are exposing
things to the outside world you want them to be as limited as possible to
limit the damage that they can do.
David Lang
Dear David.
Why do you trust VPN more than the SSH?
I ask because I have just removed the "first VPN then SSH" solution
in favor for a SSH only solution using Gitosis just to get rid of
the VPN which I believe is less secure than SSH (well until I read
you comments below).
I thought I was doing something right for once but maybe I'm not?
Thanks and best regards
Martin
in part it's that a VPN is a single point of control for all remote
access.
If you use ssh you end up exposing all the individual machines
1. data leakage of just what machines exist to possibly hostile users.
Errr... what? One of established practices is expose only _one_
machine to outside; you have to SSH to gateway.
that works for sysadmin access to a box, it doesn't work for git push
(unless that box also happens to be your git repository). multiply by a
few dozen different applications that all take the attitude 'just us SSH
and you are secure' and you end up with a bunch of machines that _have_ to
be exposed via SSH.
quoted
2. the many machines are configured seperatly, frequently by different
people. this makes it far more likely that sometime some machine will
get misconfigured.
See above.
quoted
3. people who are focused on providing features have a strong
temptation to cut corners and just test that the feature works and not
test that everything that isn't supposed to work actually doesn't
work. as a result, in many companies there is a deliberate seperation
(and tension) between a group focused on controlling and auditing
access and one that is focused on creating fucntionality and features.
And that differs from VPN in what way?
the VPN is typically (but not always) run by the group who is focused on
controlling and auditing access.
quoted
also from a polical/social point of view everyone recognises that if
you grant someone VPN access you are trusting them, but people don't
seem to think the same way with ssh.
Errr... what? I think everybody knows that unrestricted SSH access
(without limiting done by shell used) means that you trust user.
you would be surprised.
I'm not saying that SSH is bad for all uses by any means. I'm responding
to the people who seemd to be thinking that anyone who didn't like the
'use SSH' option are luddites and just don't know what they are doing.
different networks can have different stances and all be right (for their
environment)
David Lang
Dear David.
Why do you trust VPN more than the SSH?
I ask because I have just removed the "first VPN then SSH" solution in
favor for a SSH only solution using Gitosis just to get rid of the VPN
which I believe is less secure than SSH (well until I read you comments
below).
I thought I was doing something right for once but maybe I'm not?
Thanks and best regards
Martin
in part it's that a VPN is a single point of control for all remote access.
If you use ssh you end up exposing all the individual machines
1. data leakage of just what machines exist to possibly hostile users.
2. the many machines are configured seperatly, frequently by different
people. this makes it far more likely that sometime some machine will get
misconfigured.
3. people who are focused on providing features have a strong temptation to
cut corners and just test that the feature works and not test that
everything that isn't supposed to work actually doesn't work. as a result,
in many companies there is a deliberate seperation (and tension) between a
group focused on controlling and auditing access and one that is focused on
creating fucntionality and features.
also from a polical/social point of view everyone recognises that if you
grant someone VPN access you are trusting them, but people don't seem to
think the same way with ssh.
David Lang
I opened port 22 in the firewall to just those hosts that I need to reach,
which is one in this case...the rest of the machines I cannot reach.
I did a brief port scan and the thing is silent... so I don't think I reveal
any of the other hosts... but I should not say is it's secure with your
measures...
Your point two I don't understand... If you are in charge of the firewall
you also know what machines you let people reach. If these machines are
numerous then I think there is a management problem somewhere else...
two things here
1. if you are running multiple different applications that all want to be
exposed via port 22 (like git for 'git push') then you may need to expose
numerous machines. tools that use SSH don't tend to have the ability to
use a gateway box before they start executing commands, they assume that
you will SSH directly into the destination box.
2. many people take the attitude that SSH is secure, period, end of
statement. so they think that every machine should be able to be contacted
via SSH, and you can then use SSH to do any other functionality on any
machine that you can dream up. a small minority of people try to minimize
what boxes are exposed directly (you are one of them), but most don't
David Lang
On 2008-12-14, david@lang.hm [off-list ref] wrote:
quoted
On Sun, 14 Dec 2008, martin wrote:
quoted
Why do you trust VPN more than the SSH?
in part it's that a VPN is a single point of control for all remote
access.
If you use ssh you end up exposing all the individual machines
Need not be true. None of my internal servers aer even
accessible from the outside world; they're all in RFC1918
space and there's only one gateway. This *is* my single
point of control.
I can setup different port numbers to forward to different
internal servers (ssh, http, whatever I wish); that may
sound like a form of "exposing" but in reality it's a lot
*more* restrictive than setting up a VPN and granting access
to it.
if you setup multiple inbound redirects for SSH (be they different IP
addresses or different ports), then you have the exact same situation as
those machines being accessed directly.
I actually don't like VPNs; they imply that you're "inside"
the network in some way, and I hate blurring that
distinction. If I'm outside, I want to be acutely aware of
it, and the fact that I can't even ping one of the inside
hosts or see what's on it, or do anything other than what is
specifically allowed by the gateway, is one way of ensuring
this.
this is the mindset about SSH that I don't like. I see allowing SSH in as
blurring that distinction.
With a VPN you aren't blurring it, you _are_ letting the person into your
network. it's not appropriate to do this for everyone, but in the initial
post the desire was to have trusted company employees working remotely
push data to the repository. In that scenerio a VPN makes sense. If you
were doing a distributed opensource project it would probably not make
sense to allow contributers that you only know via e-mail to VPN into a
network to do their push (it can be agued that they shouldn't be doing a
push at all, but that's a workflow discussion ;-)
many people who would never allow a person to VPN into a network seem to
have no problem with that same person useing SSH to login to a machine on
that same network (and usually without trying to setup a limited shell).
In my opinion SSH and VPN access are both in the same category.
In both cases you can limit what the person you are granting access can
do. with a VPN you would use a firewall to control what they can access
after connecting to the VPN, with SSH you have to have the server they are
connecting to configured to limit what they can do.
VPNs tend to have better tools for auditing access and doing strong
authentication other than certificates (even certificate plus password is
better than just certificate). cerificates are good and useful, but they
aren't always enough by themselves.
there have been a number of breeches over the last few years that have
resulted from one client machine with SSH being comprimized and the
credentials then used to hop to other machines, gather other credentials
to then use to comprimize other machines, etc. while I am sure that there
have also been networks comprimized via VPN, I haven't heard of any
daisy-chain type attacks involving VPN access.
SSH is a monoculture. there is essentially only one implementation that is
used (although there are patches to it in some cases), and while it is
pretty good, any problems with it give you no options. with VPNs there are
many implementations, if any one has a problem it's possible to replace it
(painful to change out clients, but possible)
David Lang
as a security person who doesn't like how ssh is used for everything,
let me list a couple of concerns.
ssh is default allow (it lets you run any commands), you can lock it
down with effort.
ssh defaults to establishing a tunnel between machines that other
network traffic can use to bypass your system. yes I know that with
enough effort and control of both systems you can tunnel over anything,
the point is that ssh is eager to do this for you (overly eager IMHO)
ssh depends primarily on certificates that reside on untrusted machines.
it can be made to work with tokens or such, but it takes a fair bit of
effort.
sshd runs as root on just about every system
people trust ssh too much. they tend to think that anything is
acceptable if it's done over ssh (this isn't a technical issue, but it
is a social issue)
what would I like to see in an ideal world?
something that runs as the git user, does not enable tunneling, and only
does the data transfer functions needed for a push. it should use
off-the-shelf libraries for certificate authentication and tie into PAM
for additional authentication.
How about a git-specific deployment/configuration of ssh? You can
certainly run multiple copies of SSH (on different ports), by providing
a restricted configuration file you can disable tunneling and any other
functionality that you don't like.
And if you want it to run as a non-root user, simply choose a port>1024,
but keep in mind that you won't be able to authenticate by password
(IIRC, only key auth will work when running non-root), or setuid to
those users when they log in. Nonetheless, this could be sufficient for
gitosis, since everything runs as the specified user anyway, and IIRC,
gitosis wants individual SSH pubkeys to allow access.
the authentication would not be any better than with SSH, but the rest
would be better. I was very pleased to watch the git-daemon development,
and the emphisis on it running with minimum privilages and provide just
the functionality that was needed, and appropriately assuming that any
connection from the outside is hostile until proven otherwise.
In another mail, David wrote:
1. if you are running multiple different applications that all want
to be exposed via port 22 (like git for 'git push') then you may need
to expose numerous machines. tools that use SSH don't tend to have the
ability to use a gateway box before they start executing commands,
they assume that you will SSH directly into the destination box.
In many cases, especially if the tool is unix based, you can specify (in
~/.ssh/config) a Proxy command that is executed before the SSH protocol
negotiation begins, which results in stdin and stdout being connected to
the SSH daemon at the destination. The most common variations are the
HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
the limit in terms of what is possible.
Rogan
On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
quoted
1. if you are running multiple different applications that all want to be
exposed via port 22 (like git for 'git push') then you may need to expose
numerous machines. tools that use SSH don't tend to have the ability to
use a gateway box before they start executing commands, they assume that
you will SSH directly into the destination box.
But ssh itself allows you to do proxying. See ProxyCommand in
ssh_config's manpage.
I was not aware of that option, but it looks like it's designed to be one
setting for all your ssh communications, so unless you always use the same
gateway box to get to your destination you would need to tweak your ssh
config for each different thing that you are doing.
David Lang
as a security person who doesn't like how ssh is used for everything,
let me list a couple of concerns.
ssh is default allow (it lets you run any commands), you can lock it
down with effort.
ssh defaults to establishing a tunnel between machines that other
network traffic can use to bypass your system. yes I know that with
enough effort and control of both systems you can tunnel over anything,
the point is that ssh is eager to do this for you (overly eager IMHO)
ssh depends primarily on certificates that reside on untrusted machines.
it can be made to work with tokens or such, but it takes a fair bit of
effort.
sshd runs as root on just about every system
people trust ssh too much. they tend to think that anything is
acceptable if it's done over ssh (this isn't a technical issue, but it
is a social issue)
what would I like to see in an ideal world?
something that runs as the git user, does not enable tunneling, and only
does the data transfer functions needed for a push. it should use
off-the-shelf libraries for certificate authentication and tie into PAM
for additional authentication.
How about a git-specific deployment/configuration of ssh? You can
certainly run multiple copies of SSH (on different ports), by providing
a restricted configuration file you can disable tunneling and any other
functionality that you don't like.
And if you want it to run as a non-root user, simply choose a port>1024,
but keep in mind that you won't be able to authenticate by password
(IIRC, only key auth will work when running non-root), or setuid to
those users when they log in. Nonetheless, this could be sufficient for
gitosis, since everything runs as the specified user anyway, and IIRC,
gitosis wants individual SSH pubkeys to allow access.
IMHO this is better then exposing a 'normal' ssh daemon to the Internet
just to be able to do a git push. the fact that you loose authentication
options is not a good thing, are you sure that you cannot hook into PAM
authentication for this?
quoted
the authentication would not be any better than with SSH, but the rest
would be better. I was very pleased to watch the git-daemon development,
and the emphisis on it running with minimum privilages and provide just
the functionality that was needed, and appropriately assuming that any
connection from the outside is hostile until proven otherwise.
In another mail, David wrote:
quoted
1. if you are running multiple different applications that all want
to be exposed via port 22 (like git for 'git push') then you may need
to expose numerous machines. tools that use SSH don't tend to have the
ability to use a gateway box before they start executing commands,
they assume that you will SSH directly into the destination box.
In many cases, especially if the tool is unix based, you can specify (in
~/.ssh/config) a Proxy command that is executed before the SSH protocol
negotiation begins, which results in stdin and stdout being connected to
the SSH daemon at the destination. The most common variations are the
HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
the limit in terms of what is possible.
as I just commented, this looks like it's a per-user config option that is
designed to be used as a proxy out of the network you are in to get to the
Internet, not to be used at the far side of a connection to get to things
on a remote network. as I understand it, you would need to change this
config file for each different destination network you need to connect to.
David Lang
what would I like to see in an ideal world?
something that runs as the git user, does not enable tunneling, and only
does the data transfer functions needed for a push. it should use
off-the-shelf libraries for certificate authentication and tie into PAM
for additional authentication.
How about a git-specific deployment/configuration of ssh? You can
certainly run multiple copies of SSH (on different ports), by providing
a restricted configuration file you can disable tunneling and any other
functionality that you don't like.
And if you want it to run as a non-root user, simply choose a port>1024,
but keep in mind that you won't be able to authenticate by password
(IIRC, only key auth will work when running non-root), or setuid to
those users when they log in. Nonetheless, this could be sufficient for
gitosis, since everything runs as the specified user anyway, and IIRC,
gitosis wants individual SSH pubkeys to allow access.
IMHO this is better then exposing a 'normal' ssh daemon to the Internet
just to be able to do a git push. the fact that you loose authentication
options is not a good thing, are you sure that you cannot hook into PAM
authentication for this?
I *think* that an unprivileged user cannot invoke PAM for accounts other
than its own, and most certainly cannot change to that other user
without being setuid (or having the appropriate capability).
quoted
In many cases, especially if the tool is unix based, you can specify (in
~/.ssh/config) a Proxy command that is executed before the SSH protocol
negotiation begins, which results in stdin and stdout being connected to
the SSH daemon at the destination. The most common variations are the
HTTP and Socks proxy connectors (e.g. corkscrew?), but the sky is really
the limit in terms of what is possible.
as I just commented, this looks like it's a per-user config option that
is designed to be used as a proxy out of the network you are in to get
to the Internet, not to be used at the far side of a connection to get
to things on a remote network. as I understand it, you would need to
change this config file for each different destination network you need
to connect to.
That may be its original intention, but it can nonetheless be used for
other purposes. Yes, you might need a different configuration for each
network that you need to access, and quite possibly for each location
that you need to access them from. This may result in config entry
proliferation, but it is manageable, especially with the openssh
wildcard syntax in the config file.
man ssh_config:
Host
Restricts the following declarations (up to the next Host keyword) to be
only for those hosts that match one of the patterns given after the
keyword. If more than one pattern is provided, they should be separated
by whitespace. A single `*' as a pattern can be used to provide global
defaults for all hosts. The host is the hostname argument given on the
command line (i.e. the name is not converted to a canonicalized host
name before matching).
e.g
Host *-home
ProxyCommand . . . .
FWIW.
Rogan
From: Mike Hommey <hidden> Date: 2016-06-15 22:45:46
On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
1. if you are running multiple different applications that all want to be
exposed via port 22 (like git for 'git push') then you may need to expose
numerous machines. tools that use SSH don't tend to have the ability to
use a gateway box before they start executing commands, they assume that
you will SSH directly into the destination box.
But ssh itself allows you to do proxying. See ProxyCommand in
ssh_config's manpage.
Mike
From: Mike Hommey <hidden> Date: 2016-06-15 22:45:46
On Mon, Dec 15, 2008 at 12:25:53AM -0800, david@lang.hm wrote:
On Mon, 15 Dec 2008, Mike Hommey wrote:
quoted
On Sun, Dec 14, 2008 at 05:00:14PM -0800, david@lang.hm wrote:
quoted
1. if you are running multiple different applications that all want to be
exposed via port 22 (like git for 'git push') then you may need to expose
numerous machines. tools that use SSH don't tend to have the ability to
use a gateway box before they start executing commands, they assume that
you will SSH directly into the destination box.
But ssh itself allows you to do proxying. See ProxyCommand in
ssh_config's manpage.
I was not aware of that option, but it looks like it's designed to be one
setting for all your ssh communications, so unless you always use the
same gateway box to get to your destination you would need to tweak your
ssh config for each different thing that you are doing.
But ssh itself allows you to do proxying. See ProxyCommand in
ssh_config's manpage.
I think that's exactly the point David Lang is making.
For the security-paranoid, maybe the approach gitosis should take
is to develop an ssh subserver (like sftp). The possibilities for
restricted access and configuration are greatly expanded by such an
approach. One could configure "sgit" to chroot into some account-specific
subdirectory. The sshd configuration can be tweaked to allow sgit access
but not terminal or exec request (or port forwarding) access, perhaps
dependent on group membership.