Re: [gitolite] fatal: unrecognized command '/opt/git/gitolite/src/gitolite-shell git'

[milki]

On 07:26 Tue 12 Feb , Pedro Albuquerque wrote:
> Hi guys,
>
> I installed the new gitolite version and after following the steps, I got this message when I try to clone the gitolite-admin repo:

How did you install and what OS?

>
> bash-4.1$ git clone git@<hostname>:gitolite-admin.git
> Initialized empty Git repository in /opt/git/gitolite-admin/.git/
> fatal: unrecognized command '/opt/git/gitolite/src/gitolite-shell git'
> fatal: The remote end hung up unexpectedly

Does /opt/git/gitolite/src/gitolite-shell exist?

--
milki

[Pedro Albuquerque]

Hi,

I installed on Red Hat 6.3 and used the current gitolite (git clone git://github.com/sitaramc/gitolite).
This cloned repo is on the git home directory: /opt/git

I ran gitolite/install -ln. The symlink exists on /opt/git/bin/gitolite to /opt/git/gitolite/src/gitolite. The git PATH also contains /opt/git/bin.
Then I ran gitolite setup -pk git.pub. This public key was created with ssh-keygen -t rsa and copied from id_rsa.pub.

The /opt/git/gitolite/src/gitolite-shell exists.

Thanks.
Pedro.

milki

13 February 2013 00:01

Pedro Albuquerque

12 February 2013 15:26

Hi guys,

I installed the new gitolite version and after following the steps, I got this message when I try to clone the gitolite-admin repo:

bash-4.1$ git clone git@<hostname>:gitolite-admin.git
Initialized empty Git repository in /opt/git/gitolite-admin/.git/
fatal: unrecognized command '/opt/git/gitolite/src/gitolite-shell git'
fatal: The remote end hung up unexpectedly

Can you help me please?

Thanks,
Pedro.

[Sitaram Chamarty]

On Tue, Feb 12, 2013 at 8:56 PM, Pedro Albuquerque <pedr...@gmail.com> wrote:

> fatal: unrecognized command '/opt/git/gitolite/src/gitolite-shell git'

weird. It appears to be taking the command *and* its argument
together as one argument.

[Ralf Hemmecke]

>>> bash-4.1$ git clone git@<hostname>:gitolite-admin.git
>>> Initialized empty Git repository in /opt/git/gitolite-admin/.git/
>>> fatal: unrecognized command '/opt/git/gitolite/src/gitolite-shell git'
>>> fatal: The remote end hung up unexpectedly

What do you see in ~/.ssh/authorized_keys. (Exact copy of the part that
comes before the actual public key.)

You should have something like

command="/home/git/gitolite/src/gitolite-shell foo"

What is yours? In particular are there other/more quotes?

Ralf

[Pedro Albuquerque]

Hi,

I have this in the authorization_keys:

# gitolite start

command="/opt/git/gitolite/src/gitolite-shell git",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa <public_key>

# gitolite end

Thanks,

Pedro.

[Pedro Albuquerque]

And if I run it with git user in the shell I get the following:

bash-4.1$ /opt/git/gitolite/src/gitolite-shell git

hello git, this is git@ves-ebi-ef running gitolite3 v3.3-10-g293df79-dt on git 1.7.1

 R W gitolite-admin

 R W testing

[Ralf Hemmecke]

Your entry in the authorized_keys file looks OK to me.
Is that the only entry in authorized keys or do you have more entries?

On 02/18/2013 10:34 AM, Pedro Albuquerque wrote:
> And if I run it with git user in the shell I get the following:
>
> bash-4.1$ /opt/git/gitolite/src/gitolite-shell git
> hello git, this is git@ves-ebi-ef running gitolite3 v3.3-10-g293df79-dt on
> git 1.7.1
>
> R W gitolite-admin
> R W testing

That's OK. Do you also get this output for

ssh git@yourgitserver info

?

Ralf

[Pedro Albuquerque]

Hi,

This is the only entry in that file.
Why running it in the shell works?

The secure log shows that the ssh call was successful.

Pedro.

[Ralf Hemmecke]

> Why running it in the shell works?

Why shouldn't it work?

Your problem seems to be in connection with ssh.

So what does

ssh git@yourgitserver info

give? Still your

fatal: unrecognized command '/opt/git/gitolite/src/gitolite-shell git'

> The secure log shows that the ssh call was successful.

??? So where is your problem?

Ralf

[Pedro Albuquerque]

/var/log/secure

2013-02-18T11:14:24.681366+00:00 ves-ebi-ef sshd[17702]: Accepted publickey for git from 10.3.2.239 port 59016 ssh2

2013-02-18T11:14:24.685212+00:00 ves-ebi-ef sshd[17702]: pam_unix(sshd:session): session opened for user git by (uid=0)

2013-02-18T11:14:24.721605+00:00 ves-ebi-ef sshd[17704]: Received disconnect from 10.3.2.239: 11: disconnected by user

2013-02-18T11:14:24.722153+00:00 ves-ebi-ef sshd[17702]: pam_unix(sshd:session): session closed for user git

bash-4.1$ ssh git@ves-ebi-ef info

fatal: unrecognized command '/opt/git/gitolite/src/gitolite-shell git'

Yes, seems something related calling that script via ssh. Do you have any idea where else to look?

Thanks,

Pedro.

--
You received this message because you are subscribed to the Google Groups "gitolite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Sitaram Chamarty]

On Mon, Feb 18, 2013 at 4:47 PM, Pedro Albuquerque <pedr...@gmail.com> wrote:
> /var/log/secure
> 2013-02-18T11:14:24.681366+00:00 ves-ebi-ef sshd[17702]: Accepted publickey
> for git from 10.3.2.239 port 59016 ssh2
> 2013-02-18T11:14:24.685212+00:00 ves-ebi-ef sshd[17702]:
> pam_unix(sshd:session): session opened for user git by (uid=0)
> 2013-02-18T11:14:24.721605+00:00 ves-ebi-ef sshd[17704]: Received disconnect
> from 10.3.2.239: 11: disconnected by user
> 2013-02-18T11:14:24.722153+00:00 ves-ebi-ef sshd[17702]:
> pam_unix(sshd:session): session closed for user git
>
> bash-4.1$ ssh git@ves-ebi-ef info
> fatal: unrecognized command '/opt/git/gitolite/src/gitolite-shell git'

I am not sure if I replied to this earlier but for some reason your
sshd is treating the entire thing in quotes as the command. Including
the space.

I certainly have never seen that before and don't know how to fix it.

As an experiment, try removing the space and the username, and then do
the ssh. If you get "FATAL: GL_USER not set" or something like that
then we know this is the issue.

[Pedro Albuquerque]

Hi,

Sorry for this late reply. I found what was causing the issue.

I created the git user with gitolite-shell instead of /bin/bash as its shell. My mistake.

Thanks for your time in trying to help me.

Cheers,

Pedro.

[Ralf Hemmecke]

On 02/22/2013 02:55 PM, Pedro Albuquerque wrote:
> Sorry for this late reply. I found what was causing the issue.
> I created the git user with gitolite-shell instead of /bin/bash as its
> shell. My mistake.

Wow, interesting.

In fact, that brings me to a question to Sitaram. I wanted to remove
shell access for the "git" user on the server completely. Well, there is
no key outside the gitolite area in authorized_keys. Still, I've tried
to "chsh" the login shell for git from /bin/bash to /bin/false.

Don't beat me if I am wrong now, but I remember that gitolite didn't
work anymore then. Sitaram, do you think it's allowed to set /bin/false
as login shell for "git"?

Ralf

[Sitaram Chamarty]

On Fri, Feb 22, 2013 at 7:34 PM, Ralf Hemmecke <ra...@hemmecke.org> wrote:
> On 02/22/2013 02:55 PM, Pedro Albuquerque wrote:
>> Sorry for this late reply. I found what was causing the issue.
>> I created the git user with gitolite-shell instead of /bin/bash as its
>> shell. My mistake.

You used git-shell, not gitolite-shell, by the way.

My (privately emailed) question to you still stands: why did you do
it, and what part of my documentation said you have to do it? I need
to know...

> Wow, interesting.
>
> In fact, that brings me to a question to Sitaram. I wanted to remove
> shell access for the "git" user on the server completely. Well, there is
> no key outside the gitolite area in authorized_keys. Still, I've tried
> to "chsh" the login shell for git from /bin/bash to /bin/false.
>
> Don't beat me if I am wrong now, but I remember that gitolite didn't
> work anymore then. Sitaram, do you think it's allowed to set /bin/false
> as login shell for "git"?

No.

[Christoph Anton Mitterer]

On Friday, February 22, 2013 at 3:18:49 PM UTC+1, Sitaram Chamarty wrote:
> > Don't beat me if I am wrong now, but I remember that gitolite didn't
> > work anymore then. Sitaram, do you think it's allowed to set /bin/false
> > as login shell for "git"?
>
> No.

Hey.

May I ask why this doesn't work? I would have expected, that it doesn't matter at all, since the .ssh/authorized_keys contain some command= anyway... so I'd have set this just as safety fallback in case someone accidentally adds another key with out command restriction to .ssh/authorized_keys .

Also there's problem, that if non set to /bin/false... users may log in to the git user with bash, when they simply don't use pubkey auth (and when another SSH authentication mechanism is on, and e.g. a password is set in /etc/shadow)

Cheers,
Chris.

[Sitaram Chamarty]

On 02/19/2015 07:34 AM, Christoph Anton Mitterer wrote:
> On Friday, February 22, 2013 at 3:18:49 PM UTC+1, Sitaram Chamarty wrote:
>>> Don't beat me if I am wrong now, but I remember that gitolite didn't
>>> work anymore then. Sitaram, do you think it's allowed to set /bin/false
>>> as login shell for "git"?
>>
>> No.
>
> Hey.
>
> May I ask why this doesn't work? I would have expected, that it
> doesn't matter at all, since the .ssh/authorized_keys contain some
> command= anyway... so I'd have set this just as safety fallback in

it's nothing to do with gitolite; sshd tries to run whatever command it
is supposed to run with $SHELL -c <your command>.

[Christoph Anton Mitterer]

Hey folks.

On Thu, 2015-02-19 at 07:49 +0530, Sitaram Chamarty wrote:
> it's nothing to do with gitolite; sshd tries to run whatever command it
> is supposed to run with $SHELL -c <your command>.

Ah thanks :) ... of course... how could I just forget ^^


