[guardian-dev] a pathetic ssh question

[Lee Azzarello]

I like your echo chamber thread. I've encountered this before. The default
ssh-agent config for max identities is 5.

-lee

On Wednesday, November 5, 2014, Harlo Holmes <harlo at guardianproject.info>
wrote:

> ok, -o IdentitiesOnly=yes. back in business.
>
> ++++++++++++++++++++++++++
> Research Fellow, Head of Metadata
> The Guardian Project <https://guardianproject.info>
>
> pgp: 0x0A0F0B18
> twitter: @harlo
>
> On Wed, Nov 5, 2014 at 11:16 AM, Harlo Holmes <harlo at guardianproject.info
> <javascript:_e(%7B%7D,'cvml','harlo at guardianproject.info');>> wrote:
>
>> 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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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/ea4e989b/attachment.html>