Finger Github

[Marine Farinha]

Iwant to add GitHub to my computer's list of acceptable SSH hosts for a coding boot camp that I will be taking soon. The boot camp says that I need to do so via GitHub's RSA public key fingerprint. However, I keep getting GitHub's ED25519 public key fingerprint instead. Is there any way to fix this?

It used to be that GitHub offered only RSA and DSA keys as host keys. However, that changed recently, and GitHub now offers ECDSA and Ed25519 keys as well (and has removed the DSA key). On a fresh system, the latest versions of OpenSSH will prefer the Ed25519 key over the RSA key, which is normal and fine.

The GitHub API meta endpoint lists both the correct fingerprints and the actual SSH keys themselves. From a cursory glance, you appear to have the correct fingerprint, but you can verify that by pasting the fingerprint from the API at the prompt.

A better approach, to avoid any MITM (Man-In-The-Middle) attack, would be (as commented below by Mamsds) to verify GitHub's public key first (see "GitHub's SSH key fingerprints") and, if you find a match, then you can answer 'yes'.

Note: the ssh key generation should use the base64 old PEM format (option -m PEM), rather than the new current 70 chars OpenSSH one.

See "What is the correct format for private key in Credentials":

We immediately acted to contain the exposure and began investigating to understand the root cause and impact.

We have now completed the key replacement, and users will see the change propagate over the next thirty minutes.

Some users may have noticed that the new key was briefly present beginning around 02:30 UTC during preparations for this change.

Please note that this issue was not the result of a compromise of any GitHub systems or customer information.

Instead, the exposure was the result of what we believe to be an inadvertent publishing of private information. We have no reason to believe that the exposed key was abused, and took this action out of an abundance of caution.

For anyone running into repeated ECDSA host key for 'github.com' differs from the key for the IP address / Offending key for IP issues and you can't grep IPs in known_hosts because you have hashed entries, I have created a Gist listing all Github git IPv4 addresses (as of Fri Mar 24 16:33:22 UTC 2023), generated from CIDRs listed in :

When uploading your project to Github, check whether https or ssh is selected under quick setup. I accidentally selected ssh and got the same output in the terminal. By selecting https, I recreated the git remote add origin .... section.

It won't ask you for a fingerprint, because ssh is not involved, https is used instead. For a security standpoint you are trusting root certificates installod on your OS. If you're using a minimalist image or Docker, you might need to install the ca-certificates package.

Do you really need to add the key at runtime? This is not secure because you didn't check the fingerprint and that leaves you open to MiTM attacks. This is not just theoretical, and it has been proven to work.

