Pull repository mirroring: Support for SSH keys

We decided to not do it in the first place, but consider it if a customer requested it. I agree it would be a useful feature.

@ayufan had this to say on the subject:

SSH mirroring. I see a two options:

We generate per-project SSH keys for mirroring: we expose the public key in mirroring settings,

We allow to paste private SSH key when setting up the mirror and it is stored internally,

1 requires less work on the user's side, so I prefer that.

By using global GitLab ssh private key we allow anyone to mirror the repository as long as he knows the URL.

Right, so that's not an option.

I'm not sure how to handle the known_hosts issue, but this can lead to silent error when the host keys changes for remote server (quite unlikely to happen).

The error doesn't need to be silent, we already show mirroring error messages:

mentioned in merge request !51 (merged)

@DouweM

Thanks @DouweM and @ayufan.

Where I can get 'public SSEH key of the GitLab server' please?

@vojtasvoboda.cz The SSH key of the GitLab server is located at /var/opt/gitlab/.ssh/id_rsa, with its public key at /var/opt/gitlab/.ssh/id_rsa.pub. If this file doesn't exist yet, run sudo -u git -H ssh-keygen, and accept the defaults when prompted. This SSH key will be used to authenticate with the remote SSH server, which you would need to upload the public key to.

It prints Unknown option: -H at MacOS. Git version 2.6.3.

@vojtasvoboda.cz Run it on the GitLab server, not your local computer :) Only a GitLab admin with SSH access to the actual server can do this.

Hello, we would like to mirror remote repository to gitlab.com using ssh key. However we could not find what public key should we use to set up as deploy key on the remote repository. Is there a way to solve this now? Is there any way we could help? Thanks, JohnnyB

I have the same problem as @johnnybdude. Can we get the key somewhere so we can mirror our Gitlab repos to GitHub?

Like @johnnybdude and @skorokithakis im wondering where to find the SSH keys used by a gitlab.com.

I tried the host keys returned by gitlab.com (nmap gitlab.com --script ssh-hostkey --script-args ssh_hostkey=all) but none of them worked.

mentioned in issue #317

mentioned in issue omnibus-gitlab#1255 (closed)

If I try to ssh with keys, I get permission denied error on frontend list. When I do the same as git user on gitlab server, it works. Does the mirror script run under git user?

Permission denied error was due Issue #562

Before my question: I’m user of gitlab.com service. There is a git with automatic deployment on my hosting. I normally push commits from my local repo with my private key (public is set on hosting – I can set more than one) and it works like a charm. Now I’m trying to achieve a situation, where I push commit on my hosting and gitlab.com mirror the repo or vice versa.

But it doesn’t work. In the setting it says:

If your SSH repository is not publicly accessible, add the public SSH key of the GitLab server to the remote repository.

I suppose the gitlab.com website should tell me the public key, but it’s nowhere. So I put a key which I found on the internet, which is suppose to be from gitlab.com, but I’m getting this error

Host key verification failed. fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

So either I have a bad key or there is some bug in connection between gitlab.com and my hosting.

Thank you for the answer.

Requested: https://gitlab.zendesk.com/agent/tickets/26191

oops The page you were looking for doesn't exist You may have mistyped the address or the page may have moved

It's not there. I don't really get it. This feature has been there for a long time. I found another people asking for the public ssh key of gitlab.com but nobody ever answers. Is it just me or it hasn’t ever worked?

Same here this is completely broken, also if I enter the default github ssh address that use from command line it ends up on a 500 because it gets confused with a semicolon. Also where are the ssh keys.

I'm also getting a lot of 500's now. I figured out, it's based on the url i put there. Some causes error, some doesn't. It woul'd be just nice to here from the devs 'it's broken guys, just wait for the fix' or at least something.

@ondrejvasicek have you tried with ssh-keyscan gitlab.com?

I've just tried that, used that key on my hosting, right next to my personal public key, which works. Still getting this error

500576
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

mentioned in merge request !608 (merged)

mentioned in commit 9ae5e95d

I think to support SSH properly, we should make encrypted_credentials be structured data. It can then carry username, password, client_pem, and server_pem, supporting the following authentication possibilities:

