> If GitLab security were to be perfect, then this change would not affect security in any which way.
Yes, it does: right now users can use ssh to push and pull repos on my machine using gitolite but they do not have shell access to the computer. "ssh git@gitlab.example.com" just prints a short message and exits. With this change they can all just ssh into the computer and have a bash prompt. Trying to make that secure requires a whole different level of paranoia than just not letting people in in the first place.
It also means that every gitlab user has access to every repo that's hosted and the permissions in the web interface are just for show.
If this is really the case and the attitude of the devs then I don't think I will be updating any time soon...
However, I still feel I must be missing something because the gitlab guys host private repos at gitlab.com and so they must have worked these security things out, right? I can't create an account at gitlab.com and just ssh into their server. At least, I really hope I can't.
AUTHORIZED_KEYS FILE FORMAT
....
command="command"
Specifies that the command is executed whenever this key is used for
authentication. The command supplied by the user (if any) is
ignored. The command is run on a pty if the client requests a pty;
otherwise it is run without a tty. If an 8-bit clean channel is
required, one must not request a pty or should specify no-pty. A
quote may be included in the command by quoting it with a backslash.
This option might be useful to restrict certain public keys to per‐
form just a specific operation. An example might be a key that per‐
mits remote backups but nothing else. Note that the client may
specify TCP and/or X11 forwarding unless they are explicitly prohib‐
ited. The command originally supplied by the client is available in
the SSH_ORIGINAL_COMMAND environment variable. Note that this
option applies to shell, command or subsystem execution. Also note
that this command may be superseded by either a sshd_config(5)
ForceCommand directive or a command embedded in a certificate.
Got it, so the shell is still /bin/bash but they specify the command in the .ssh/authorize_keys file which means it cannot be overridden by the user. (I was under the mistaken impression that gitolite overrode the shell and not the command)
So your original point was correct: as long as the authorized_keys file is not corrupted, everything is good. Thanks for helping me understand!
Yes, it does: right now users can use ssh to push and pull repos on my machine using gitolite but they do not have shell access to the computer. "ssh git@gitlab.example.com" just prints a short message and exits. With this change they can all just ssh into the computer and have a bash prompt. Trying to make that secure requires a whole different level of paranoia than just not letting people in in the first place.
It also means that every gitlab user has access to every repo that's hosted and the permissions in the web interface are just for show.
If this is really the case and the attitude of the devs then I don't think I will be updating any time soon...
However, I still feel I must be missing something because the gitlab guys host private repos at gitlab.com and so they must have worked these security things out, right? I can't create an account at gitlab.com and just ssh into their server. At least, I really hope I can't.