I want to understand the differences between the SSH Key and the SSH Key fingerprint.
Search on Google but I have not found a clear answer.
Related
I'm using Yubikey 5 NFC and want to move my openssh key into it so that I can authenticate for ssh login via this Yubikey.
Maybe you will suggest to generate a new gpg keypair for Yubikey and use the gpg-agent instead of ssh-agent to authenticate. But I still want to move my current ssh private key into Yubikey because this way I don't have to edit authorized_keys everywhere.
I tried to do this following this article:
https://www.mvps.net/docs/how-to-add-your-existing-ssh-key-to-yubikey-via-openpgp/
which suggest to use pem2openpgp from monkeysphere to translate my ssh key into gpg key and somehow write this translated gpg key into Yubikey (via keytocard command of gpg).
But after all these done. I find that the fingerprint of my ssh key is changed, this is confirmed by following command:
$ ssh-keygen -lf ~/.ssh/id_rsa.pub
$ ssh-add -l
And the fact that the fingerprint changed makes using my current ssh key meaningless -- I still need to edit authorized_keys everywhere to make the "new public key" work.
So is there any other way which can write my old ssh key into Yubikey and keep the old key's fingerprint?
I've used ssh-keygen to generate a ssh key pair, and then ssh-copy-id to copy the public key to the remote server. This has worked for all systems in my local network. I followed instructions similar to this link
However, on bitbucket and github, I see this additional step of adding the private key to the ssh-agent using ssh-add <private key>
This page explains what this additional step but why is that not needed for my local network when it is needed for github and bitbucket?
Thanks
The "Adding your SSH key to the ssh-agent" documented on GitHub (same on GitLab) is only there if you generate a private SSH key protected by a passphrase (meaning, encrypted)
The idea is that, for a private SSH key used for authenticating to a remote public service like GitHub or GitLab, it is better to have an encrypted key, which makes it less dangerous if said key is leaked.
This is different for a private SSH key used inside a LAN (in your local network): using a passphrase is still a good idea but not mandatory: if the SSH key leak, you still need access to the LAN in order to use it.
How to extract or get the 4096 ssh key format from existing 2048 ssh key in window 10.
As i am want to use one web development tools, it requires only 4096 ssh key format, if i have generated new ssh key then old environments and tools won't work so i don't want to break current system workflow.
Is there any way to generate new 4096 ssh key without overwrite the existing ssh key?
or
Can we maintain multiple ssh key in our system?
Please help us.
I found the answers. We can maintain multiple ssh keys in our system.
While generating the ssh key, we have to give unique key name which shouldn't be old key name. We can maintain separate folder for new ssh keys.
PS : Please take backup of existing ssh keys available in ".ssh/" folder before generate new keys.
This command is used to generate ssh key : ssh-keygen -b 4096
I'm having a problem; git returns this alert:
The authenticity of host 'bitbucket.org (104.192.143.2)' can't be established.
RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1
Are you sure you want to continue connecting (yes/no)?
When I choose yes, it returns this:
Warning: Permanently added 'bitbucket.org,104.192.143.2' (RSA) to the list of known hosts.
ssh_packet_read: Connection closed
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
What is the problem?
Where must I add the RSA number? Please, I'm desperate. :(
The authenticity of host 'bitbucket.org (104.192.143.2)' can't be established. RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1 Are you sure you want to continue connecting (yes/no)?
This is normal and it's safe to say yes. ssh is being overly paranoid by asking you to confirm it. You can turn it off by setting StrictHostKeyChecking to no in your ssh config.
Remembering the public key of each server you connect to is a security feature of ssh to protect you from a man-in-the-middle attack. It goes something like this:
The first time you ssh to a host its public key (that's all that SHA256:zzXQ... stuff) is remembered, usually in ~/.ssh/known_hosts.
Every time thereafter ssh will check that the same host is still using the same key. This authenticates that bitbucket.org is still the same server you were talking to the first time.
If the keys don't match it could mean one of two things. First is that the server admin reinstalled their ssh server and forgot to keep the same key. This is common for small sites, but unlikely for something like bitbucket.org.
The second possibility is that the ssh server has been hijacked. It doesn't matter how. One common way is for a rogue DNS server to return their own malicious IP address instead of the real address for bitbucket.org. Common enough on public wifi connections.
As for why it won't connect after confirming, it's right there in the error message.
$ git clone git#bitbucket.org:RobeJablonski/sda-robert.git
Cloning into 'sda-robert'...
conq: repository access denied.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
The repository exists, that can be verified, so you don't have access rights (neither do I). Bitbucket determines who you are using your ssh key. This means you're not logging in with the right key. It has to be the same key as is associated with your account on BitBucket.
You can find your BitBucket ssh keys in your Bitbucket settings under https://bitbucket.org/account/user//ssh-keys/. Then you have to check if ssh is using that key. You can check what it's using using ssh -v git#bitbucket.org. It will spew out a lot of stuff but you're looking for the last instance of debug1: Offering RSA public key: /Users/blah/.ssh/blah.
Once you find that, check if /Users/blah/.ssh/blah.pub matches what BitBucket thinks your ssh key is. If they don't match, then you'll have to find the matching key and configure ssh to use that key for bitbucket.org.
If you've lost the key, you should change your ssh key on bitbucket.org.
Make sure you have followed below steps in your application server:
Have you created public key:
cd ~/.ssh/
To generate keygeneration:
ssh-keygen
Copy public key value (NOT PRIVATE KEY)
cat ~/.ssh/id_rsa.pub
Install git :
sudo apt install git
ATLASSIAN SETUP :
SETTINGS -> Access keys -> Add key
https://bitbucket.org/compassitesinc/your-repository/admin/access-keys/
Make sure your email address added to the User group (with admin permission)
SETTINGS -> User and group access
Add your email address with admin access
Inside your application root directory clone your repository.
cd /var/www/html/
git clone git#bitbucket.org:organization_name/repo_application.git repo_application
You need to create an SSH key on the machine you wish to connect to GitHub or Bitbucket, then add that key to your online account. You can do this by following this:
https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html
I'm following the ssh github tutorial, and I'm confused about the difference between ssh-add and ssh-agent. The tutorial seems to imply that I will need to enter a password every time I want to use my ssh key, and to stop that, I need to give the key somehow to the ssh agent. However, I am not prompted to enter a password until I run the command ssh-add, and according to the man page
ssh-add adds RSA or DSA identities to the authentication agent, ssh-agent(1).
If the point of an agent is to not have to use a password, why is the agent asking me to create a password?
Here's the code I'm running and my understanding of ssh-add:
ssh-keygen -t rsa -C "your_email#example.com"
# Creates a new ssh key, using the provided email as a label
# Generating public/private rsa key pair. Public key is like a padlock, private key is like a padlock key.
# Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]
#This is like taking the padlock and they key together and sticking them in a box.
#-------------------------------
ssh-add id_rsa
#ssh-add is like sticking your key in a safe. Instead of putting your keys on a hook in your house, where anyone can pick it up, you put your key in a safe protected by a password.
Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]
#The safe now has a password.
What is the relationship between ssh-add and ssh-agent? Am I right in assuming the following:
that doing an SSH keygen without an add is sort of like leaving your keys out in your apartment, where anyone you let into your apartment can pick them up, make a copy, and get to all of your stuff?
Doing an SSH keygen with an add is like sticking your keys in a safe with a combination, so that even if you let somebody into your apartment, they still can't get to all of your keys?
That ssh-add is an action taken by a program called ssh-agent?
Assume that you have several Linux machines to manage and you setup ssh login by creating a public private key pair issuing ssh-keygen -t rsa. Assume that you didnt set a passphrase while creating your keys. Now you will copy your public key to all the machines where you want to login by issuing ssh-copy-id -i ~/.ssh/id_rsa.pub user#somehost. Now, with your keys, you will be able to login to all the machines where you copied your keys.
Since you didnt create a passphrase, anyone who gets your private key can login to all the machines where your public key is added. Assume you let your machine to be used by some of your friends and one of him is evil-minded. To prevent this, you set a passphrase to your private key. So whenever you login using your key, you will be prompted for the passphrase and so only you(who knows the passphrase) can login.
But it becomes cumbersome to type the passphrase whenever you login to other machines. So you can give your passphrase to ssh-agent once and it will use it whenever required. You use ssh-add to give your keys to ssh-agent. You can always check what all keys your ssh-agent is managing by issuing ssh-add -l.