Nevertheless, I feel a bit bad about this, i.e. having a user which I
must allow for SSH and which might thus be an entry point into the
system should anything be accidentally misconfigured (e.g. when someone
changes has password authentication enabled, a password set for the git
user... or maybe when the path for authorized_keys is changed in ssh)


Some ideas that came up my mind:



1) I guess just a shell that accepts any command to be executed with
sh(1) compatbile "-c" would work and you don't need bash in specific,
right?
So making things a tiny bit better would be to advise people to
use /bin/sh as shell - on e.g. Debian system this is dash,.. far less
code, far tricky bash hacks... less likely to have security exploits.




2) Even better, can't you provide a dummy shell that handles "-c", e.g.
add -c to /usr/share/gitolite3/gitolite-shell .
When gitolite-shell is invoked with -c, then make sure that *only*
gitolite's commands (i.e. what you set in commands="..." in
authorized_keys) are executed and immediately exit if something else was
given by ssh.

That would be a simple fuse to prevent "normal" shell access to the
gitolite user (and thus all repos), just in case anyone does something
stupid with his ~git/.ssh/authorized_keys or whatever).




3) ~git/.ssh/authorized_keys
Maybe it makes sense to add "no-user-rc" in addition to all lines? Or
perhaps make it configurable, whether it should be added or not (just in
case someone really uses it for whatever).




