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.
Related
I am working recently on building Hadoop environment on windows7 OS. However, I got stuck in SSH configuration which blocks all the remaining work for Hadoop. I believe it's nothing to do with Hadoop, so any one familiar with SSH can do me a great favor.
Here's the thing, I'm trying to install SSH service for two computers so that any one can communicate with the other. I have successfully installed SSH for my PC, which is win7-x64, through cygwin. However, when I repeated it on the other computer, which is a server with win7-x86, SSH server failed, while the client can work, I get totally confused.
For my PC, I installed cygwin to use SSH service. ssh localhost works fine. And after generating ssh keys and appending it to authorized_keys, I managed to log in to my PC without password.
I copied the cygwin folder from my PC to the server, which is not connected to the Internet thus cygwin can't be directly installed on it. ssh localhost turned out okay at the first. But when I attemptted to log in without password by generating ssh keys and appending to authorized_keys, I got
Connection to localhost closed by remote host
Connection to localhost closed.
What's more, I copied the public key of the server to my PC and appended to authorized_keys file. I managed to log in to PC from the server without password.
On the other hand, the SSH connection from PC to server failed no matter whether with or without password. I got the same failure:
Connection closed by 192.168.0.52
where 192.168.0.52 is the ip address of the server.
What makes me more confused is when I connected to server from PC using putty rather than ssh command, I could log in to the server, with password.
In conclusion, I hope it would make the question more clearer with this graph:
ssh connection graph
I hope any one can help me to figure out what's wrong and how to fix it. Thanks a lot!
After trying for several centries, I finally found what's happening. When I built sshd service on the server, I didn't create a privileged account('cyg_server' by default), which I did on my PC but I forgot. Instead, I used current account for logging. Yet, the account , even the administrator, on windows doesn't have all the authorities as root on Linux does. Considering that, Cygwin considerately creates a privileged account named 'cyg_server', we just leave it and log in using current account. Everything is okay!
Again, f**k windows(So why would I have to do that on windows. Well, if I could, I would)
I have created an instance on Google Compute Engine, but I can't seem to SSH using the terminal. The command that I used was :
gcloud compute ssh example-instance
The error that I got was:
ERROR: (gcloud.compute.ssh) Could not SSH to the instance. It is possible that your SSH key has not propagated to the instance yet. Try running this command again. If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.
When I googled the error, I was led to this link:Unable to SSH to Google Cloud
I went and checked the firewall rules here https://cloud.google.com/compute/docs/troubleshooting#ssherrors and things seem fine. I also went onto ~/.ssh and checked for google_compute_engine and google_compute_engine.pub which indicate the presence of my private and public key. I was wondering what I should do next? Is this is a problem specific to Mac workstations?
Any help would be really appreciated.
Personally, had some trouble getting my ssh keys setup correctly by following the Google Cloud Engine docs. Found another logical solution...
This didn't take long and solved the problem (i.e., simple ssh access to Google Cloud VM via MacOS Terminal)...
Follow these simple instructions provided by nixCraft:
https://www.cyberciti.biz/faq/google-cloud-compute-engin-ssh-into-an-instance-from-linux-unix-appleosx/
Here are a few other things to check:
Can you ssh into that instance from a browser, using the "SSH" button in the Cloud Console?
If not, try a newly created instance using default settings and compare how your example-instance differs.
Run gcloud config list and confirm that the values for project, account, region, and zone match your expectations.
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'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
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.