david@xxxxxxx wrote: > On Mon, 15 Dec 2008, Rogan Dawes wrote: > >> david@xxxxxxx wrote: >> >>> >>> 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). >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