4) Restrictions at the sshd_config level using Match blocks and options
allowed therein[0].
So maybe one could come up with a recommendation for such Match block
that users can/should use with the git/gitolite users, but which doesn't
break any things.

My first idea would have been something like:
------------------------------------------------------------------------------------------------------------
Match User git,otherGitolitUser,...
#for the user “git” used with Gitolite
Match User git
#Note: Gitolite via SSH must only be used with the public key authentication method, therefore the following completely disables all others. However, the former isn’t explicitily ena
bled here, but rather “inherited” from the “global” configuration.
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
RhostsRSAAuthentication no
HostbasedAuthentication no
HostbasedUsesNameFromPacketOnly no
KerberosAuthentication no
GSSAPIAuthentication no
RSAAuthentication no
###PubkeyAuthentication yes
AuthenticationMethods publickey

#Note: As of now, Gitolite doesn’t make use of an “authorized keys command”. It could have been “inherited” from the “global” configuration, therefore the following disables it explicitly.
AuthorizedKeysCommand none
AuthorizedKeysCommandUser invalid

#Note: Gitolite always expects the authorized keys to be found at “~/.ssh/authorized_keys”. A different value could have been “inherited” from the “global” configuration, therefore the following sets it explicitly.
AuthorizedKeysFile .ssh/authorized_keys

#Note: The following makes sure that it is really the user “git” which is used and that it isn’t an “alias for root” (in other words: any user name having the user ID 0).
AllowUsers git
PermitRootLogin no

#Note: The following restricts miscellaneous things which shouldn’t be necessary for respectively used with git or Gitolite.
PermitTTY no
AllowAgentForwarding no
PermitUserRC no
AcceptEnv LANG LC_ALL LC_ADDRESS LC_COLLATE LC_CTYPE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME
AllowStreamLocalForwarding no
StreamLocalBindMask 0777
StreamLocalBindUnlink no
AllowTcpForwarding no
PermitOpen none
PermitTunnel no
X11Forwarding no
X11UseLocalhost yes
GatewayPorts no

#Note: The following effectively forbids SSH channel multiplexing, which might have security implications (simplified: further channels “inherit” some parameters from the initiating one) if allowed.
MaxSessions 1
------------------------------------------------------------------------------------------------------------

Gitolite seems to still work with this correctly, at least at a first
glance.
So maybe you can include this in the documentation/recommendations on
how to set it up?

a) Any ideas whether git / gitolite makes use of LANG / LC_* env vars?
b) Do you think it's feasible to run gitolite inside a ChrootDirectory
(which ssh supports via that option)?

If you have questions thereon or further ideas for appropriate
hardening, that would be great :)




5) Using authorized keys command
That might be something interesting for gitolite to use/support in
future versions (but I don't know enough of its internals to tell
whether or not)

There's the authorized keys command:
AuthorizedKeysCommand /bin/foo
AuthorizedKeysCommandUser git
which can as of now be only used to get the authorized keys for a used.
But in future versions this:
https://bugzilla.mindrot.org/show_bug.cgi?id=2081
will be implemented, and so you might determine the right command="" via
the AuthorizedKeysCommand as well.
Maybe this helps to make access control easier.



Cheers,
Chris.


[0] As of OpenSSH 6.7 these options are allowed:
AcceptEnv, AllowAgentForwarding, AllowGroups, AllowTcpForwarding,
AllowUsers, AuthenticationMethods, AuthorizedKeysCommand,
AuthorizedKeysCommandUser, AuthorizedKeysFile, AuthorizedPrincipalsFile,
Banner, ChrootDirectory, DenyGroups, DenyUsers, ForceCommand,
GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication,
HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication,
KerberosAuthentication, MaxAuthTries, MaxSessions,
PasswordAuthentication, PermitEmptyPasswords, PermitOpen,
PermitRootLogin, PermitTTY, PermitTunnel, PermitUserRC,
PubkeyAuthentication, RekeyLimit, RhostsRSAAuthentication,
RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost
And as far as I understand, also these: IPQoS, RevokedKeys,
StreamLocalBindMask, StreamLocalBindUnlink and TrustedUserCAKeys (see
https://bugzilla.mindrot.org/show_bug.cgi?id=2353)

[milk]

On Thu, Feb 19, 2015 at 7:00 PM, Christoph Anton Mitterer
<cale...@gmail.com> wrote:
> [0] As of OpenSSH 6.7 these options are allowed:

A note here. Not everyone is fortunate to have the latest and greatest
OpenSSH. For example, Debian Squeeze is still on 5.5:
https://packages.debian.org/squeeze/openssh-server

[Christoph Anton Mitterer]

On Thu, 2015-02-19 at 21:08 -0800, milk wrote:
> A note here. Not everyone is fortunate to have the latest and greatest
> OpenSSH. For example, Debian Squeeze is still on 5.5:
> https://packages.debian.org/squeeze/openssh-server

Sure... but a) depending on how secure such people wanna be, they should
perhaps strongly consider to update (and via backports for all big
distros, this shouldn't be a big deal)... and b) telling people which
options they *could* use for hardening doesn't mean they *have* to use
all of them. :)