HTTP(S) username & password
SSH username & password
SSH username & public-key authentication

client_pem and server_pem could also permit client certificate authentication for HTTP(S). I don't know if that's ever been requested, though!

We'll need a bit of a UX overhaul - maybe away from entering userinfo in URLs and towards a tab per protocol. It's too easy to enter invalid URLs at the moment, anyway.

In the "SSH" tab, entering or changing the hostname & port would do a callout to a (Rack::Attack-protected!) endpoint which looks up the 'server_pem' (which is to say, the SSH host key). The fingerprint can be presented to the user immediately for approval or rejection. So by the time the form is submitted in its entirety, the value is already known.

The worker writes out a script that sets up ssh according to the given values, then does GIT_SSH=thatscript git ... as usual.

A naive implementation of that would write the SSH private key to the filesystem, or at least to tmpfs, for the duration of the mirroring operation. That might not be reasonable - thoughts? The expert-level option is to speak the ssh-agent protocol somewhere to provide access to these credentials.

The known_hosts is easy enough, you just write a conforming file and ensure the generated GIT_SSH script has -o UserKnownHostsFile=thatfile

Existing setups where users have tweaked the git user's SSH client configuration on their own server can continue to be supported with a "Let me manage the SSH client configuration manually" checkbox.

When checked, this would hide all the new fields and not set GIT_SSH - so falling back to the default ssh client config for the git user, as happens now.

mentioned in issue #874

Also requested by https://na34.salesforce.com/00161000004xTBK?srPos=0&srKp=001

@regisF @JobV This seems like a highly requested feature (at least from the support perspective) along with support for importing over SSH (need another feature proposal). It could also be seen as a differentiator from other services that don't provide this kind of functionality. Any possibility it can be assigned/milestoned for a future release?

I would love to make this happen. +1 for scheduling it :)

As a workaround, I have managed to mirror things to/from Github by using HTTP authentication and entering the URL in Gitlab like http://user:pass@github.com/skorokithakis/myrepo etc.

Related issues associated to imports for GitLab.com:

Here is another request: https://gitlab.zendesk.com/agent/tickets/40331

Added ~313021 label

We are really desperate for this feature. Would be great to have it scheduled.

@DouweM @regisF weight / requirements?

I had a call with @nick.thomas about this and this is what's been discussed.

Description

There are two ways of setting up mirror repository: during an import or in the Mirror repository settings screen.
Both screens need the same mechanisms to setup SSH ( a total of 3 options, then). One tab in the UI per type of credentials.
- HTTP(S) username & password (as it is now)
- SSH username & password: 4 fields
  - hostname
  - port
  - username
  - password
- SSH username & public-key authentication: 3 fields
  - hostname
  - port
  - username
  - a public key, that we generate on a per-project basis, that the user has to paste to the remote server
- There is a fourth option: when users want to use their own key instead of the one we provide. I don't know if this use-case is heavily used though. I need your thoughts on that, and data too.
And that's it. There should not be other changes on the user-part.

Option-3 is more likely in a corporate environment (There is a fourth option: when users want to use their own key instead of the one we provide.)

A team is assigned a 'bot-ci' user and a set of keys that are placed on Github or external git system. That team is not able to modify or add a public key to the remote system.

Another thing to consider is known_hosts handling. I wrote something on it a while ago but can't find it now. We have to verify the SSH host key of the remote end. There's no DNS or CA infrastructure to speak of (unlike HTTPS), so the only option we really have is to present the fingerprint to the user and ask them to verify it.

In the "new" action, whenever the hostname or port changes for options 2 & 3, we can use JS to ask a heavily cached, rate-limited and ability-secured endpoint to retrieve the SSH host key fingerprint for the hostname+port. This is presented to the user for them to verify (or blindly click past) and submitted with the rest of the form when creating.

In the "edit" action, changing the hostname or port will again need us to verify the host key. In cases where the hostname and port haven't changed, but the remote has changed the host key and mirroring has broken as a result, we'd need a "rescan" button to retrieve the new one.

Once we have it, getting git clone git+ssh://... to respect it is fairly easy - I suggested a method using GIT_SSH above

