I'm trying to set up an ssh connection from an OS X box provided by Travis CI to git-over-ssh at github.com.

Nothing fancy: my script takes a base64-encoded passwordless private key, decodes it and setups up the following git ssh wrapper to enforce key usage:


# Setting up bot key
echo "$BOT_SSH_KEY" | base64 --decode >$HOME/bot_id
chmod 600 $HOME/bot_id

# Setting up ssh wrapper
cat >$HOME/git-ssh <<__EOF__
#!/bin/sh -efx
ssh -vv -i "$HOME/bot_id" "\$@"
chmod a+x $HOME/git-ssh
export GIT_SSH="$HOME/git-ssh"

Then it tries to do ssh-authenticated git clone, which, according to the logs, results in ssh client being called. The very same script works on Ubuntu Linux instances provided by Travis and fails on OS X instances:

Analyzing the logs, they both look very similar, expect for:

  • Ubuntu uses OpenSSH_6.6.1, OS X uses OpenSSH_6.9p1 => kex_parse_kexinit lists slightly different set of ciphers available
  • Ubuntu uses /home/travis/bot_id, OS X uses /Users/travis/bot_id
  • OS X issues extra warnings for not being able to see the public part of the key (probably not a big deal):

    debug1: key_load_public: No such file or directory
  • Ubuntu suceeds after:

    debug1: Server host key: RSA 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
    debug1: Host 'github.com' is known and matches the RSA host key.
    debug1: Found key in /home/travis/.ssh/known_hosts:2
    Warning: Permanently added the RSA host key for IP address '' to the list of known hosts.
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home/travis/bot_id ((nil)), explicit
    debug1: Authentications that can continue: publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/travis/bot_id
    debug1: key_parse_private2: missing begin marker
    debug1: read PEM private key done: type RSA
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentication succeeded (publickey).
    Authenticated to github.com ([]:22).
  • OS X fails with:

    debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
    debug1: read_passphrase: can't open /dev/tty: Device not configured
    debug1: permanently_drop_suid: 501
    ssh_askpass: exec(/usr/X11R6/bin/ssh-askpass): No such file or directory
    Host key verification failed.
    fatal: Could not read from remote repository.
    Please make sure you have the correct access rights
    and the repository exists.

As far as I understand, ssh client should at the very least (1) connect, (2) verify server's keys and identity, (3) start trying various auth methods. From what I see, OS X gets the connection, but then does not even try to do any verifications (or complain about RSA checks failed, or whatever), but somehow bypasses all pre-set auth methods (i.e. passwordless key) and directly proceeds to "ask authentication information interactively" method => and then fails, as it's obviously disabled, as CI is not an interactive server.

Any ideas what's wrong with OS X ssh and how to get it to work, or at least add some debug? As my guesses go, probably it somehow silently fails on server's identity check, but I have no idea how to debug that (especially given that I don't have any OS X boxes handy to try it interactively).

  • I don't think it's dropping down to interactive password authentication, because that would involve debug1: Next authentication method: password. My blind guess is the client thinks the key isn't passwordless and wants the passphrase, or confirmation to use the key at all. Sep 14 '17 at 11:50
  • Have you considered having base64 --decode output the decoded key into ~/.ssh? ssh is fairly picky about permissions, not only of the file itself, but of the containing directory. /var/log/secure may tell you more.
    – user2267
    Sep 14 '17 at 15:47
  • @UlrichSchwarz The very same key works on Ubuntu. I've figured it out, it was actually due to known_hosts filled differently on different systems — see my answer.
    – GreyCat
    Sep 14 '17 at 16:13
  • @barrycarter Typically, that kind of things is clearly visible with ssh -vv. /var/log/secure — you mean on a recepient server? It's github.com, I can't access it there. Anyway, I've figured it out, see the answer.
    – GreyCat
    Sep 14 '17 at 16:16
  • @GreyCat I meant on your own server (the remote server wouldn't know your directory perms), but 1) you're correct, "ssh -vv" (or -vvv or whatever) may shows this. Glad you figured it out.
    – user2267
    Sep 14 '17 at 16:17

It turned out that indeed the problem was in the contents of .ssh/known_hosts file. Travis's ssh uses pretty much default options, so it would try to ask for confirmation on every new key, which, in turn, will result in this obscure error message.

On Ubuntu, Travis team supplies a preset .ssh/known_hosts file, which contains 5 lines with popular github keys:

github.com, ssh-dss AAAAB3NzaC1kc3MAAACBANGFW2P9xlGU3zWrymJgI/lKo//ZW2WfVtmbsUZJ5uyKArtlQOT2+WRhcg4979aFxgKdcsqAYW3/LS1T2km3jYW/vr4Uzn+dXWODVk5VlUiZ1HFOHf6s6ITcZvjvdbp6ZbpM+DuJT7Bw+h5Fx8Qt8I16oCZYmAPJRtu46o9C2zk1AAAAFQC4gdFGcSbp5Gr0Wd5Ay/jtcldMewAAAIATTgn4sY4Nem/FQE+XJlyUQptPWMem5fwOcWtSXiTKaaN0lkk2p2snz+EJvAGXGq9dTSWHyLJSM2W6ZdQDqWJ1k+cL8CARAqL+UMwF84CR0m3hj+wtVGD/J4G5kW2DBAf4/bqzP4469lT+dF2FRQ2L9JKXrCWcnhMtJUvua8dvnwAAAIB6C4nQfAA7x8oLta6tT+oCk2WQcydNsyugE8vLrHlogoWEicla6cWPk7oXSspbzUcfkjN3Qa6e74PhRkc7JdSdAlFzU3m7LMkXo1MHgkqNX8glxWNVqBSc0YRdbFdTkL0C6gtpklilhvuHQCdbgB3LBAikcRkDp+FCVkUgPC/7Rw==
github.com, ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
gist.github.com, ssh-dss AAAAB3NzaC1kc3MAAACBANGFW2P9xlGU3zWrymJgI/lKo//ZW2WfVtmbsUZJ5uyKArtlQOT2+WRhcg4979aFxgKdcsqAYW3/LS1T2km3jYW/vr4Uzn+dXWODVk5VlUiZ1HFOHf6s6ITcZvjvdbp6ZbpM+DuJT7Bw+h5Fx8Qt8I16oCZYmAPJRtu46o9C2zk1AAAAFQC4gdFGcSbp5Gr0Wd5Ay/jtcldMewAAAIATTgn4sY4Nem/FQE+XJlyUQptPWMem5fwOcWtSXiTKaaN0lkk2p2snz+EJvAGXGq9dTSWHyLJSM2W6ZdQDqWJ1k+cL8CARAqL+UMwF84CR0m3hj+wtVGD/J4G5kW2DBAf4/bqzP4469lT+dF2FRQ2L9JKXrCWcnhMtJUvua8dvnwAAAIB6C4nQfAA7x8oLta6tT+oCk2WQcydNsyugE8vLrHlogoWEicla6cWPk7oXSspbzUcfkjN3Qa6e74PhRkc7JdSdAlFzU3m7LMkXo1MHgkqNX8glxWNVqBSc0YRdbFdTkL0C6gtpklilhvuHQCdbgB3LBAikcRkDp+FCVkUgPC/7Rw==
gist.github.com, ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
ssh.github.com, ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==

However, on OS X, this file doesn't exist, which triggers an error. This simplest solution is to just precreate the file with lines like this on OS X from a shell script.

I've raise an issue with Travis team for this one.

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.