Cheers,
Chris.

[Sitaram Chamarty]

Beyond a point, there's not much gitolite can do to help with stuff
outside its environment, and I have very (very!) little interest in
making it be a policeman for all the stuff that can go wrong outside its
control. Stupidity by a "user" is within its purview, stupidity by
someone who has shell access to the hosting user... is most definitely
not.

The only thing I am willing to do is the attached patch. The "no
support; no docs" is serious. People who want to change the default
shell should know how to get in and do routine maintenance.

For the other stuff, please write it all up and give me a link and I'll
add a pointer to your page on the gitolite docs. I suggest hanging out
on #gitolite and #git, supporting ssh isues, for at least one year
before doing that :-)

regards
sitaram

[Christoph Anton Mitterer]

Hey Sitaram.

On Fri, 2015-02-20 at 14:45 +0530, Sitaram Chamarty wrote:
> Beyond a point, there's not much gitolite can do to help with stuff
> outside its environment

Sure...

> and I have very (very!) little interest in
> making it be a policeman for all the stuff that can go wrong outside its
> control. Stupidity by a "user" is within its purview, stupidity by
> someone who has shell access to the hosting user... is most definitely
> not.

Depends on what we're talking about, now:
a) the idea with the shell
(see below)
b) hints for user how to restrict their ssh with respect to git/gitolite
useage.
It's obviously not your (i.e. "gitolite"'s) job telling people how to
configure SSH, but practise is likely, that no user would do anything
if not suggested by upstream... and even if, many users probably
simply don't want to put the extra effort into finding out what makes
sense to configure.
That's why I think it's much more useful if this is provided as kind
of a "what you can do beyond configuring gitolite, if you want" wiki
page, especially since no user should need to re-invent the wheel ;)

> The only thing I am willing to do is the attached patch.

I've had a short look at it,... I'm a bit unsure whether I understand
it.

So basically, when you find "-c", this can be both, either the
command="/usr/share/gitolite3/gitolite-shell user" from the normal way,
or "anything plus arguments", when the user was able to directly execute
a command.
In that case "-c" would be ARGV[0], while everything else (including
spaces/further arguments) would be put into ARGV[1] by ssh.

Then you directly do anything further, i.e. everything is done from the
process executed by ssh as shell, e.g. to execute the command="..." via
-c.
So no further process is started for that, right?

Okay, when in gitolite=shell mode, you shift ARGV[0] (i.e. do away with
the -c).
With "$ARGV[0] =~ s/^$0 //;" you remove the program name from the former
ARGV[1] (i.e. what ssh wants to execute directly or forced via
command="..."), in order to make the "normal" mode (invocation via
command="...") work directly without further forking.

Isn't it necessary here to check whether "^$0 " really occurs and _die
if not? Just to sort out any users who had their keys added but no
command="..." being in place?
Otherwise such user might try to just fake himself being another user
like invoking:
ssh g...@example.org otherUserName...

> The "no
> support; no docs" is serious. People who want to change the default
> shell should know how to get in and do routine maintenance.

Mhh do you think that this patch would contain any hidden secrets? In
other words, what's the reason for not making this the default
behaviour?
If not for security reasons, than one at least saves crappy bash process
from being forked, parsing all kinds of profile/bashrc/etc. configs and
so on ;)

> For the other stuff, please write it all up and give me a link and I'll
> add a pointer to your page on the gitolite docs.

Mhh well right now I don't have an appropriate website where I'd want to
have people redirected to ;-)
Can't you just place that directly to the page, marking it as 3rd party
contributed or whatver? You can include my mail address (i.e.
no-reply@... ;-P)

btw: I changed my suggestions a bit to:

#for the user “git” used with Gitolite
Match User git
#Note: Gitolite via SSH must only be used with the public key authentication method, therefore the following completely disables all others. However, the former isn’t explicitily ena
bled here, but rather “inherited” from the “global” configuration.
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
RhostsRSAAuthentication no
HostbasedAuthentication no
HostbasedUsesNameFromPacketOnly no
KerberosAuthentication no
GSSAPIAuthentication no
RSAAuthentication no
###PubkeyAuthentication yes
AuthenticationMethods publickey

#Note: As of now, Gitolite doesn’t make use of an “authorized keys command”. It could have been “inherited” from the “global” configuration, therefore the following disables it explicitly.
AuthorizedKeysCommand none
AuthorizedKeysCommandUser

#Note: Gitolite always expects the authorized keys to be found at “~/.ssh/authorized_keys”. A different value could have been “inherited” from the “global” configuration, therefore the following sets it explicitly.
AuthorizedKeysFile .ssh/authorized_keys

