How to use .pem key/certificate for AutoSSH into Amazon EC2 instance?

[fanbase]

I'm trying to configure AutoSSH to connect to my relay server, which happens to be an Ubuntu 12.04 instance hosted by Amazon's EC2 service. They use .pem certificates. I like them; they're easy. I don't have to mess around with public keys and private keys and Bob and Alice. Sadly, though, the MK5's web UI no longer allows me to specify the command line for AutoSSH, where it seems (at least in previous versions of the UI) I would have been able to replace the "-i /etc/dropbear/id_rsa" with "-i key.pem" and have it work all the same.

I followed all the instructions in episode 1112 and (the relevant parts of) Chris Haralson's tutorial. I hoped that doing so would obviate the need for the "-i key.pem" argument when autoSSHing with Amazon's EC2. It did not. When I try to test AutoSSH, it does not connect to the EC2 instance.

I need your help. As I see it, there are at least three avenues for solutions:

1) Change a config file in the pinapple's bowels to use an "-i key.pem" argument for AutoSSH (such as I have used successfully when setting up manual SSH sessions - no password required). I prefer this option, for what it's worth.

2) Make the EC2 instance accept whatever crypto the pineapple wants to serve it (what do we call it? an RSA key?). This is basically what I've tried to do so far, by following the instructions given in Darren and Chris's tutorials. It hasn't worked so far, but maybe there's more monkeying around in the server's "sshd_config" or "authorized_keys" that I can still do?

3) Convert Amazon's .pem key into an RSA (public?) key (or whatever it's called) format? Then maybe replacing the contents of the some key file deep in the pineapple's bowls with the output of the pem->rsa conversion? I am not sure this can actually be done; results of preliminary googling are all above my head.

Can you folks help me work this problem, walk me through steps for solving it?

Thanks in advance.

Edited March 28, 2014 by fanbase

[fanbase]

Solved.

[THCMinister]

It might be helpful to others if you post your solution.

[kevinfwb]

If you don't mind, please post your solution. I could certainly use it.

[fanbase]

My apologies for the delayed reply; after staying up all night to work the problem, I didn't have the heart for a write-up that same morning. My curt "solved" was meant only to save folks from devoting their energies toward my problem unnecessarily. (Hopefully, this detailed answer will cache some good karma, since my next post on VPN tunneling really will require some help!)

I had a few hurdles to overcome just to get the ssh connection going. The first and most obvious problem was that I was improperly writing the command for SSHing from my relay into my pineapple. I was specifying the Pineapple by its external IP, rather than "localhost."

The .pem key seemed not to be an issue at this step. Apparently, pasting the Pineapple's public key into the relay server's ".ssh/authorized_keys" file (both as ubuntu and root) does indeed work. More on that in a moment.

One important point I should make, however, is that the one-step command to connect from your terminal to Pineapple (such as Darren demonstrated in episode 1112.2) does not work in this setup. By which I mean this command:

root@kali:~# ssh -i <key>.pem ubuntu@<relay server IP> -p 4255

...just doesn't work in this setup. Don't know why. You have to do it in two steps. First, SSH from your terminal to the relay server:

root@kali:~# ssh -i <keyfile>.pem ubuntu@<relay server IP>

next, SSH from the EC2 relay to the Pineapple (as localhost)

ubuntu@<relay IP>:~$ ssh root@localhost -p 4255
root@localhost's password:

Success! You have your SSH tunnel!

Actually, though, there are a few things you need to do first to get there and beyond. Allow me to outline in more detail:

The real problem actually came when I tried to set up the web interface. To achieve this, I first modified the Pineapple's /etc/config/autossh file, appending the argument

&& ssh -f -N -R 6855:localhost:1471 -i <keyfile>.pem ubuntu@<relay server IP>'

to the final line of that file. Notice that for this step I used the .pem key, whereas the first part of the command (to set up the SSH connection) uses the "-i /etc/dropbear/id_rsa" argument. Different types of keys, but apparently it works.

Don't forget to close that modified argument with the single quotation mark (which was there in the first place). Otherwise, your Pineapple's insides get reformatted into a smoothie.

Just kidding. No idea if it's important.

And, of course, you need to scp the <key>.pem file to your Pineapple and chmod 400 it.