The known host issue is easily verifiable with a static remote, however Github are known to use AWS for their offering and as a result if load balancers change IP's, then you are likely to get an error on the new endpoint. That has to be addressed without a sync failure.

@regisF there is also a fifth option currently supported: the unencrypted, boring git protocol (i.e., git:// URLs, rather than git+ssh:// URLs).

For GitHub specifically, it may be worth special-casing them to respect https://help.github.com/articles/what-are-github-s-ssh-key-fingerprints/ without user intervention.

When "this host key changed to one I've never heard of before", it is impossible to automatically distinguish between benign and malicious cases.

also githubs ips where quite stable since a while https://help.github.com/articles/what-ip-addresses-does-github-use-that-i-should-whitelist/

the ability to clone via ssh key is quite important, because often username and password give also access to the whole webaccount of the repo, which you might not want to add in the mirror url. ssh keys allow the access to the repo only.

edit: additional you can't use complex passwords any more, you are restricted to passwords which can't contain specific chars or else you will get:

edit2: i personally would prefer to fully (manually) control the ssh keys, known_host and maybe also the ssh_config files for the mirror and remote push process.

@nick.thomas

do we even have to support the 2nd option (SSH username and password)? The initial need was to support SSH keys.
known_hosts: noob question → can we bypass that and blindly accept without verifying?

@regisF I think we support it now; removing support for it would be peculiar.

Accepting the host key without some form of verification would be a security risk - think of it as being on the same scale as configuring gitlab globally to ignore SSL certificate verification.

I think a checkbox letting the user decide to auto-accept known host changes.

@nick.thomas for existing setups (as you mentioned here), can't we just let "as is" in terms of UI? That way, we don't say in the UI that we support custom setups, but we still support existing ones (under the hood)?

@regisF we could, but I'm a little worried about the transitionary period where someone has an existing, working setup (albeit undocumented), upgrade their GitLab instance and discover that they can't use it for any new projects.

I don't see how to preserve the current behaviour for new projects without some UI - or how to signal that an existing project is using it, for that matter.

@nick.thomas I see. But why couldn't they still setup custom solution for new projects? I don't see which changes introduced with this feature would prevent them to continue to do so.

@regisF so they create a new project. It doesn't have any mirroring enabled. They go to the "set up project mirroring page", and are presented with a list of options. They need to do something, or mirroring will never be attempted. What do they do?

Say they pick "SSH with public-key authentication" (option 3, above). This will necessarily disable the implicit SSH client configuration to make it pick up the autogenerated key, so their new project won't use it.

@nick.thomas but how are they doing today? They only have one choice (HTTP, HTTPS or git) (which is option 1 above for us). So wouldn't they do the same?

Is this going to be a CE feature too, or just limited to EE?

@regisF it looks like this today:

They enter a URL like ssh://username@example.com/project.git and there is no option to enter an SSH key. That, the SSH client configuration that causes it to be used, and the known_hosts entries, are all picked up from the default SSH client configuration on the gitlab server.

My UI proposal above was to split up the view so each existing URL type is handled with separate inputs; if the only options for SSH require password to be entered, or generate and force the use of a specific private key, then there is literally no way to request a new project to use the existing scheme, or to signal that an existing project uses it.

@nick.thomas ok so the simplest solution for this is:

we will have two tabs: HTTP and SSH
The HTTP tab is what we have today. We don't change that so we won't break anything that has been setup previously.
The SSH tab is the new tab where we ask for the remote address, port, username and we display a SSH key we generate on our end.
If people want something more in the future, we'll do in a future iteration.

I've updated the body of the issue to reflect this.

@DouweM can you read the body of the issue and put a weight on this?

Mentioned in issue #1123

Milestone changed to %8.14

Added ~481018 label

Milestone changed to %8.15

Milestone changed to %Backlog

@nick.thomas can you check the wireframes at the top and let me know if I'm missing something?

mentioned in issue #1490 (closed)

@awhildy could we put someone on the design side for this feature? Thanks!

@hazelyang - can you help out here? Thanks!

added ~126459 label

@regisF couple of things:

The 'git://' protocol isn't HTTP(S), but is being referenced under that tab. It's pretty minor as long as support doesn't go away.

There's no way to represent or preserve the existing implicit SSH configuration.

@awhildy Sure!

assigned to @hazelyang

mentioned in issue gitlab-com/support-forum#695 (closed)

The design is based on current wireframes. If there is something needs to be adjusted, please let me know.

HTTPS

SSH

Are there plans to have individual project mirror frequency details. Currently this is globally set and not really ideal.

@casibbald yes, there are! I think https://gitlab.com/gitlab-org/gitlab-ee/issues/99 should cover that? If so, the intention was to do it for 8.16, but it may not make it as we are very short of capacity for the 8.16 release.

Looks good @hazelyang. Thanks!

@regisF Do you think we need any guidance next to the SSH key so people know what to do with it? Or maybe a link to some documentation? This might not be needed and I don't want to go overkill -- just want to make sure things are clear to people, though. Thanks!

changed milestone to %8.17

added EE Starter label

added ~1012342 label

removed ~126459 label

removed assignee

Thanks @hazelyang, great as always.

The comment of @awhildy (very pertinent, thanks) made me realize that we need indeed some instructions on what to do with the SSH tab.

Perhaps something like:

Here is the public SSH key that needs to be added to the remote server. For more information, please refer to the documentation.

@hazelyang could you update the design accordingly? Thanks!

@awhildy @regisF Updated SSH tab!

changed milestone to %Backlog

@mydigitalself to schedule in an upcoming release.

We need that as well, would be great to get this scheduled for an upcoming release.

added SP1 label

Another customer has asked for this: https://gitlab.zendesk.com/agent/tickets/78257.

Hello,

Also please don't forget to update the API so we can set everything needed for mirroring.

Currently, as a customer of GitLab EE, we cannot set mirroring through the API which is currently something we do by hand.

mentioned in issue #2803 (closed)

https://gitlab.zendesk.com/agent/tickets/79486

Any idea when this feature will be released then? :) (Our prod runs GitLab EE 9.3.3)