#Note: The following makes sure that it is really the user “git” which is used and that it isn’t an “alias for root” (in other words: any user name having the user ID 0).
AllowUsers git
PermitRootLogin no

#Note: The following restricts miscellaneous things which shouldn’t be necessary for respectively used with git or Gitolite.
PermitTTY no
AllowAgentForwarding no
PermitUserRC no
AcceptEnv LANG LC_ALL LC_ADDRESS LC_COLLATE LC_CTYPE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME
AllowStreamLocalForwarding no
StreamLocalBindMask 0777
StreamLocalBindUnlink no
AllowTcpForwarding no
PermitOpen none
PermitTunnel no
X11Forwarding no
X11UseLocalhost yes
GatewayPorts no

#Note: The following effectively forbids SSH channel multiplexing, which might have security implications (simplified: further channels “inherit” some parameters from the initiating one) if allowed.
MaxSessions 1

=> i.e. the AuthorizedKeysCommandUser is now explicitly set to empty,
which makes ssh completely ignore it (even though this is undocumented).

Also, as of now there seems to be a bug in either SSH
(https://bugzilla.mindrot.org/show_bug.cgi?id=2355) or the Debian
packaging of it
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778807) when
PermitOpen is set to none.... so that might be added as a information.


Cheers,
Chris.

[Christoph Anton Mitterer]

Hey.

1) Perhaps you may want to use:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778928
As such link :)


2) I did some testing of the shell-mode:
=> at least in the very last case it seems to allow a command even
though it is no intended user of gitolite (i.e. with command="..."

# ed25519 key is a gitolite key (with command="..."),... rsa is a "normal" key

#
# shell is /bin/bash:
#

user@host:~$ ssh -i .ssh/id_ed25519 git@server whoami user@host
FATAL: unknown git/gitolite command: 'whoami user@host'
before: user@host
after: user@host
user@host:~$

user@host:~$ ssh -i .ssh/id_rsa git@server whoami user@host
whoami: extra operand ‘user@host’
Try 'whoami --help' for more information.
user@host:~$

user@host:~$ ssh -i .ssh/id_rsa git@server whoami
git
user@host:~$



#
# shell is gitolite:
#

user@host:~$ ssh -i .ssh/id_ed25519 git@server whoami user@host
FATAL: unknown git/gitolite command: 'whoami user@host'
before: -c,/usr/share/gitolite3/gitolite-shell user@host
shell -c found
after: user@host
user@host:~$

user@host:~$ ssh -i .ssh/id_ed25519 git@server whoami
FATAL: unknown git/gitolite command: 'whoami'
before: -c,/usr/share/gitolite3/gitolite-shell user@host
shell -c found
after: user@host
user@host:~$

user@host:~$ ssh -i .ssh/id_ed25519 git@server info
before: -c,/usr/share/gitolite3/gitolite-shell user@host
shell -c found
after: user@host
hello user@host, this is git@server running gitolite3 3.6.1-3 (Debian) on git 2.1.4
user@host:~$

user@host:~$ ssh -i .ssh/id_rsa git@server info user@host
before: -c,info user@host
shell -c found
after: info user@host
hello info user@host, this is git@server running gitolite3 3.6.1-3 (Debian) on git 2.1.4
FATAL: invalid user 'info user@host'
user@host:~$

user@host:~$ ssh -i .ssh/id_rsa git@server info
before: -c,info
shell -c found
after: info
hello info, this is git@server running gitolite3 3.6.1-3 (Debian) on git 2.1.4
user@host:~$



Cheers,
Chris.

[Sitaram Chamarty]

On 02/22/2015 03:17 AM, Christoph Anton Mitterer wrote:
> Hey.
>
> 1) Perhaps you may want to use:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778928
> As such link :)

Sorry no. Adding a "bug report" as advice is just confusing. I'll
accept a markdown formatted file though (it'll go into the "contrib/"
directory of the gitolite-doc repository), then it will be linked from
the "ssh.html" page with a suitable 1-line description. Please see
https://github.com/sitaramc/gitolite-doc/tree/master/contrib for some
samples of how that document should look, including copyright statement
and license. (The gitolite documentation is CC-BY-NC-SA; you are free
to choose any other license for your piece).

> 2) I did some testing of the shell-mode:

All the stuff below looks fine to me; I don't know what you're saying
here.

[Sitaram Chamarty]

On 02/22/2015 05:19 AM, Sitaram Chamarty wrote:
> On 02/22/2015 03:17 AM, Christoph Anton Mitterer wrote:

>> 2) I did some testing of the shell-mode:
>
> All the stuff below looks fine to me; I don't know what you're saying
> here.

>> user@host:~$ ssh -i .ssh/id_ed25519 git@server info
>> before: -c,/usr/share/gitolite3/gitolite-shell user@host
>> shell -c found
>> after: user@host
>> hello user@host, this is git@server running gitolite3 3.6.1-3 (Debian) on git 2.1.4

I forgot that the default command (info) will run, so this can be an
information leak. That is, a user whose pubkey has been added to
~/.ssh/authorized_keys without a "command=" restriction, can see repo
names and R/W permissions for any arbitrary user.

I suppose a "die" could be added to prevent that, as you mentioned in
your other email.

But I'll wait a bit before I add that "die" in. Meanwhile, please try
to fool gitolite-shell into running some other command (any other
command, gitolite or shell, except "info").

[Christoph Anton Mitterer]

On Sun, 2015-02-22 at 05:19 +0530, Sitaram Chamarty wrote:
> Sorry no. Adding a "bug report" as advice is just confusing.

