The github instructions say to setup your SSH keys in ~/.ssh using the windows git bash program.
I have in the past used Putty to manage ssh keys.
What is the difference between the 2 setups?
This is for my own git server.
I know this is a pretty old question, but here's the answer:
Basically, PuTTY stores all its sessions in the Windows registry, rather than in a config file in a home folder, whereas the default git+ssh setup uses openSSH and it's style of key configuration (files that are typically stored in ~/.ssh, i.e., /home/<username>/.ssh).
In Windows, if you'd rather use PuTTY than openSSH, set an environment variable named GIT_SSH to C:\your\putty\folder\plink.exe. Then, you can reference any saved session in PuTTY by using a remote url of the form ssh://<session name>/<repository path>. This allows you to, for example, specify particular keys with each session, similarly to how you could use ~/.ssh/config to specify a particular key with the IdentityFile option.
Git uses an SSH program to deal with SSH accesses, basically the default one depending on your system (look at the GIT_SSH environment variable). So it's just to ease the configuration that they say to setup SSH keys in ~/.ssh. If you want to put SSH keys in another directory, just tell it by using ssh-add /path/to/your/key.
Related
So, I followed this to configure my SSH -Setting up SSH keys for Bitbucket on Windows- and it works as expected.
For a reason out of knowledge, control and understanding.... The %HOMEDRIVE% on my computer is set to Q (a network drive), resulting on GIT storing and looking for my ssh keys on Q:\Users\MyUser\.ssh.
I can tell git to create the keys on C:\Users\MyUser\.ssh (or just copy them from Q to C). But when I want to do a git pull, git looks for my keys on Q instead of C, and obviously fails to connect.
Any idea on how to tell git to always look for SSH keys and configurations on a specific folder?
Thanks,
R.
p.d. My %HOMEPATH% is propperly configured... if i could at least tell git to use the %HOMEPATH% instead of %HOMEDRIVE%... that could probably be a fix too.
--UPDATE--
I created a config file, that redirects ssh.exe from Q to C
Host MyHost
HostName MyIP
Port MyPort
StrictHostKeyChecking no
UserKnownHostsFile /C/Users/MyUser/.ssh/known_hosts
IdentityFile /C/Users/MyUser/.ssh/id_rsa
So, being able to specify a location for the config file would also help.
So far I solved my issue (in a way i don't really like)... But my solution doesn't answer my question.
I added a variable to my user variables called HOME and set it to C:\Users\MyUser.
Basically what rolyat suggested in this thread change-the-default-location-for-git-bash
I don't know the reason why my organization configures %HOMEDRIVE% to Q and I don't know if my variable will later affect me accessing network resources or receiving windows updates from my organization...
At least this way i am not dependent on the network drive anymore.
I recently reinstalled Windows on my PC. However the new SSH location on my PC is different because the username is different. When I try to sync git, it still looks for the previous ssh location.
My question is simply why is it looking for the previous location?
EDIT
I forgot to mention that I copied all my repositories and .ssh folder over.
Git will always look by default for ssh keys in %USERPROFILE%\.ssh\id_rsa(.pub).
Warning, with Git 2.19+, you need to add the -m PEM option to ssh-keygen:
ssh-keygen -t rsa -m PEM -P ""
The only way Git would look elsewhere is if you have restored your %USERPROFILE%\.ssh\config file, in which you could have set a specific path for a private key.
all it's looking for is the private key. since you reinstalled Windows, you would have lost you previous key. only option you have is to generate a new key and configure it's corresponding public key on git again.
P.S: you are incorrect in assuming that it's due to change in location or that git's even looking for your key at a certain location.
I normally use Linux and everything goes very well. :-)
But I have a machine which runs with Windows 7. :-\
When I try to connect to a server using Git Bash I receive following message:
The authenticity of host '144.76.35.106 (144.76.35.106)' can't be established.
ECDSA key fingerprint is 50:50:10:f7:40:50:b8:3a:20:c5:20:20:00:a0:d8:70.
Are you sure you want to continue connecting (yes/no)?
Normally I should only type yes and hit enter. But we are talking about Windows... ;-)
The problem is that in this special case the folder ~/.ssh is not writeable and I'm unable to change rights. (Why is that so is related to the security philosophy of the company. Unfortunately I have no influence here).
So I would like to know if there's any chance to change this: So when I type yes and hit enter the file known_hosts is saved in another place and most important, that the file is read next time when I access the server once again.
In other words: Where can I configure that Git look for known_hosts in another place than ~/.ssh using Windows?
Many thanks in advance!!!
The problem is that in this special case the folder ~/.ssh is not writeable and I'm unable to change rights.
Here is simply the value referenced by the environment variable HOME.
Check its value with echo $HOME in your bash session.
HOME should be set by default to %USERPROFILE%, but you can set it to any other folder of your choice, where you know you have the right to write.
I've got a Lacie Network Space 2 where they have disabled the SSH access and I'd like to write a script where I transfer files from my computer to the NS2 using scp.
The only problem I have is that I can't (from what I know) generate a public key without first connecting via SSH.
So my question is: Is it possible to generate a key without having access to SSH, for use with scp? Or some other clever way to transfer files to my NS2 (FW 2.2.4) using a script.
I might add that I'm currently mounting the disk and using cp, but I'd like something better.
Thanks in advance!
What exactly do you want? If you want to scp to the NS2, you'll have to generate the keys on the source machines and append it to authorized_keys on the target. Since you can already mount & use cp, you should be able to do that.
Note that since scp works over ssh, if they've disabled ssh this won't work. OTOH, if they've only disabled password based ssh, or set /bin/false as your shell, this might work.
I have concluded that if you want to gain access to ssh keys on your NS2 with a newer FW you have to remove the disk from its casing and connect it to a computer, as they explain in this link
Enabling SSH on NS2
I thank you both for your answers, but I guess I'll have to do it the hard way.
I have a desktop in the office that I often need to access from home and use scp to copy files. Currently I am doing it like this
scp username#x.x.x.x ...
I want a mechanism that I dont have to type the IP address each time I want to scp something. I was trying to do it by creating an alias, but it doesn't seem to work.
Can I give my desktop machine a name so that instead of typing the ip address I can use the name of the machine instead ?
One way to deal with this is to create an entry in your ssh configuration. This can be done on a system wide basis or, if you don't have root access on this box, just for your user.
The per user configuration file is ~/.ssh/config and uses the following format
host my_desktop
hostname 11.22.33.44
This method is also nice because you can specify other options like the user name. To find out more about the options available try man ssh_config.
You should have a HOSTS file on your system that's designed to do exactly that. On my Linux system, it's located at /etc/hosts. If you add a line that looks like this:
11.22.33.44 my_desktop
then all accesses to the name my_desktop will be mapped to the IP address listed. This change only affects the machine whose HOSTS file was modified, though. If you want to make it so that anybody can access an IP using a specific name, then you're looking at something a little more difficult (this is the general problem that DNS servers were designed to resolve).
Use a environment variable to hold your IP and username - then use the variable in the scp command.
user#crunchbang:~$ export mypc='myuser#x.x.x.x'
user#crunchbang:~$ scp $mypc: ......