I also modified the Pineapple's /etc/config/uhttpd file, and disabled the RFC1918 checking option like so:

option rfc1918_filter 0

A post in a previous thread in the MK4 forums said this is necessary (not sure if this is confirmed).

Now for the changes that you have to make on the Amazon instance side:

First, you have to modify .ssh/authorized_keys.

sudo nano .ssh/authorized_keys

You're going to do two things to this file.

First, you're going to see some contents already there, consisting of a command and a key (the contents of your .pem file):

command="echo 'Please login as the ec2-user user rather than rootuser.';echo;sleep10"    ssh-rsa AAAAB3NzaC1yc2EA...

Delete everything before "ssh-rsa...". Everything after that is your .pem key; don't touch "ssh-rsa" or anything after it. Just start a new line.

Now paste your Pineapple's public key in there on the new line. CTRL + X, save.

For some reason, deleting that command from the authorized_keys file -- not just echoing in the Pineapple's key (as demonstrated by Darren and Chris) -- proved to be really important in making the web interface run remotely. My interpretation of the debug output from failed attempts is that maybe it has something to do with permissions for nesting SSH sessions? Even though I'm never actually logging into the relay as root. I really don't know.

Next, we need to monkey with sshd_config:

sudo -i
nano /etc/ssh/sshd_config

Make the following changes. If a line below isn't present your file, add it:

PermitRootLogin without-password
StrictModes no
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
UsePAM yes
AllowTcpForwarding yes
GatewayPorts yes
X11Forwarding yes

Save and exit. Now, restart ssh:

sudo /etc/init.d/ssh restart

Finally, fire up your browser and navigate over to your Amazon EC2 Management Console.

Make sure that your security group's rules allow the ports and protocols that you'll be using.

Also, on your instance's main page, there's a dropdown menu with an item labeled, "Destination Check/Source Check." Disable that. Not sure if it's critical, but it worked for me.

Now, the moment of truth: Let's test whether the tunnel for the web UI works by manually executing the command that starts it (on the pineapple->relay side).

To do this, SSH from your terminal to the relay server; then from the relay, SSH to the Pineapple. Once tunneled into your Pineapple, connect back into the relay by manually executing the command that fires up the tunnel for the web UI:

root@Pineapple:~# ssh -f -N -R 6855:localhost:1471 -i <keyfile>.pem  ubuntu@<relay server IP>
root@Pineapple:~# Warning: remote port forwarding failed for listen port 6855

Well that looks discouraging. But let's try dialing it up in a browser anyhow. Navigate to:

<relay server IP address>:6855

Success! You get the login page. Works from any computer, anywhere.

Lessons learned: Don't just echo when advised to echo in modifications. I learned of several sticking points by opening up each of the config files in nano, combing through them, and then confirming my changes when done.

What I'd like to learn to improve on this: 1) Set up a VPN tunnel for all traffic connected to the Pineapple in client mode, with the tunnel endpoint being my VPS, enabling more powerful MitM attacks like Metasploit; and 2) obfuscating the remote web UI as an i2p page.

If anyone has any thoughts on what I could have done better, please do let me know. I hope this helps somebody and saves them sleep!

Edited March 31, 2014 by fanbase

[kevinfwb]

Thanks for taking the time to write this up. It's very much appreciated.

[fringes]

FWIW and if it helps anyone, the last line of my /etc/config/autossh is similar to:

option ssh '-i /root/.ssh/id_rsa -N -T -R 1471:localhost:1471 -R 222:localhost:22 <someuser>@<somedomain> -p 22'

The autossh infusion doesn't like it (yet), but that gives me both the web interface and SSH forwarded over a single persistent SSH connection whenever the pineapple boots (if it's set up to connect to the internet).

Since my relay servers' firewall only forwards SSH to the Internet, I use SSH (or Putty) to connect myself (laptop) to the relay and forward those ports back to me. So -R from the pineapple to the relay, and -L from my laptop to the relay puts both services from the pineapple to localhost on my laptop. Since I use session chaining for the SSH connections, I don't actually need to port forward the SSH from the laptop. Either way, both services (HTTP & SSH) are over SSH end-to-end.

Edited April 23, 2014 by fringes