changed milestone to %9.5

added frontend label

added Deliverable label

known_hosts management:

When we setup SSH, we need to display the message returned by known_hosts to verify the host key, and ask the user to answer (yes/no).

When we edit SSH setup, we also need to re-trigger the verification

@hazelyang What would this stage look like?

changed title from Repository mirroring: Support for SSH keys to Pull repository mirroring: Support for SSH keys

@DouweM Just to clarify as I am not sure I understand the context.

Does this stage happen after clicking 'Verify SSH connection' button? Or it happens on SSH keys page when we add an ssh key?
What kind of message will we display to verify the host key?

Thanks!

changed the description

@hazelyang This would be after hitting "Verify SSH connection" and after saving a new SSH URL. On the command line, it looks like this:

% ssh git@gitlab.com
The authenticity of host 'gitlab.com (52.167.219.168)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no)?

Then when you type yes, you get:

Warning: Permanently added 'gitlab.com' (ECDSA) to the list of known hosts.

We could use the same message, but using a button instead of typing yes/no, of course.

@nick.thomas Do you have any extra thoughts? I'm thinking of asking you to work on this for 9.5 :)

@DouweM awesome, this would be right up my street :)

I think I'd have a text input inline (i.e., no modal dialogue box) to display the fingerprint, and a checkbox for the user to confirm that they have verified the fingerprint. When the JS in the browser fetches a new fingerprint, it can uncheck the verified_host_key checkbox.

If you try to create or update SSH mirror settings and the verified_host_key checkbox isn't set, the create / update can be rejected. The form submission can be disabled clientside too. In this way it's roughly analogous to

We do need the button to manually refresh the fingerprint - "Verify SSH connection" - but if the existing fingerprint is blank and unverified, we can probably fetch the new fingerprint automatically when the URL input loses focus and the hostname has changed.

We can probably achieve the 90% case by including a hardcoded hostname -> fingerprint map, and automatically checking verified_host_key if it matches.

If you'll excuse the terrible GIMPing:

The wording is a bit shaky and we might want red / green background hinting and some visual grouping of the text input, checkbox and verify button to make it clear what's happening, but that can be worked out through experimentation.