Okay... point taken :D

> I'll
> accept a markdown formatted file though (it'll go into the "contrib/"
> directory of the gitolite-doc repository), then it will be linked from
> the "ssh.html" page with a suitable 1-line description.

Apart from the fact that you force me to learn markdown, ;-) ... sounds
good to me... see the attached file.

> Please see
> https://github.com/sitaramc/gitolite-doc/tree/master/contrib for some
> samples of how that document should look, including copyright statement
> and license. (The gitolite documentation is CC-BY-NC-SA; you are free
> to choose any other license for your piece).

I triple license it, so everyone should be happy.

> All the stuff below looks fine to me; I don't know what you're saying
> here.

skipping my answer to your follow-up up mail

Cheers,
Chris.

[Christoph Anton Mitterer]

On Sun, 2015-02-22 at 06:27 +0530, Sitaram Chamarty wrote:
> I forgot that the default command (info) will run, so this can be an
> information leak.

Jap,.. that's what I've noticed as well,... but that wasn't the reason
for me asking for that additional check and _die if no match was found.

I guess the charming reason of such check would be, that one can then be
basically sure, that however you change your other gitolite code, as
long as this matches, things are the same as if it would have gotten
called via command="...".

AFAIU, right now the shell mode basically fails at some point because no
user is set.
Just imagine you change that code in 20 years from now to default to
something if unset, this would then break the idea of the shell mode.

> That is, a user whose pubkey has been added to
> ~/.ssh/authorized_keys without a "command=" restriction, can see repo
> names and R/W permissions for any arbitrary user.

Well... not the end of the world, but something we should try to avoid
if it doesn't cost much anything.
And since all this anyway just kicks in when "-c" was found, an
additional check won't hurt the "normal" users.

> I suppose a "die" could be added to prevent that, as you mentioned in
> your other email.

That would be great :)

> But I'll wait a bit before I add that "die" in. Meanwhile, please try
> to fool gitolite-shell into running some other command (any other
> command, gitolite or shell, except "info").

Well that's what I've basically tried to do with the "test series" I've
sent before,... but I think it's not really possible.
Anyway, the main idea of the _die is rather to be a safety fuse for
future changes,... less the privacy leak (even though this is of course
nice as well).


Oh and perhaps you oversaw that:
I wonder, which are your reasons for not making this the default (in the
sense of telling people "hey there is this new fancy shell like mode,...
use this")?
Do you think it might cause any troubles (and thus more work for you)?


Best wishes,
Chris.

[Sitaram Chamarty]

On 02/22/2015 10:57 AM, Christoph Anton Mitterer wrote:
> On Sun, 2015-02-22 at 06:27 +0530, Sitaram Chamarty wrote:
>> I forgot that the default command (info) will run, so this can be an
>> information leak.
> Jap,.. that's what I've noticed as well,... but that wasn't the reason
> for me asking for that additional check and _die if no match was found.
>
> I guess the charming reason of such check would be, that one can then be
> basically sure, that however you change your other gitolite code, as
> long as this matches, things are the same as if it would have gotten
> called via command="...".

I don't understand the word "charming" in this context but for me, the
importance is reversed. Info leak today is far more important than some
future change screwing up something.

I don't know what you mean by "making this the default". **Require**
"gitolite-shell" to be the $SHELL for the hosting user? Never!
**Allow** [... that ...]? Sure; modulo adding a "die", that's the point
of this code.

As for documenting it so people know about it, sorry no. As I said,
spend a year supporting people with ssh issues on #git/#gitolite then
talk.

More importantly, I know (of) people who run gitolite on a VPS where
they have only one "user". I will not document anything that **might**
result in such people losing their "emergency password access".

[Sitaram Chamarty]

On 02/22/2015 10:50 AM, Christoph Anton Mitterer wrote:
> On Sun, 2015-02-22 at 05:19 +0530, Sitaram Chamarty wrote:
>> Sorry no. Adding a "bug report" as advice is just confusing.
> Okay... point taken :D
>
>
>> I'll
>> accept a markdown formatted file though (it'll go into the "contrib/"
>> directory of the gitolite-doc repository), then it will be linked from
>> the "ssh.html" page with a suitable 1-line description.
> Apart from the fact that you force me to learn markdown, ;-) ... sounds
> good to me... see the attached file.

I'd have been happy to convert it from plain text if I'd know it was
that hard :)

By the way, your text has a lot of UTF-8 quotes; I'll be changing them
to plain ASCII. There's no real reason to use UTF-8 for those things;
only things like the copyright symbol etc., need it.

Will push sometime over the next few days or so, depending on time.

[Christoph Anton Mitterer]

On Sun, 2015-02-22 at 11:36 +0530, Sitaram Chamarty wrote:
> I don't understand the word "charming" in this context but for me, the
> importance is reversed. Info leak today is far more important than some
> future change screwing up something.

I just meant that it's a nice aspect of it =)
But as I've said, the privacy aspect is also important.

> > Oh and perhaps you oversaw that:
> > I wonder, which are your reasons for not making this the default (in the
> > sense of telling people "hey there is this new fancy shell like mode,...
> > use this")?
> > Do you think it might cause any troubles (and thus more work for you)?
>
> I don't know what you mean by "making this the default". **Require**
> "gitolite-shell" to be the $SHELL for the hosting user? Never!
> **Allow** [... that ...]? Sure; modulo adding a "die", that's the point
> of this code.

No I didn't meant require, I meant basically "advertising" this as the
default mode, i.e. educating people... try this, it's more secure, but
if you don't like it, continue as before.

The problem with the current way is: it's not documented (apart from the
sources) and the warning that this is expert only, not supported, will
likely scare off most users.

