Bug#778928: gitolite3: please include ssh hardening hints in README.Debian
Hey. Okay upstream has changed his opinion again an no longer wants to provide hardening hints to gitolite users in general. So attached is a text based version based on the latest version I've presented upstream using the default Debian gitolite3 username. Please include to within /u/s/doc/gitolite3 Cheers, Chris. *** “Hardening” OpenSSH for the use with git/Gitolite*** This is some documentation about how to “harden” the configuration of OpenSSH’s server sshd(8) for the use with git/Gitolite. • Be sure to read sshd_config(5) in order to understand all the used directives, their effects as well as whether and how they might affect your system. • The configuration snippet must be placed below the “global section” (or simply at the very end) of sshd_config(5). • Adapt the example user “gitolite3” to the user(s) for git/Gitolite. For the “Match” directive, multiple users are separated with “,” (U+002C COMMA), for example: Match User gitolite3,git For the “AllowUsers” directive, multiple users are separated with “ ” (U+0020 SPACE), for example: AllowUsers gitolite3 git • The “Match-block” can be further restricted (for example to the incoming IP address or TCP port if desired). See sshd_config(5) for details. • Currently, there may be a bug in OpenSSH (or at least the Debian packaging of it) which leads issues when the directive “PermitOpen” is set to “none”. See OpenSSH bug #2355 (https://bugzilla.mindrot.org/show_bug.cgi?id=2355) respectively Debian bug #778807 (http://bugs.debian.org/778807). *** sshd_config Snippet *** Match User gitolite3 #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 explicitly enabled here, but rather “inherited” from the “global” configuration. PasswordAuthentication no PermitEmptyPasswordsno KbdInteractiveAuthenticationno RhostsRSAAuthentication no HostbasedAuthentication no HostbasedUsesNameFromPacketOnly no KerberosAuthentication no GSSAPIAuthenticationno 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 gitolite3 PermitRootLogin no #Note: The following restricts miscellaneous things which shouldn’t be necessary for respectively used with git or Gitolite. PermitTTY no AllowAgentForwardingno PermitUserRCno 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 #TODO: Uncomment the following once OpenSSH bug #2355 (https://bugzilla.mindrot.org/show_bug.cgi?id=2355) has been solved. #PermitOpen none PermitTunnelno X11Forwarding no X11UseLocalhost yes GatewayPortsno #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 *** License
Bug#778928: gitolite3: please include ssh hardening hints in README.Debian
Hey. It seems upstream will include[0] my hardening hints in the form of markdown file[1] (which has also some spelling corrections compared to the one uploaded here) in the contrib section in the next version. So perhaps wait a bit with that,... and eventually just include a pointer to the contrib section in README.Debian (which will likely be read by more people than every file there). Thanks, Chris. [0] https://groups.google.com/d/msg/gitolite/eLTiK8hvijo/AC_Erj5GoHwJ [1] https://groups.google.com/d/msg/gitolite/eLTiK8hvijo/-CqBajaLg7wJ smime.p7s Description: S/MIME cryptographic signature
Bug#778928: gitolite3: please include ssh hardening hints in README.Debian
Package: gitolite3 Version: 3.6.1-3 Severity: wishlist Tags: patch Hi. I spent some time in thinking how one can ideally harden the git user fromt he SSH side (i.e. rather independently of gitolite3). I've posted my ideas upstream https://groups.google.com/d/msg/gitolite/eLTiK8hvijo/9dKI8YfTSecJ (with some updated version a bit more down in the thread). I guess it would be nice if these hints could be added to e.g. README.Debian or as stand alone example file for the benefit of other users. Cheers, Chris. Instructions: • Be sure to read the sshd_config(5) documentation to understand all directive set below and their effects. • This snippet must be placed at the very end (or at least below the “global section”) of sshd_config(5). • Adapt the user “gitolite3” with the user(s) used for git/Gitolite. For the “Match” directive, multiple users are separated with “,”, for example: Match User gitolite3,git For the “AllowUsers” directive, multiple users are separated with “ ”, for example: AllowUsers gitolite3 git Match User gitolite3 #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 enabled here, but rather “inherited” from the “global” configuration. PasswordAuthentication no PermitEmptyPasswordsno KbdInteractiveAuthenticationno RhostsRSAAuthentication no HostbasedAuthentication no HostbasedUsesNameFromPacketOnly no KerberosAuthentication no GSSAPIAuthenticationno 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 “gitolite3” which is used and that it isn’t an “alias for root” (in other words: any user name having the user ID 0). AllowUsers gitolite3 PermitRootLogin no #Note: The following restricts miscellaneous things which shouldn’t be necessary for respectively used with git or Gitolite. PermitTTY no AllowAgentForwardingno PermitUserRCno 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 #TODO: Uncomment the following once Debian bug #777643 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777643) has been solved. #PermitOpen none PermitTunnelno X11Forwarding no X11UseLocalhost yes GatewayPortsno #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
Bug#778928: gitolite3: please include ssh hardening hints in README.Debian
Perhaps placing an emphasis on this: As of now, there is at least on my server a bug when PermitOpen is set to none: https://bugzilla.mindrot.org/show_bug.cgi?id=2355 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778807 Which is why the attached config snippet has this disabled for the moment. Further, some of these directives might only work with newer versions of OpenSSH, but since that file will likely only end up in =stretch that shouldn't be a big concern for us. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