And check it manually against those listed in this page (ok, there you trust https certificates and OpenSSL to bring you the original github website, but it's still a lot better than blindly accepting a public key).

While I certainly understand that you want to automate such a process, doing so would be ill-advised. The reason why SSH and related networking subcomponents balk when using a secure protocol is to WARN a human that a system's public key is unknown. This is intentional - the user needs to explicitly inform the system the host is expected. You wouldn't want to auto accept every public key presented to you or part of the security in SSH or TLS/SSL could be compromised. One example is via a man-in-the-middle attack such as when a proxy software presents it's own key in the place of a host you expect.

As Jeff Hall said, doing so is dangerous as it allows undetected man-in-the-middle attacks. However, you could use the StrictHostKeyChecking no option in ssh to disable checking the host keys. However, I'd be very careful with that option if I were you.

If however you get an error like; Could not open a connection to your authentication agent.

Then it means that ssh-agent is not running. You can start/run it with: ssh-agent bash (thanks to @Richard in the comments) and then re-run ssh-add -l

A key pair (the private and public keys) will have the same fingerprint; so in the case you can't remember which private key belong to which public key, find the match by comparing their fingerprints.

The most voted answer by Marvin Vinto provides the fingerprint of a public SSH key file. The fingerprint of the corresponding private SSH key can also be queried, but it requires a longer series of step, as shown below.

It used to be that GitHub offered only RSA and DSA keys as host keys. However, that changed recently, and GitHub now offers ECDSA and Ed25519 keys as well (and has removed the DSA key, since it's insecure). On a fresh system, the latest versions of OpenSSH will prefer the Ed25519 key over the RSA key, which is normal and fine.

While in general, you should always verify the SSH key fingerprint, in this case, the fingerprint is correct but it's just a different key. You should let the maintainers of this tutorial know that their information is out of date and that they should update the documentation.

Imitation learning from human hand motion data presents a promising avenue for imbuing robots with human-like dexterity in real-world manipulation tasks. Despite this potential, substantial challenges persist, particularly with the portability of existing hand motion capture (mocap) systems and the difficulty of translating mocap data into effective control policies. To tackle these issues, we introduce DexCap, a portable hand motion capture system, alongside DexIL, a novel imitation algorithm for training dexterous robot skills directly from human hand mocap data. DexCap offers precise, occlusion-resistant tracking of wrist and finger motions based on SLAM and electromagnetic field together with 3D observations of the environment. Utilizing this rich dataset, DexIL employs inverse kinematics and point cloud-based imitation learning to replicate human actions with robot hands. Beyond learning from human motion, DexCap also offers an optional human-in-the-loop correction mechanism to refine and further improve robot performance. Through extensive evaluation across six dexterous manipulation tasks, our approach not only demonstrates superior performance but also showcases the system's capability to effectively learn from in-the-wild mocap data, paving the way for future data collection methods for dexterous manipulation.

Overview of the DexCap system:

Front design: A camera rack on the chest is equipped with an RGB-D LiDAR camera and three SLAM tracking cameras.

Back design: A mini-PC and power bank in the backpack power the system for approximately 40 minutes of data collection.

Data collection process: The tracking cameras, initially placed in the camera rack for calibration, are relocated to hand mounts during data collection to consistently track the palm positions. Finger motions are captured by motion capture gloves.

Compare to vision-based method: In this example, human is holding the mug handle with a fixed gesture. The vision-based hand tracking method used by the VR headset fails to accurately track finger positions due to heavy occlusion. DexCap is more capable of collecting hand-object interaction data.

Action retargeting: To transfer human finger motion to the LEAP robot hand, we use fingertip inverse kinematics (IK) to compute the 16-dimensional joint positions. Human finger motions are tracked using a pair of motion capture gloves, which measure the 3D positions of the fingers relative to the palm based on electromagnetic field (EMF).

Visual gap: To further bridge the visual gap between human hand and robot hand, we use forward kinematics to genrate a point cloud mesh of the robot hand and add it to the pointcloud observation as is shown in this video.

We first retarget the DexCap data to the robot embodiment by constructing 3D point clouds from RGB-D observations and transforming it into robot operation space. Meanwhile, the hand motion capture data is retargeted to the dexterous hand and robot arm with fingertip IK. Based on the data, a Diffusion Policy is learned to take the point cloud as input and outputs a sequence of future goal positions as the robot actions.

DexCap supports two types of human-in-the-loop correction during the policy rollouts:

(1). Residual correction measures the 3D delta position changes of the human wrist and incorporates them as residual actions to the robot's wrist movements. This mode enables minimal movement but requiring more precise control.

(2). Teleoperation directly translates full human hand motions to the robot end-effector actions based on inverse kinematics. This mode enables the full control over the robot but requiring more effort.

Users can switch between the two modes by stepping on the foot pedal during the rollouts.

This research was supported by National Science Foundation NSF-FRR-2153854 and Stanford Institute for Human-Centered Artificial Intelligence, SUHAI. This work is partially supported by ONR MURI N00014-21-1-2801. We would like to thank Yunfan Jiang, Albert Wu, Paul de La Sayette, Ruocheng Wang, Sirui Chen, Josiah Wong, Wenlong Huang, Yanjie Ze, Christopher Agia, Jingyun Yang and the SVL PAIR group for providing help and feedback. We also thank Zhenjia Xu, Cheng Chi, Yifeng Zhu for their suggestions in tuning the robot controller. We especially thank Kenneth Shaw, Ananye Agrawal, Deepak Pathak for open-sourcing the LEAP Hand.

3a8082e126