> As for documenting it so people know about it, sorry no. As I said,
> spend a year supporting people with ssh issues on #git/#gitolite then
> talk.

Okay fine... I just wanted to ask why =)

Cheers,
Chris.

[Christoph Anton Mitterer]

On Sun, 2015-02-22 at 11:38 +0530, Sitaram Chamarty wrote:
> I'd have been happy to convert it from plain text if I'd know it was
> that hard :)

Hehe... you mean I should have whined much more in the first place and
then you'd have done the work for me?! ;-D
You should never tell that you contributors :P

> By the way, your text has a lot of UTF-8 quotes; I'll be changing them
> to plain ASCII. There's no real reason to use UTF-8 for those things;
> only things like the copyright symbol etc., need it.

Arrr... you know that literally everyone should have full unicode
support in all places these days? ;-)
Those who haven't deserved it to see garbage :P

> Will push sometime over the next few days or so, depending on time.

Great! Thanks in advance.


One more word on the documentation... I've filed a request in Debian to
get it packaged as well, but due to the NC license it will at least not
went to main... is there any reason for the restriction?


Cheers,
Chris.

[Sitaram Chamarty]

On 02/22/2015 11:21 PM, Christoph Anton Mitterer wrote:
> On Sun, 2015-02-22 at 11:38 +0530, Sitaram Chamarty wrote:
>> I'd have been happy to convert it from plain text if I'd know it was
>> that hard :)
> Hehe... you mean I should have whined much more in the first place and
> then you'd have done the work for me?! ;-D
> You should never tell that you contributors :P

I meant formatting not the material.

But speaking of the material, I am re-thinking the idea of adding this
to gitolite, sorry. It needs to go somewhere else with a more "general"
scope than gitolite. It's relevance to gitolite is marginal at best,
and seems to hinge entirely upon "what if someone royally screws up
something outside gitolite?" That's a direction I am absolutely not
interested in taking, as I may have mentioned before.

It is also too broad, too detailed, and over-engineered. Why do you
need "PermitOpen" when you already have "AllowTCPForwarding no"? Why do
you need "X11UseLocalhost yes" when you already have "X11Forwarding no"?

Most importantly, it seems to be geared toward someone who does not even
know whether to separate usernames with spaces or commas (which means an
ssh novice), and yet the settings are advanced settings that I do not
**want** to be responsible for advising on. It is not gitolite's job to
make them into competent admins, and I am not interested in going down
that path either.

If all this sounds too harsh, please re-read section 1 of ssh.html.

I realise you said you don't have any web-space anywhere but that's
easy. People are putting up documentation on their github pages. Just
create a github page and put it there, and I will link to it from
ssh.html with something like this:

Christoph Anton Mitterer contributed a [guide to hardening
OpenSSH][link goes here] for people who have the latest and greatest
openssh installed. Please note that I do not endorse blind use of
those settings if you're an ssh novice. For instance, they would
prevent anyone from using password access as a fall-back mechanism
in an emergency. So become comfortable with ssh, *then* apply those
settings, would be my advice.

[Christoph Anton Mitterer]

On Mon, 2015-02-23 at 07:48 +0530, Sitaram Chamarty wrote:
> It needs to go somewhere else with a more "general"
> scope than gitolite.

Well I wouldn't know a place where this really fits.
In general people who want to learn about ssh should start with it's
manpages, but this is obviously general stuff and not specific how to
harden with respect to some use case (here git/giolite,.. which e.g.
don't need all the port forwarding, etc.).

> It's relevance to gitolite is marginal at best,
> and seems to hinge entirely upon "what if someone royally screws up
> something outside gitolite?" That's a direction I am absolutely not
> interested in taking, as I may have mentioned before.

Well I personally would think different,.. gitolite/git depends heavily
on OpenSSH and since that in turn could also simply have security
issues, one should want to lock down as much as possible.

Practise however has shown that people want to do/learn little about
security, therefore a recipe on how to do things (without much
searching) seemed the best solution to me.


But obviously it's your decision on what you want to put in!

> Why do you
> need "PermitOpen" when you already have "AllowTCPForwarding no"? Why do
> you need "X11UseLocalhost yes" when you already have "X11Forwarding no"?

Well then you can also question: "Why do hardening at all?" Cause if
everything goes right, it couldn't be done anyway.
So why forbidding things twice and more? Well upstream could change
defaults of some options, they could have bugs, etc.

> Most importantly, it seems to be geared toward someone who does not even
> know whether to separate usernames with spaces or commas (which means an
> ssh novice), and yet the settings are advanced settings that I do not
> **want** to be responsible for advising on.

Phew... I wouldn't think you're anyhow responsible for anything you
do,... it's opensource, no one paid you, and if your code would
accidentally contain an rm -rf / ... well than still no one would come
for you ;)
Especially when you provide 3rd party content...


Anyway,.. no big deal.. =)

I filed now some final version at Debian
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778928)
so that at least we can include it over there.

> Christoph Anton Mitterer contributed a [guide to hardening
> OpenSSH][link goes here] for people who have the latest and greatest
> openssh installed. Please note that I do not endorse blind use of
> those settings if you're an ssh novice. For instance, they would
> prevent anyone from using password access as a fall-back mechanism
> in an emergency. So become comfortable with ssh, *then* apply those
> settings, would be my advice.

