0

Have 3 servers: Local, Bare, Development.

The following workflow works perfectly:

1. Make my local changes 
2. git push to Bare 
3. ssh into Bare 
4. $ ssh ip.of.Development.server "cd /path/to/Development/repo; git pull"

This does exactly what you would expect, content gets pulled to my Development server, displays on the page, all is well.

However, if I move the last line to my hooks/post-receive file on Bare, I get a

remote: Host key verification failed.

I can ssh from Development to Bare without issue and without using a password (after I set up an RSA pair).

Even if I cut the post-receive hook down to just

ssh ip.of.Development.server

I get the same error, but if I enter this exact same line on the command line, it works fine.

  • 3
    What user does the hook run under? Has the keypair been installed in the ~/.ssh folder for that user? Has the devel server been added to that user's known_hosts file? Can you pipe the stdout and stderr of the hook to a file? – jimbobmcgee Jan 14 '13 at 22:32
  • I'm not sure how to check what the hook runs under. I first assumed root, but that wouldn't make much sense, so now I'm thinking it runs under gitdaemon, whereas I installed the keypair for root and added the devel server for root as well. – Nick Brown Jan 14 '13 at 22:58
  • 1
    You might be able to supply a common private key with (I think) -i and possibly bypass known_host checks with a -o option (I think you have to tell it the fingerprint to expect). I'd get the script output piping out to a file, first, e.g. >> /var/log/post-receive 2>&1 to make sure it is definitely this issue? – jimbobmcgee Jan 14 '13 at 23:09
  • 2
    Also, I don't know much about git, but if it works at all like Subversion and you are tunnelling your access to bare over SSH (in Subversion, it would be by using the svn+ssh://server/path URL) the process is probably run under bare's authenticating SSH user (in Subversion, svnserve will be started by the authenticating SSH user, which will do the commit and run the hooks). – jimbobmcgee Jan 14 '13 at 23:12
  • You were correct, it was running under the wrong user. I performed an 'echo $USER' in the post-hook script to nail it down. Thanks for the assistance. – Nick Brown Jan 15 '13 at 22:57
1

Inside the "bare" server you should edit the ~/.ssh/known_hosts file of the user that's running the hook.

Example of a line of ~/.ssh/known_hosts:

192.168.1.9 ssh-rsa AAAB3NzaC1yc2EAAAADAQABAAABAQDM5bg362+EqiRioaVO5f7L7a4NK94yHI6HXQCdge7WvmN9AFVhruXs31JUooxTD0tMe3nE0zDIt9fBcoIXNYjd2auCrRdT/2kvNg12aqhJpoxKeArekjQ10xmyjkDGQr6DUTzW7TOX55aucDbftO1chQ6+wG7mpvkE6N0J9HsQvJrjb3LO9JlEDCYFp2sSx3OxvCl33pEMk7zVhHftqP8hmZnQF8Y2/dO/nK/UawJVOVzyvImzvOhBFqKYgVIKajtjH/yodf9R1tOALqP9QQVBA9zJOLhc4q6Rcj3QVb+o6mv3Zl5QudZP6ATcFeKZPzEEUrqHbeQiZ2Ce72AUtD+7

You should remove the line that identifies the server that you're trying to connect to and then, BEFORE launching again your script, do a "ssh user@destination" with your user so that the destination server's host key to your known_hosts file. Like this:

localhost% ssh user@destination The authenticity of host 'destination (10.0.0.1)' can't be established. RSA key fingerprint is 51:a4:73:ef:6d:b6:40:c1:a2:1f:ba:33:a0:64:c0:f8. Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'destination' (RSA) to the list of known hosts.

0

The answer by Pablo Montepagano is correct-- but it is very specific and doesn't necessarily go into the why or some peripheral understanding.

Find that in a different answer here: https://serverfault.com/questions/132970/can-i-automatically-add-a-new-host-to-known-hosts/807363#807363

(I hate when people mark things as duplicate-- this is NOT a duplicate question, but the answer linked applies to many things based on SSH.)

-----------------Heard link only answers were frowned upon, self moderating-------------

So, I was searching for a mundane way to bypass the unkown host manual interaction of cloning a git repo as shown below:

brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?

Note the RSA key fingerprint...

So, this is a SSH thing, this will work for git over SSH and just SSH related things in general...

brad@computer:~$ nmap bitbucket.org --script ssh-hostkey

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_  2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds

First, install nmap on your daily driver. nmap is highly helpful for certain things, like detecting open ports and this-- manually verifying SSH fingerprints. But, back to what we are doing.

Good. I'm either compromised at the multiple places and machines I've checked it-- or the more plausible explanation of everything being hunky dory is what is happening.

That 'fingerprint' is just a string shortened with a one way algorithm for our human convenience at the risk of more than one string resolving into the same fingerprint. It happens, they are called collisions.

Regardless, back to the original string which we can see in context below.

brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg

So, ahead of time, we have a way of asking for a form of identification from the original host.

At this point we manually are as vulnerable as automatically-- the strings match, we have the base data that creates the fingerprint, and we could ask for that base data (preventing collisions) in the future.

Now to use that string in a way that prevents asking about a hosts authenticity...

The known_hosts file in this case does not use plaintext entries. You'll know hashed entries when you see them, they look like hashes with random characters instead of xyz.com or 123.45.67.89.

brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==

The first comment line infuriatingly shows up-- but you can get rid of it with a simple redirect via the ">" or ">>" convention.

As I've done my best to obtain untainted data to be used to identify a "host" and trust, I will add this identification to my known_hosts file in my ~/.ssh directory. Since it will now be identified as a known host, I will not get the prompt mentioned above when you were a youngster.

Thanks for sticking with me, here you go. I'm adding the bitbucket RSA key so that I can interact with my git repositories there in a non-interactive way as part of a CI workflow, but whatever you do what you want.

#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

So, that's how you stay a virgin for today. You can do the same with github by following similar directions on your own time.

I saw so many stack overflow posts telling you to programmatically add the key blindly without any kind of checking. The more you check the key from different machines on different networks, the more trust you can have that the host is the one it says it is-- and that is the best you can hope from this layer of security.

WRONG ssh -oStrictHostKeyChecking=no hostname [command]

WRONG ssh-keyscan -t rsa -H hostname >> ~/.ssh/known_hosts

Don't do either of the above things, please. You're given the opportunity to increase your chances of avoiding someone eavesdropping on your data transfers via a man in the middle attack-- take that opportunity. The difference is literally verifying that the RSA key you have is the one of the bona fide server and now you know how to get that information to compare them so you can trust the connection. Just remember more comparisons from different computers & networks will usually increase your ability to trust the connection.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.