[guardian-dev] a pathetic ssh question

Harlo Holmes harlo at guardianproject.info
Wed Nov 5 11:16:59 EST 2014


upon further investigation (with the tripple-v output) i see the difference
is that on my host machine, ssh is attempts to try several (wrong) keys
before finally trying my correct key.  the correct key is marked as
"explicit" but there are too many authentication failures before the
correct one can be tried, and the server closes connection.

that seems really dumb, though, because why would ssh try all these keys
before getting to the one i've specified?

++++++++++++++++++++++++++
Research Fellow, Head of Metadata
The Guardian Project <https://guardianproject.info>

pgp: 0x0A0F0B18
twitter: @harlo

On Wed, Nov 5, 2014 at 10:39 AM, Harlo Holmes <harlo at guardianproject.info>
wrote:

> Hi,
>
> Having a problem.  It seems so pathetic to me, I'm slightly embarrassed to
> ask it.  But here goes...
>
> As of yesterday, I've had trouble ssh-ing into some amazon instances.  I
> have an alias on my host machine that does this:
>
> ssh -i /path/to/private/key user at host
>
> This has always worked, as it should.  The private key has not changed;
> not one thing has changed.  But it stopped working.
>
> At first, I freaked out, thinking someone accessed my instance, and wiped
> out the contents of ~/.ssh/authorized_keys, and that scared me.  But turns
> out, that's not the case.  On a virtual machine, i am able to ssh into the
> instance fine using the same command.
>
> Here's the output of that command with the debug flag on my virtual
> machine (which succeeded):
>
> ash-vb at ash-vb:~$ ssh -i j3m_info/unveillance_proxy_NEW.pem
> ubuntu at ec2-54-224-53-141.compute-1.amazonaws.com -v
> OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
> debug1: Reading configuration data /home/ash-vb/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: Connecting to ec2-54-224-53-141.compute-1.amazonaws.com
> [54.224.53.141] port 22.
> debug1: Connection established.
> debug1: identity file j3m_info/unveillance_proxy_NEW.pem type -1
> debug1: identity file j3m_info/unveillance_proxy_NEW.pem-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1
> Debian-5ubuntu1.4
> debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5* compat
> 0x0c000000
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-ctr hmac-md5 none
> debug1: kex: client->server aes128-ctr hmac-md5 none
> debug1: sending SSH2_MSG_KEX_ECDH_INIT
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ECDSA
> 97:4e:ff:55:c4:19:7e:23:2d:0d:c4:4d:59:17:3f:44
> debug1: Host 'ec2-54-224-53-141.compute-1.amazonaws.com' is known and
> matches the ECDSA host key.
> debug1: Found key in /home/ash-vb/.ssh/known_hosts:9
> debug1: ssh_ecdsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: Roaming not allowed by server
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey
> debug1: Next authentication method: publickey
> *debug1: Trying private key: j3m_info/unveillance_proxy_NEW.pem*
> debug1: key_parse_private2: missing begin marker
> debug1: read PEM private key done: type RSA
> debug1: Authentication succeeded (publickey).
> Authenticated to ec2-54-224-53-141.compute-1.amazonaws.com
> ([54.224.53.141]:22).
> debug1: channel 0: new [client-session]
> debug1: Requesting no-more-sessions at openssh.com
> debug1: Entering interactive session.
> debug1: Sending environment.
> debug1: Sending env LANG = en_US.UTF-8
> Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-54-virtual x86_64)
>
> and here's the output on my host (which fails now):
>
> ~ $ ssh ec2-54-224-53-141.compute-1.amazonaws.com -vOpenSSH_6.6.1,
> OpenSSL 1.0.1f 6 Jan 2014
> debug1: Reading configuration data /home/videoclash/.ssh/config
> debug1: /home/videoclash/.ssh/config line 5: Applying options for
> ec2-54-224-53-141.compute-1.amazonaws.com
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: Connecting to ec2-54-224-53-141.compute-1.amazonaws.com
> [54.224.53.141] port 22.
> debug1: Connection established.
> debug1: identity file
> /media/videoclash/video_one/keybase/ec2/unveillance_proxy_NEW.pem type -1
> debug1: identity file
> /media/videoclash/video_one/keybase/ec2/unveillance_proxy_NEW.pem-cert type
> -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1
> Debian-5ubuntu1.4
> debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH_5* compat
> 0x0c000000
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-ctr hmac-md5 none
> debug1: kex: client->server aes128-ctr hmac-md5 none
> debug1: sending SSH2_MSG_KEX_ECDH_INIT
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ECDSA
> 97:4e:ff:55:c4:19:7e:23:2d:0d:c4:4d:59:17:3f:44
> debug1: Host 'ec2-54-224-53-141.compute-1.amazonaws.com' is known and
> matches the ECDSA host key.
> debug1: Found key in /home/videoclash/.ssh/known_hosts:28
> debug1: ssh_ecdsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: Roaming not allowed by server
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey
> debug1: Next authentication method: publickey
> *debug1: Offering RSA public key: videoclash at VIDEOClash*
> debug1: Authentications that can continue: publickey
> debug1: Offering RSA public key: harlo.holmes at gmail.com
> debug1: Authentications that can continue: publickey
> debug1: Offering RSA public key: videoclash at VIDEOClash
> debug1: Authentications that can continue: publickey
> debug1: Offering RSA public key: videoclash at VIDEOClash
> debug1: Authentications that can continue: publickey
> debug1: Offering RSA public key: videoclash at VIDEO
> debug1: Authentications that can continue: publickey
> debug1: Offering RSA public key: videoclash at VIDEOClash
> Received disconnect from 54.224.53.141: 2: Too many authentication
> failures for ubuntu
>
> From the logs (which i've set in bold), it appears that ssh is absolutely
> ignoring the keyfile, even though i've explicitly set the -i flag.  I also
> modified my ~/.ssh/config file to set it there, but that does not work
> either.
>
> So, why is my host machine's ssh not honoring the -i flag, or any
> IdentityFile directive?
>
> ++++++++++++++++++++++++++
> Research Fellow, Head of Metadata
> The Guardian Project <https://guardianproject.info>
>
> pgp: 0x0A0F0B18
> twitter: @harlo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20141105/6cca8e56/attachment-0001.html>


More information about the Guardian-dev mailing list