Issue Summary

Bitbucket Data Center's SSH server currently only resolves a repository when the path argument in the Git SSH command is wrapped in single quotes. If a client sends the command without quotes, Bitbucket returns a generic "Repository not found" error, even if the SSH key and user permissions are correct.

Works: git-upload-pack '/PROJECT/repo.git'

Fails: git-upload-pack /PROJECT/repo.git

Fails: git-upload-pack "/PROJECT/repo.git" (double quotes)

While the standard Git CLI always sends the path in single quotes (as per gitprotocol-pack), certain third-party integrations such as SAP Streamworks, use internal SSH clients with hard-coded command formats that omit these quotes.

Because other major Git hosting providers (like GitHub) tolerate both quoted and unquoted paths, these third-party tools work seamlessly elsewhere but are completely blocked when integrating with Bitbucket Data Center.

Steps to Reproduce

1. Step 1
2. Step 2

Expected Results

The SSH command parser should be updated to resolve the repository path even when it is provided in an unquoted or double-quoted format. Since repository paths in Bitbucket do not contain whitespace, the unquoted form is unambiguous and safe to parse.

Why this is important:

Third-Party Compatibility: Enables integration with enterprise tools (like SAP Streamworks) that do not use the standard Git CLI and have non-configurable SSH command strings.

Improved Diagnostics: Prevents the misleading "Repository not found" error, which currently leads administrators to believe there is a permission or SSH key issue when the root cause is actually a command-parsing limitation.

Consistency: Aligns Bitbucket's SSH behavior with other industry-standard Git hosting services.

Workaround

SSH: None.

HTTPS: While Bitbucket supports x-token-auth for Basic Auth, some clients (like SAP Streamworks) only provide a single token field and do not allow for a custom username, making this workaround non-viable for certain integrations.