We could also include some help text on either the input or the checkbox, like so:

(automatically verified)

GitLab automatically verified this fingerprint one week ago

(manually verified)

@nick.thomas manually verified this fingerprint just now

this is useful, both for auditing, and for educating users who just click through about what they committed to when checking the box.

assigned to @nick.thomas

@DouweM Thanks for clarifying!

I think I'd have a text input inline (i.e., no modal dialogue box) to display the fingerprint, and a checkbox for the user to confirm that they have verified the fingerprint. When the JS in the browser fetches a new fingerprint, it can uncheck the verified_host_key checkbox.

@nick.thomas What do you think if we have a dialogue box(01) to let the user confirm the fingerprint after clicking 'Verify SSH connection' button? I think it's more usual to use checkbox to activate a feature than to confirm something.

We could also include some help text on either the input or the checkbox

If we use dialogue box, the help text will be next to the button.

I am wondering if we need to display who verified the fingerprint manually. We perhaps can remove it.

01 - Dialogue box	02 - Help text

@hazelyang I shyed away from the dialogue box in favour of having the inputs inline because it makes sense for the user to be able to manually input or remove a host key to use.

Checkboxes are used for confirmation in various scenarios - accepting EULAs comes to mind for instance.

What we're asking the user to do is to warrant that the information in front of them is accurate. I guess I don't mind too much whether it's a button or a checkbox, as long the user can't click through without taking some sort of additional action. We could have a pair of buttons - good / bad - instead of a checkbox.

@nick.thomas Thanks for the feedback!

Clean up the flow:

After entering Git repository URL, SSH hot key fingerprint is fetched automatically (01).
After clicking Verify SSH Connection button, a dialogue box appears next to the button (02).
After clicking Correct button in the dialogue box, the help text is displayed under SSH hot key fingerprint (03).
After clicking Cancel button, nothing happened.

If I missed something or you find something wrong, please let me know. Thanks!

01	02

03

mentioned in merge request !2423 (closed)

Thanks @hazelyang , I can work with this.

@filipa I may need some frontend help later on in the month - I'm putting together simple, stupid, ugly bootstrap in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2423 to help me build the backend, but I doubt it'll be production-quality. No action needed yet, just a heads-up :)

@nick.thomas I'm FE for this deliverable, so feel free to mention me here or ping me on Slack when you need me.

Thanks! Will do

Presumably we want to keep the generated SSH private key gitlab-server-side only - so we can't show the public part (ssh-rsa ...) until the mirror settings have been saved at least once.

We'll also need to allow users to regenerate the key somehow.

I propose we generate 4096-bit RSA keys by default. DSS keys are unusual, and the elliptic options are less well-supported. Generating such a key takes perhaps a second (although running out of random bytes will slow it down).

It seems peculiar to implement this for pull mirrors without also implementing it for push mirrors, but I see now there's a lot of wide open space between the two features in the backend. @DouweM should we open a separate issue for push mirroring and perhaps try to get it in in %9.5 as well?

I'm leaning to the tabs beingPassword authentication | SSH public key authentication rather than HTTP | SSH. This is closer to what we're actually doing, and affords very good backward compatibility with these existing use cases:

Global SSH key in ~git/.ssh/id_rsa
SSH password authentication

They're both purposefully undocumented at the moment, but we have existing EE customers using them regardless.

It's also good if we need to add "HTTP client certificate auth" in the future.

We'd move the "Git Repository URL" out of the tabs, as it's common to all of them.

@DouweM should we open a separate issue for push mirroring and perhaps try to get it in in %9.5 as well?

@nick.thomas Please create a new issue, but only try to do it for 9.5 if it doesn't get in the way of any of your other assignments. We are only targeting pull mirrors right now as a way of reducing scope and increasing the likelihood of us shipping something at all :)

I'm leaning to the tabs beingPassword authentication | SSH public key authentication rather than HTTP | SSH. This is closer to what we're actually doing, and affords very good backward compatibility with these existing use cases:

@nick.thomas But isn't there also a difference in what URL format we'll allow? It does feel more like HTTP URL vs SSH URL to me.