Perhaps we can link to the Debian place once they'd have added it?


Cheers,
Chris.

[Sitaram Chamarty]

On 02/23/2015 08:49 AM, Christoph Anton Mitterer wrote:
> On Mon, 2015-02-23 at 07:48 +0530, Sitaram Chamarty wrote:

>> Why do you
>> need "PermitOpen" when you already have "AllowTCPForwarding no"? Why do
>> you need "X11UseLocalhost yes" when you already have "X11Forwarding no"?
> Well then you can also question: "Why do hardening at all?" Cause if
> everything goes right, it couldn't be done anyway.
> So why forbidding things twice and more? Well upstream could change
> defaults of some options, they could have bugs, etc.

I think that summarises our differing points of view quite well. I
could do a https://en.wikipedia.org/wiki/Reductio_ad_absurdum on your
argument in several directions, but there's no point.

regards
sitaram

[Sitaram Chamarty]

For the sake of other people reading this who may not know why I said
that, I need to explain.

"PermitOpen none" is a weaker form of "AllowTCPForwarding no". The
former blocks only local forwards (ssh -L ...) while the latter blocks
both local and remote (ssh -R ...) forwards.

As such, once you specify the latter, the former is redundant.

The difference in our points of view here is that you seem to think it
is *your* responsibility to cover for fundamental assumptions being
violated. Mine is that if you go down that path there is no end to it.

For example, you say "upstream could change defaults". Can I assume you
mean "...in a way that reduces security" (otherwise it does not make
sense)?

Well then, have you covered for the possibility that the ssh stack is
compromised in some way? That is certainly far more likely than that
openssh upstream will change defaults to be less secure.

[Sitaram Chamarty]

On 02/23/2015 09:41 AM, Sitaram Chamarty wrote:

[Christoph Anton Mitterer]

He Sitaram.

On Mon, 2015-02-23 at 10:46 +0530, Sitaram Chamarty wrote:
> For the sake of other people reading this who may not know why I said
> that, I need to explain.

I thin you overdo it a bit here :)

Look, I guess there's no need to analyse/justify that.
All I did was coming up with some few ideas on how one could restrict
things even a bit more (and would have already assumed that people did
something or that there are some unknown bugs in gitolite, where any of
these measures would help against (which is no guaranteed)).


I thought giving a example for how options can be restricted as much as
possible wouldn't cause much harm, neither to you nor any user.

- Such information is usually provided "as is" and I even clearly wrote
that people should read the sshd_config(5) and be sure to understand
what they do. So I guess nothing of this would have fallen back to you
(or anyone else).

- It's also highly unlikely that any user could have screwed his setup
by any selection from these option. Nothing of what they restrict is
used by git/giolite ... plus everything is limited to the "git" user.
And even *if* people would break their setups with this,... as easy as
one can copy&paste that to sshd_config, as easy it can be removed.


Now with respect to double restricting the same things e.g. PermitOpen
vs. AllowTCPForwarding.
I've never said that nothing would be "doubled", but I fail to see the
harm either.
In the worst case, the parsing of the config file takes some
milliseconds more.

The idea behind providing all possible options was simply to have a
collected list of restriction options which are known to still keep
git/gitolite working without any hidden surprises.

If someone knows OpenSSH well enough to understand that
AllowTCPForwarding no already does the job, he's free to remove the
PermitOpen.
If someone's a novice, he won't get hurt either.
And if someone has a really special setup in where he actually
uses/needs TCP forwarding with the git user, he may now stumble over the
PermitOpen option to see that he can perhaps just partially restrict TCP
forwardings.

That's the whole idea in providing restriction options even when they do
the same.


Apart from all that, I thought that the gitolite documentation was an
appropriate place for this, since this is where people would look if
they set it up (i.e. they wouldn't look for other general SSH hardening
sites).

If you feel it doesn't fit there or should be modified - fine either. :)
As I've said it was just a proposal... no need to make a state affair
out of it.
I'm happy with either decision.


And actually my main point here in the thread was rather to get the
shell mode working, which you did.
Great! :-)

Having another safety check there and some _die sounds like a good idea
to me, at least for the privacy reasons you've mentioned yourself.
But apart from that,... things are fine =)


Best wishes,
Chris.

[Sitaram Chamarty]

On 02/24/2015 03:34 AM, Christoph Anton Mitterer wrote:
> He Sitaram.
>
> On Mon, 2015-02-23 at 10:46 +0530, Sitaram Chamarty wrote:
>> For the sake of other people reading this who may not know why I said
>> that, I need to explain.
> I thin you overdo it a bit here :)

Hmm; not sure I agree, but sorry anyway :)

> - Such information is usually provided "as is" and I even clearly wrote

doesn't stop people from commenting, complaining, and asking for changes
to suit their situation.

Which is why I said spend a year supporting ssh issues then talk.

My original offer still stands. Write up whatever you want to, put it
up on github under your name, and I will link to it with some text to go
with it.

> - It's also highly unlikely that any user could have screwed his setup

I thought I already explained this, but maybe I didn't. I don't have
the energy to do that now but disabling password access is not something
I advise, if you only have one userid on the box. I'm sure there are
other such traps.

And that scenario is pretty common on corporate setups, where "root" is
someone from a completely different reporting chain.