I've got a Github account setup on one computer. I would like to also access my Github account on a second machine using the same SSH key I used for the first computer. How do I import the SSH private key into the new computers user profile?
cp ~/other_comp_github_key ~/.ssh/github
The above command did not do the job in the git bash console on Windows.
Argh! No!
Do. Not. Share. Private. Keys.
Make a new keypair on the second computer.
It'd be best to create a new private key if github allows you to have several associated with your account. (Sharing private keys among machines is very much like sharing passwords on multiple accounts.) But not all services allow multiple keys, so...
You don't specify that you copied the private portion of the key; make sure you copy the private portion.
You don't specify that you configured the ~/.ssh/config block to use the ~/.ssh/github key for the github.com host. Make sure you add a new block to your ~/.ssh/config file just like block on the machine you stole the key from.
host github.com
IdentityFile ~/.ssh/github
(I don't know that the host is github.com -- if you use a different hostname, then use that.)
The copying of the private key will work, iff the permissions to the ssh files copied are correct, i.e. readable for the user who uses the keys, something like 555 will do. Also, since github allows multiple ssh keys to be used with same account, you can create a new keypair and add it to your account.
I had the same issue, simply create a new SSH Key in the other computer since its not advisable sharing the same SSH Keys across different computers.
Follow these sets of instructions on Github,I found them pretty much direct and easy to follow.
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
Related
I have a AWS EC2 Instance running with a PEM file kept at a safe place.
Now I want to give sftp access to one of the user to a particular directory. For this they have given me the private key file of their system. Is it possible to somehow import that private key on AWS Instance?
In general, private keys should not be distrubuted. You need the users public key. You can then place that public key in the ~/.ssh/authorized_keys file for the user you want to allow access to. Note that you can use both sftp and scp to retrieve files from as server in a secure fashion. In my opintion, scp is easier to setup, but you may want sftp depending on your use case. If you want additional information on setting up SFTP, check How to setup an SFTP server on CentOS.
If you need is share a directory, you can associate your EC2 instances to an EFS clúster and share a directory between two or more instances and you could have a private instance (only you will have ssh access) and other public (other users can access to this instance by ssh or sftp).
Create public key and placed in ~/.ssh/authorized_keys file for anyone user need to access.
You should using sftp instead of scp for secure purpose.
So i am having a rather severe issue with setting up OpenSSH for password-less entry on my university supplied computer.
There are 2 main issues:
1. The default config and known_hosts file created by openSSH upon first use default to the university h: directory. This is a local directory so i would need to be connected to the local network or using a VPN which isn't always the case. So the first question is, how can i change where the openSSH looks for known_hosts and config.
2. The second issue is that when i try to set up passwordless entry. It is that the openssh client tells me that my private key is not protected which is fair enough, but what is the best way to change the permissions because I have tried through windows properties and it is hopeless.
This was only fixable by changing to a different SSH program, copSSH.
I am fairly new at EC2 technology so I think I am missing some points. So I set up an instance which is running and had created two key pairs. I choose the instance, choose "Connect" and the site gives me instructions about that. I follow them and when I execute the ssh command returns that "network is unreachable". Can you help me please?
Okay a few things to check:
Make sure you have the correct ports on your security group open to either your personal IP or to the world, depending on your security requirements. For example: Port Range 22, IP 0.0.0.0/0 (World) xx.xx.xx.xx/32 (personal IP)
Next I would make sure you are executing the command correctly.If 1 does not work can you post the command?
Another thing to check, although based off your error this probably isn't it, is that your have the proper permissions on your private key. chmod 600 mykey
If you're using Amazon Linux the username is ec2-user, which you can then run sudo from.
I've got an instance using this AMI - ami-b7a29cc3
http://thecloudmarket.com/image/ami-b7a29cc3--bitnami-wordpress-3-3-1-1-multisite-linux-ubuntu-10-04-ebs#/details
Which is a Wordpress Multisite Bitnami Image.
It's installed and booted up fine, I've setup the security groups SSH, HTTP, HTTPs.
But weirdly enough connecting via SSH is not working, despite the front end working fine.
I've tried the following users and commands to no avail, ubuntu, root and bitnami.
I keep getting something weird like this happen though when I run the command.
D-Hewards-MacBook-Pro:Downloads dheward$ ssh -i macbookpro.pem bitnami#176.34.127.170
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
9f:85:89:8a:7a:9d:db:e0:15:e4:11:d0:e0:4b:74:a9.
Please contact your system administrator.
Add correct host key in /Users/dheward/.ssh/known_hosts to get rid of this message.
Offending key in /Users/dheward/.ssh/known_hosts:17
RSA host key for 176.34.127.170 has changed and you have requested strict checking.
Host key verification failed.
D-Hewards-MacBook-Pro:Downloads dheward$
This is likely (i.e. you need to judge this yourself after reading and understanding my explanation, because otherwise your security would indeed be at risk!) just normal behavior of SSH coupled with reuse of the meanwhile scarce IP addresses by Amazon EC2 (see IPv4 address exhaustion):
Background
The server side of your SSH connection needs to identify itself by the mentioned fingerprint for the RSA key, which is subsequently checked by your client side SSH tooling to ensure you are not falling victim of a Man-in-the-middle attack.
Regular SSH Process
you connect to a new SSH server for the first time
the new server presents its RSA key identity to your SSH client
your SSH client asks you to confirm this servers identity and will import the RSA key in turn for future security checks (into /Users/dheward/.ssh/known_hosts in your case)
ideally you'd have received this RSA key on a secure channel to properly assess its validity, however, most people simply don't do that in nowadays ever changing cloud environments, see Eric Hammond's Poll: Verifying ssh Fingerprint on EC2 Instances
Eric's post mentions options to deal with this in principle already, i.e. For optimal security, you are supposed to request the instance console output and find the ssh host key fingerprint in the log to verify that it is the same as the fingerprint presented to you by the ssh command.
Furthermore, Eric discussed this topic in great detail in ssh host key paranoia.
Scott Moser has distilled a great summary how to actually Verify SSH Keys on EC2 Instances and provides instructions on how to update your known_hosts file in turn as well.
on every subsequent connect to the same SSH server, your SSH client will compare the stored RSA key with the one provided by the SSH server and will present a big fat warning regarding potential nastiness if it changes, because it usually shouldn't indeed (I'll skip the rare exceptions for now)
this means, if it suddenly changed (especially for a host you had been connecting to already without such a warning), you should indeed back out immediately and assess the situation first, i.e. if you don't know a reason for the change, your connection security is at risk
Cause (i.e. Your Experience)
You might have gone through steps 1-4 once for another SSH server on EC2, which happened to have the very same IP address from their pool (i.e. 176.34.127.170); while not encountered every day, this is all but unlikely over time given the limited number of IPv4 addresses available in general and the respective pool available for Amazon in particular.
Now, since you are connecting to an entirely different server then the one for which the RSA key had been stored in the first place (every started EC2 instance has a respectively unique identity), your SSH client cries foul and presents the properly escalated warning you are seeing.
Furthermore, it seems to disallow SSH access entirely in this situation, since you [or your system administrator] have requested strict checking. (Most desktop SSH clients seem to ask for confirmation just like on first commit in this case by default).
Solution
Make damn sure my explanation of your experience actually applies to your situation!
Follow the instructions given in the warning message already:
The fingerprint for the RSA key sent by the remote host is
9f:85:89:8a:7a:9d:db:e0:15:e4:11:d0:e0:4b:74:a9. Please contact your
system administrator. Add correct host key in
/Users/dheward/.ssh/known_hosts to get rid of this message. Offending
key in /Users/dheward/.ssh/known_hosts:17 RSA host key for
176.34.127.170 has changed and you have requested strict checking. [emphasis mine]
I.e. the SSH RSA key cache maintained in /Users/dheward/.ssh/known_hosts currently has an entry No. 17 for IP address 176.34.127.170 with a different RSA key then the one presented by the server with IP address 176.34.127.170 you are currently trying to connect to - this must be adjusted, if you are sure there is no man-in-the-middle-attack in place in fact (which is unlikely, given that this is a new host you just commissioned, though as mentioned in 3) above, you might want to ensure this by following Scott Moser's instructions how to actually Verify SSH Keys on EC2 Instances).
Good luck!
I need to access a SVN repository from home, that runs under the IP 192.168.0.10 in the work network.
I can establish a SSH tunnel to my localhost.
Now I have to map 192.168.0.10 in a way, that instead 127.0.0.1 is accessed.
Does anybody know a way to do this under Windows?
TortoiseSVN allows you to relocate your repository
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-relocate.html#tsvn-dug-relocate-dia-1:
If your repository has for some reason changed it's location (IP/URL). Maybe you're even stuck and can't commit and you don't want to checkout your working copy again from the new location and to move all your changed data back into the new working copy, TortoiseSVN → Relocate is the command you are looking for. It basically does very little: it scans all entries files in the .svn folder and changes the URL of the entries to the new value.
Or you can use svn command:
svn switch --relocate From_URL To_URL
When you're at work, edit your HOSTS file to have svn = 192.168.0.10; when you're at home, edit it to have svn = 127.0.0.1, and then access it, in both by using 'svn' as the server name.
Alternatively, use the "svn switch --relocate" command to change the repository location when you need to.
Can you reference the DNS name instead? You can override the IP address for a DNS name in your hosts file (C:\windows\system32\drivers\etc\hosts).
I'm not sure that's possible at all. What you could do would be to reference a DNS name instead. You can change the IP the DNS name points to using your hosts file.
edit your hosts file located at %SystemRoot%\system32\drivers\etc\
As I understand the question is that you have a subversion repository checked out on a laptop (or some other computer) that you checked out at work using the ip address 192.168.0.10, and now you're at home and want to use it.
Personally I wouldn't try any fancy network reordering (or modifying the hosts file) but just use the SSH tunnel to check out a fresh copy of the repository on the machine again. So that you'll be checking the source out from the 127.0.0.1 address. Then if you need to move changes over you could use patches between the two checked out copies. Granted it's not the most ideal solution but it will get you going quickly without messing about too much.
Though a better solution would be to convince work to allow access to the repository (with proper passwords, authentication, SSL etc) using a nicer method, say apache with dav_svn/webdav.
If they don't go for that then try and get them to provide a VPN so that you can continue to work with the repository using the work IP address.
Why don't you just access svn via 127.0.0.1? Surely this would be a better solution?
You're faced with several issues here, if I understand correctly. There's only one way you can make this work, that is to have your home machine have an address of 192.168.0.10. Then, you specify the ssh local address with 192.168.0.10 instead of 127.0.0.1.
The remote ssh connection will also by 192.168.0.10.
E.g., ssh -l work_user -L 192.168.0.10:svn:192.168.0.10:svn work_ssh_host
This syntax is possible with OpenSSH.
This is all if I understand your situation correctly.
A more elegant solution is to use OpenVPN, and route connections over the VPN.
I think I have had the same situation before, I will have to find what the exact configuration though.
You can start by looking at PuTTY Portable, it supports SSH and you can "redirect" a local IP to a remote IP.
As far as I can remember, when you run PuTTY you can:
First specify you local address and port (this will be where you will be pointing your SVN client, e.g. Tortoise)
Then go to Connection->SSH->Tunnels-> specify your source port to redirect from (same as above), then specify the destination IP and port and click add
I think that should be it, it has been a while since I have done it.