Skip to content
Snippets Groups Projects
New issue look: Off

Anonymouse SSH cloning not working

    • Closed (moved) Issue created by username-removed-1179558 @agowa338

    Summary

    Cloning a repository over ssh does not work, if the user is not authenticated using his key. This is a problem for public projects, as cloning over ssh is not possible.

    Steps to reproduce

    git clone ssh://git@gitlab.example.com:3333/root/foo.git

    What is the current bug behavior?

    Doesn't clone.

    Message: "please check, that you have the correct access rights"

    What is the expected correct behavior?

    The repository gets cloned (because it is public) mode

    Possible fixes

    1. Change handling in the backend, maybe with an login script or by assigning a custom (restricted) shell.
    2. Append to /etc/ssh/sshd_config
    Match User git
          PermitEmptyPasswords yes

    Designs

    Child items ...

    • Activity

    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      @agowa338 Please ensure that the public project's feature visibility level for "Repository" is set to "Everyone can access"

    • username-removed-419655 added ~65372 ~532786 labels

      added ~65372 ~532786 labels

    • username-removed-1179558
      username-removed-1179558 @agowa338 ·
      Author

      The repository is set to public, but I'm still not able to clone it without authentication over ssh. Cloning over https is working fine though. Here is a valid link: https://www.agowa338.de/gitlab/agowa338/InvokeResourceInMemory

      Edited by username-removed-1179558
    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      @agowa338 You didn't mention which version of GitLab you are using. Whether these options are available will depend upon the version you are running. I'm assuming that you are running the latest version here.

      Please could you add a screenshot of your Project's feature visibility settings and I can advise further. Here is an example from an example public project of mine:

      Screen_Shot_2017-03-22_at_09.47.37

      In this example, the repository will be publicly accessible, but the wiki and issue tracker will only be available to users that have been explicitly added as a member of the project.

    • username-removed-1179558
      username-removed-1179558 @agowa338 ·
      Author

      My Project settings quite similar to yours, and yes, I'm using the latest version.

      image

      Edited by username-removed-1179558
    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      @agowa338 Your settings look correct to me. Please could you add any further information about your setup. Are you using a source installation or via omnibus? Are there any customizations with regards to the web server? Thanks!

      Edited by username-removed-419655
    • username-removed-1179558
      username-removed-1179558 @agowa338 ·
      Author

      I used this commands ( https://about.gitlab.com/downloads/#debian8 )

      sudo apt-get install curl openssh-server ca-certificates postfix
curl -LJO https://packages.gitlab.com/gitlab/gitlab-ce/packages/debian/jessie/gitlab-ce-XXX.deb/download
dpkg -i gitlab-ce-XXX.deb
sudo gitlab-ctl reconfigure

      Then there is a restrictive iptables (IPv4 and IPv6) setup, but that's not the problem, it doesn't even work from localhost (no iptables restrictions) without authentication.

      I'm using a reverse proxy setup ( http://www.agowa338.de/gitlab ), using apache

      <VirtualHost www.agowa338.de:443>
	ServerAdmin webmaster@agowa338.de
	ServerName www.agowa338.de
	ServerAlias agowa338.de

	RewriteEngine on
	RewriteCond %{HTTP_HOST} !^www\.
	RewriteRule ^(.*)$ https://www.%{HTTP_HOST}$1 [R=301,L]

	RewriteEngine on
	RewriteRule "^/$" "/gitlab" [R=302]

	SSLEngine on
	SSLUseStapling on
	SSLProtocol ALL -SSLv2 -SSLv3
	SSLHonorCipherOrder on
	# SSLCipherSuite ALL:!ADH:!RC4:+HIGH:!MEDIUM:!LOW:!SSLv2:!SSLv3!EXPORT
	SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256"

	Header always set Strict-Transport-Security "max-age=15768000;includeSubdomains;preload"
	Header always set Public-Key-Pins "pin-sha256=\"Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=\"; pin-sha256=\$
	Header always set Content-Security-Policy "default-src 'self';frame-ancestors 'self';style-src 'self' 'unsaf$
	Header always set X-Content-Type-Options "nosniff"
	Header always set X-Frame-Options "sameorigin"
	Header always set Referrer-Policy "strict-origin-when-cross-origin"
	Header always set X-XSS-Protection "1; mode=block"

	<Directory />
		# Overwrite preset headers, so that only the global ones from above apply
		Header unset "X-Content-Type-Options"
		Header unset "X-Frame-Options"
		Header unset "X-XSS-Protection"
		Header unset "Public-Key-Pins"
		Header unset "Content-Security-Policy"
		Header unset "Strict-Transport-Security"
		Header unset "Referrer-Policy"
	</Directory>
	<Location /gitlab>
		ProxyPreserveHost On

		Require all granted
		#Allow forwarding to gitlab-workhorse
		ProxyPassReverse http://127.0.0.1:8181
		ProxyPassReverse https://www.agowa338.de/gitlab

		RequestHeader set X_FORWARDED_PROTO 'https'
		RequestHeader set X-Forwarded-Ssl on

		#Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy pag$
		ErrorDocument 404 /gitlab/404.html
		ErrorDocument 422 /gitlab/422.html
		ErrorDocument 500 /gitlab/500.html
		ErrorDocument 502 /gitlab/502.html
		ErrorDocument 503 /gitlab/503.html

		RewriteEngine on
		# Forward all requests to gitlab-workhorse except existing files like error documents
		RewriteCond %{DOCUMENT_ROOT}/gitlab/%{REQUEST_FILENAME} !-f [OR]
		RewriteCond %{REQUEST_URI} ^/uploads/.*
		RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

		Header unset "X-XSS-Protection"
		Header unset "X-Content-Type-Options"
		Header unset "Strict-Transport-Security"
		Header unset "X-Frame-Options"
		Header unset "Public-Key-Pins"
		Header unset "Content-Security-Policy"
		Header unset Referrer-Policy
	</Location>
	<IfModule mod_expires.c>
		ExpiresActive On
		ExpiresDefault "access plus 10 seconds"
		ExpiresByType text/html "access plus 60 seconds"
		ExpiresByType image/gif "access plus 120 minutes"
		ExpiresByType image/jpeg "access plus 120 minutes"
		ExpiresByType image/png "access plus 120 minutes"
		ExpiresByType image/svg+xml "access plus 120 minutes"
		ExpiresByType text/css "access plus 60 minutes"
		ExpiresByType text/javascript "access plus 60 minutes"
		ExpiresByType application/javascript "access plus 60 minutes"
		ExpiresByType application/x-javascript "access plus 60 minutes"
		ExpiresByType text/xml "access plus 60 minutes"
	</IfModule>
</VirtualHost>

      Despite the use of multiple "RewriteEngine on" statements, I can't see anything striking out.

      I'm heavily using SNI for my web server configuration, as there are more than one website on it with different certificates. Accessing it without SNI will most likely fail. Port 80 returns an HTTP-301 Redirect to https

      # This section is only needed if you want to redirect http traffic to https.
# You can live without it but clients will have to type in https:// to reach gitlab.
<VirtualHost *:80>
        ServerSignature Off
        RewriteEngine on
        RewriteCond %{HTTPS} !=on
        RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [NE,R=301,L]
</VirtualHost>

      Also gitlab correctly sets the "/var/opt/gitlab/.ssh/authorized_keys" file to include:

      command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa <Insert Public Key here>

      But I wasn't able to find anything similar for pure ssh without authentication.

      My /etc/ssh/sshd_config looks like that:

      Port 3332
Port 3333
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

AllowUsers root
PermitRootLogin prohibit-password
LoginGraceTime 120
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes
TCPKeepAlive yes

AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin yes".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Match LocalPort 3333
        AllowTCPForwarding no
        X11Forwarding no
        AllowUsers git
        PermitRootLogin no
        AllowAgentForwarding no
        PermitTTY no
    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      @agowa338 Please can you tail the GitLab related log files whilst carrying out the anonymous clone operation over SSH?

      sudo gitlab-ctl tail

      Please exclude any sensitive information that my appear in the logs

    • username-removed-1179558
      username-removed-1179558 @agowa338 ·
      Author

      gitlab-ctl tail doesn't print anything special.

      But /var/log/auth Mar 29 19:51:13 vmi99999 sshd[8561]: Connection closed by <My-CLIENT-IP> [preauth] so it is a problem related to ssh I think.

    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      You're running version 9.x right now?

    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      @agowa338 Please could you provide an update for this issue? Thanks!

    • username-removed-1179558
      username-removed-1179558 @agowa338 ·
      Author

      Currently I'm on "GitLab Community Edition 9.1.1 d3123f67". Sorry for the delay, I've been very busy the last weeks.

    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      Does increasing the verbosity of the clone operation grant us any further information:

      GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone ssh://git@gitlab.example.com:3333/root/foo.git
    • username-removed-1179558
      username-removed-1179558 @agowa338 ·
      Author

      Increasing the verbosity doesn't help very much:

      Permission denied (publickey)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
      Edited by username-removed-1179558
    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      Oops, sorry. Wrong flags!

      GIT_SSH_COMMAND="ssh -v" git clone ssh://git@gitlab.example.com:3333/root/foo.git
    • username-removed-1179558
      username-removed-1179558 @agowa338 ·
      Author 
      /home/user/$ GIT_SSH_COMMAND="ssh -v" git clone ssh://git@www.agowa338.de:3333/agowa338/neigh-proxy.git
Cloning into 'neigh-proxy'...
OpenSSH_7.4p1 Debian-10, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to www.agowa338.de [5.189.178.148] port 3333.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to www.agowa338.de:3333 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:j60zz3sfc5JdWHRwwBbRcD40eCkG37wf3a3pzIYZq0s
debug1: Host '[www.agowa338.de]:3333' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
      Edited by username-removed-1179558
    • Felipe Artur moved to gitlab#8746

      moved to gitlab#8746

    • Felipe Artur
      Felipe Artur @felipe_artur ·
      Maintainer

      Hey! :wave:

      GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

      If you have any questions about all of this, please ask them in our dedicated FAQ issue.

      https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

      You can also find more information here:

      Frequently Asked Questions

      For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

      What will we do with the repository names?

      https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

      Why rename gitlab-ce to gitlab-foss?

      Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

      I created a merge requests for CE, and this got closed. What do I need to do?

      You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

      How does the licensing work in this new setup?

      Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

      Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

      No. Merge requests submitted to this project will be closed automatically.

      Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

      Yes.

      How will this affect users of GitLab CE using Omnibus?

      No changes will be necessary, as the packages built remain the same.

      How will this affect users of GitLab CE that build from source?

      Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

      Where can I see a timeline of the remaining steps?

      https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

      Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

      Yes, these changes will be synced to gitlab-foss automatically, several times per day.

    • Felipe Artur locked this issue

      locked this issue

    Please register or sign in to reply