@DouweM different URL schemes are valid depending on the authentication system. We can work that into both validations and frontend.

Unless you mean we should support username@foo:bar/baz.git in the SSH authentication case? That would make sense, given it's the form gitlab exposes the SSH repositories in, but we'll still need to support the explicit ssh:// scheme as well to handle custom ports...

Reading the host key fingerprint needs to happen in the background; the frontend will need to poll until it's done, which means we'll need somewhere to store the fingerprints. This is probably best put into redis.

Since repository mirroring ends up using gitlab-shell's fetch_remote function, I've opened https://gitlab.com/gitlab-org/gitlab-shell/issues/95 to discuss the best way of adding public key support.

Working on the SSH host key part of this now. The current UI wireframes assume a single host key, always expressed as a fingerprint.

I'm starting to think the known_hosts format is more useful:

No ambiguities (hex vs. base64 keys, etc)
Supports multiple keys
We can calculate the appropriate fingerprint of the day from the key, but not vice-versa
Easy manual input
Easier verification - code already exists

In terms of actually performing the host key detection, I'll just shell out to ssh-keyscan. It doesn't look like net-ssh would make this any easier.

A thought. Currently, user-password authentication over SSH "almost works" for pull mirrors. All that's missing is SSH host key management - right now, the code path uses the system git user's configuration, as it does for public key authentication.

I think we should promote the SSH host key management UI so it applies to both user/pass and public-key authentication, only showing it when the URL is ssh://. For backward compatibility, we can fall back to the system configuration for host keys if this configuration is present.

Two benefits:

Use user+password SSH URLs on GitLab.com, and elsewhere
Pubkey auth gets the global known_hosts config fallback, which may be useful to some on-premises installations.

The UI will also make more sense. Now I've noticed it, the placement of SSH host keys with just public-key authentication is really bugging me!

marked this issue as related to gitlab-shell#95 (closed)

UX update:

I stress it won't actually look like this in the final version, this is just showing the new placement of things.

@nick.thomas Do we still show the user the fingerprint rather than the known_hosts format when they're asked to verify it? Sysadmins of both private and public Git instances often tell their users "The fingerprint for X will change to Y on date Z" over twitter for example, which is much easier to manually verify than the entire key.

I also worry that presenting it as a textarea they can edit may be confusing to users looking for a single fingerprint.

mentioned in issue gitlab-shell#95 (closed)

@DouweM the ssh_host_keys detection endpoint presents both the detected known_hosts entries and the fingerprints for each entry (indexed by line number). I'd expect the complete frontend to show the fingerprints to the user, but put the known_hosts entries into the form.

We could hide the manual-entry known_hosts <textarea> by default and only show it when a "more details" icon of some sort is pressed?

I'd expect the complete frontend to show the fingerprints to the user, but put the known_hosts entries into the form.

@nick.thomas OK, good.

We could hide the manual-entry known_hosts <textarea> by default and only show it when a "more details" icon of some sort is pressed?

I wouldn't mind a button to "Enter known_hosts entry manually", or something like that

@kushalpandya - look up :)

Clean up the mockups.

To prevent from missing some interactions, I have some questions:

For password authentication, do we need a "Save" button to save the password?
What happens if click "Rest SSH key" button?

Thanks!

Password authentication	SSH public key authentication

@hazelyang the password can be used for both SSH and HTTP(S) URLs.

Currently it's saved when you press the "Save changes" button just below.

Pressing "Reset SSH key" currently does a PUT to the same endpoint as "Save changes" does, just causing the ssh-rsa .... value to change.

Also, the password can no longer go in the "Git repository URL" input, so the help text there has changed.

mentioned in merge request !2550 (closed)

mentioned in merge request !2551 (merged)

mentioned in issue gitlab-com/www-gitlab-com#1584

closed

reopened

mentioned in merge request omnibus-gitlab!1585 (merged)

changed the description

@hazelyang I've updated the issue description; can I ask for one more mockup focusing on the ssh known hosts flow? In particular:

There may be multiple host key fingerprints to display
They will be formatted like 45:ff:5b:98:9a:b6:8a:41:13:c1:30:8b:09:5e:7b:4e at the moment
It should be hidden from view when a non-SSH URL is provided
Users should be able to press some sort of control to get a <textarea> they can manually input known_hosts data into

