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 <[email protected]> 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 <[email protected]> > 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@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@ash-vb:~$ ssh -i j3m_info/unveillance_proxy_NEW.pem >> [email protected] -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 [email protected] >> 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@VIDEOClash* >> debug1: Authentications that can continue: publickey >> debug1: Offering RSA public key: [email protected] >> debug1: Authentications that can continue: publickey >> debug1: Offering RSA public key: videoclash@VIDEOClash >> debug1: Authentications that can continue: publickey >> debug1: Offering RSA public key: videoclash@VIDEOClash >> debug1: Authentications that can continue: publickey >> debug1: Offering RSA public key: videoclash@VIDEO >> debug1: Authentications that can continue: publickey >> debug1: Offering RSA public key: videoclash@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 >> >> >
_______________________________________________ Guardian-dev mailing list Post: [email protected] List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: [email protected] Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: [email protected]