Perhaps a <ul> that gives way to a <textarea> when an "advanced..." button or link is clicked? WDYT @kushalpandya ?

@nick.thomas @hazelyang I've rearranged button position and updated label for SSH host keys input instead of showing checkbox without further complicating UI, it looks like this.

@hazelyang As for fingerprints data, here's the example data that we need to show somewhere on UI when user has provided SSH URL and clicked Detect host keys button;

{
  "known_hosts": "gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=\ngitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9\ngitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf\n",
  "fingerprints": [
    {
      "bits": 256,
      "fingerprint": "f1:d0:fb:46:73:7a:70:92:5a:ab:5d:ef:43:e2:1c:35",
      "type": "ECDSA",
      "index": 0
    },
    {
      "bits": 2048,
      "fingerprint": "b6:03:0e:39:97:9e:d0:e7:24:ce:a3:77:3e:01:42:09",
      "type": "RSA",
      "index": 1
    },
    {
      "bits": 256,
      "fingerprint": "2e:65:6a:c8:cf:bf:b2:8b:9a:bd:6d:9f:11:5c:12:16",
      "type": "ED25519",
      "index": 2
    }
  ]
}

@nick.thomas @kushalpandya UI for the fingerprint. I moved text area for Manual SSH host keys above Fingerprint.

Have a question: Will "Detect host keys" be changed to another button(or state) if users click it?

Fingerprints are hidden	Fingerprints are visible

@kushalpandya @nick.thomas Updated the UI again! Thanks!

01-Clicking Detect host keys

Detect host keys button appears when users entered ssh:// in Git repository URL.
Having an animation in the Detect host keys button to indicate that GitLab is detecting host keys.

00-Default	01-Clicking Detect host keys

02-Show fingerprints

Detect host keys button is disabled if there is nothing changed in Git repository URL.

02-Show fingerprints	03-Show advanced information

04-Authentication method - SSH public key	05-Authentication method - Password

Thanks @hazelyang!

I think it would be reasonable to disable the detect host keys button once a success result has come back... in case of an error, the user might want to try again. It's all pretty cheap though, so I wouldn't be concerned.

@hazelyang We missed out on adding Copy to clipboard button for copying SSH public key, I've added that button for now, but it doesn't feel right, can you suggest better way to do it?

@kushalpandya

Maybe we can put the icon next to the text?

closed via merge request !2551 (merged)

mentioned in commit 7559ccc7

mentioned in issue #3233 (closed)

Awesome that this was recently merged! Any chance to add the same feature for Push mirroring? Use case is we re migrating from Redmine with "gitolite" to Gitlab EE. We'd like to push changes back to Redmine to reflect merged branches but unfortunately gitolite only supports SSH protocol.

mentioned in issue #3251

@colinmollenhour thanks for the request. I've opened an issue to reflect it here: https://gitlab.com/gitlab-org/gitlab-ee/issues/3251

It references a couple of technical debt issues thrown up in the implementation of pull mirroring support. Once those are done, it should be quick and easy to add push mirroring support.

mentioned in issue #3270 (closed)

mentioned in issue #1255

mentioned in issue gitlab-shell#103

Is this in a release yet?

@jegarts it's present from GitLab EE %9.5

Running GitLab EE 9.5.2 on git 2.7.4 in production, the push over SSH is working out for me, target is a simple gitolite 3.6.6 on git 2.7.4, I authorized the key from /var/opt/gitlab/.ssh/id_rsa.pub.

Allows us to have a very easy to deploy/setup/admin remote async backup of your git repos thanks.

mentioned in issue #3308 (closed)

mentioned in issue #3195

Pull repository mirroring: Support for SSH keys

Resources

Design

Designs

Child items ...

Activity

Description

HTTPS

SSH

01-Clicking Detect host keys

02-Show fingerprints

Admin message

Admin message

Pull repository mirroring: Support for SSH keys

Resources

Design

Relates to

Activity

Description

HTTPS

SSH

01-Clicking Detect host keys

02-Show fingerprints