Autossh Not Working

[TheHackerNextDoor]

I'm trying to set up AutoSSH on my new Pineapple. My ssh server is port forwarded, in fact I can see the pineapple attempts in the log file. I used the 'Transfer Public Key' button to put its key on the server. I am not sure why it is not connecting.

[THCMinister]

Maybe manually try putting the key on the box.

[TheHackerNextDoor]

Maybe manually try putting the key on the box.

Thank you. That helped, but I have a new problem. The remote server always listens on localhost, and I want it to listen on 0.0.0.0.

[THCMinister]

I'm confused as to what you are trying to accomplish. The remote server will listen on localhost(127.0.0.1, or the dhcp/static address assigned) and is you are trying to access it directly from outside the network it is listening on then you would need to setup port forwarding on the router. If you could explain what you want your end goal to be, we might be able to help better.

[TheHackerNextDoor]

I want to go Pineapple > Server > Server local network. The server accepts connections from 127.0.0.1, but not from its internal IP. If I use netstat, I can see that it is only listening on localhost.

[THCMinister]

Correct me if I'm wrong. You have the pineapple connected to the computer via Ethernet, the computer connected to the network via Ethernet. you are not able to SSH from the pineapple to the computer via the computers assigned address? On the computer you can SSH to itself via localhost(127.0.0.1) and not the other IP?

Are you trying to use an external facing IP?

I'm still a little confused as to why this is not working. Please provide IPs of the pineapple/server. Maybe something in you config could be the cause. Could you also post the config?(please use spoiler tags)

[madhak]

If I understand correctly you want to use the pineapple as a bridge to connect wirelessly to a wired server, is that correct?

You said "The server accepts connections from 127.0.0.1" you know this mean that only connection originating from that very same server will work, if you want to be able to connect remotly, from an other machine, then it need to listen to an interface other than localhost.

[TheHackerNextDoor]

If I understand correctly you want to use the pineapple as a bridge to connect wirelessly to a wired server, is that correct?

You said "The server accepts connections from 127.0.0.1" you know this mean that only connection originating from that very same server will work, if you want to be able to connect remotly, from an other machine, then it need to listen to an interface other than localhost.

The pineapple in on a firewalled network. The server is on my home network. I want to tunnel the pineapple to my home server, and I want to access it from my home computer.

[cooper]

Okay, so the goal then is to have a 2-way tunnel between the Pineapple and your Server (which actually means 2 tunnels, one for each direction). I'm assuming 'your server' is a machine on your home network, but not one directly connected to the internet. The machine that IS directly connected to the internet we'll call the Staging server in what comes next.

I think you need 2 client sessions for this.

The first is from the Pineapple to your Staging server. I'd go about doing that by having your Staging server provide a listening socket to ssh on port 443. Encrypted traffic is expected there so the network your Pineapple is on won't see very weird traffic, just maybe more of it. When you start your ssh client on the pineapple, tell it to tunnel connections on (pineapple) local port XYZ to remote Server port 22 (or wherever you have sshd listening on Server). This is tunnel 1. Using firewall rules on the Pineapple restrict local port XYZ to localhost only. Start something like "vmstat 20" to generate a small amount of traffic every 20 seconds to prevent the connection (and, thus, tunnel) from being closed due to inactivity.

Next, on the Pineapple, run an ssh client that connects to (pineapple) local port XYZ which first creates tunnel A which is from (pineapple) local port ABC to (Server)localhost port 22 (or wherever you have sshd listening on Server) and tunnel B which maps (Server) remote port DEF to (pineapple) localhost XYZ. Again, start something like "vmstat 20" to generate traffic on the line to prevent the closing of the tunnel due to inactivity.

With this setup in place, you can now connect to port ABC on the Pineapple to get to your home Server and on your home Server you connect to DEF to connect to your Pineapple.

You could do this without a Staging server when Server is connected directly to the internet, but then you'd have to seriously firewall the listening port on your Server to prevent unauthorized access across the full internet to the Pineapple at your undisclosed location.

Edited March 21, 2014 by Cooper

[cooper]

Oh, and PS: If the admin of the network finds your Pineapple, it gets crushed.

If he / she finds out it was you who put it there, you probably won't be allowed to access the premesis anymore.

Don't say you weren't warned...

[TheHackerNextDoor]

Okay, so the goal then is to have a 2-way tunnel between the Pineapple and your Server (which actually means 2 tunnels, one for each direction). I'm assuming 'your server' is a machine on your home network, but not one directly connected to the internet. The machine that IS directly connected to the internet we'll call the Staging server in what comes next.

I think you need 2 client sessions for this.

The first is from the Pineapple to your Staging server. I'd go about doing that by having your Staging server provide a listening socket to ssh on port 443. Encrypted traffic is expected there so the network your Pineapple is on won't see very weird traffic, just maybe more of it. When you start your ssh client on the pineapple, tell it to tunnel connections on (pineapple) local port XYZ to remote Server port 22 (or wherever you have sshd listening on Server). This is tunnel 1. Using firewall rules on the Pineapple restrict local port XYZ to localhost only. Start something like "vmstat 20" to generate a small amount of traffic every 20 seconds to prevent the connection (and, thus, tunnel) from being closed due to inactivity.

Next, on the Pineapple, run an ssh client that connects to (pineapple) local port XYZ which first creates tunnel A which is from (pineapple) local port ABC to (Server)localhost port 22 (or wherever you have sshd listening on Server) and tunnel B which maps (Server) remote port DEF to (pineapple) localhost XYZ. Again, start something like "vmstat 20" to generate traffic on the line to prevent the closing of the tunnel due to inactivity.

With this setup in place, you can now connect to port ABC on the Pineapple to get to your home Server and on your home Server you connect to DEF to connect to your Pineapple.

You could do this without a Staging server when Server is connected directly to the internet, but then you'd have to seriously firewall the listening port on your Server to prevent unauthorized access across the full internet to the Pineapple at your undisclosed location.

My home servers are directly connected to the internet. They are port forwarded.

[cooper]

Then doing only what's described for the second ssh client session will suffice. Just instead of connection that session to (pineapple) local port XYZ you connect to Server where I'd still recommend you port-forward external port 443 to whatever the sshd port on your Server is to disguise your traffic and in setting up that session include the parameters to create tunnels A and B as described.

[TheHackerNextDoor]

Then doing only what's described for the second ssh client session will suffice. Just instead of connection that session to (pineapple) local port XYZ you connect to Server where I'd still recommend you port-forward external port 443 to whatever the sshd port on your Server is to disguise your traffic and in setting up that session include the parameters to create tunnels A and B as described.

I'm going to restate my question.

Pineapple is on network A, firewalled.

SSH server is on network B, not firewalled (Example IP 192.168.1.123).

PC is on network B.

I can connect the pineapple to the ssh server, forwarding port 80 on the pineapple to port 5000 on the server. I can make a connection on 127.0.0.1:5000 (Tested with wget)

When I go on my PC, and I enter 192.168.1.123:5000 in google chrome, I get connection refused.

If I go back to the server and run netstat -a, and I see that it is only listening on 5000 on localhost.

In my /etc/ssh/sshd_config file, I have GatewayPorts = clientspecified .

Does this help?

[cooper]

Run the SSH client that creates the tunnel with '-g'.

[TheHackerNextDoor]

Run the SSH client that creates the tunnel with '-g'.

I forgot to mention I tried that.

[cooper]

In your -R parameter you're probably providing as values "5000:localhost:22". If so, try as -R value "*:5000:localhost:22" in which the asterisk is the bind address, defaults to localhost and with an asterisk in place it'll now be all interfaces (but you can specify it aswell if you wish - just use the Server's name of the interface).

And PS, this only works if on the Server your SSHD configuration has the GatewayPorts option set to enabled.

Edited March 21, 2014 by Cooper

[TheHackerNextDoor]

In your -R parameter you're probably providing as values "5000:localhost:22". If so, try as -R value "*:5000:localhost:22" in which the asterisk is the bind address, defaults to localhost and with an asterisk in place it'll now be all interfaces (but you can specify it aswell if you wish - just use the Server's name of the interface).

And PS, this only works if on the Server your SSHD configuration has the GatewayPorts option set to enabled.

Hold on, so GatewayPorts = enabled? I had tried GatewayPorts = clientspecified and GatewayPorts = yes, but neither worked. Should I try that?

[cooper]

Heh. I'm just reading the man page.

GatewayPorts
Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd(8) binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded
ports. GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be ``no'' to force remote port forwardings to be
available to the local host only, ``yes'' to force remote port forwardings to bind to the wildcard address, or ``clientspecified'' to allow the client to select the address to which the forwarding is bound. The default is ``no''.

Looks like "clientspecified" is the correct one. Try running sshd server-side with 1 to 3 instances of '-d' and see if that tells you anything. Note that in that setup sshd will not daemonize and will only service a single connection (assuming you already included a valid bind_address in the -R value).

Edited March 21, 2014 by Cooper

[TheHackerNextDoor]

No can do. The server is headless and the only way I can access it is via ssh. I do have access to the logs, however.

[cooper]

But then you probably already looked into them and didn't see anything particular there.

So, let's end the suspense. Are you or are you not specifying a bind_address to ssh in your -R parameter?

[TheHackerNextDoor]

But then you probably already looked into them and didn't see anything particular there.

So, let's end the suspense. Are you or are you not specifying a bind_address to ssh in your -R parameter?

Yes, I am specifying a bind_address.

[cooper]

Does it work any better when in the sshd options you set GatewayPorts to just "yes"?

Are you using Match entries in your sshd config and might you be focussing on the wrong section of the config file? Just thinking aloud, here.

[TheHackerNextDoor]

Here is /etc/ssh/sshd_config:

# Package generated configuration file

# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for

Port 22

# Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::

#ListenAddress 0.0.0.0

Protocol 2

# HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

HostKey /etc/ssh/ssh_host_ecdsa_key

#Privilege Separation is turned on for security

UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600

ServerKeyBits 768

# Logging

SyslogFacility AUTH

LogLevel INFO

# Authentication:

LoginGraceTime 120

PermitRootLogin yes

StrictModes yes

RSAAuthentication yes

PubkeyAuthentication yes

#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

# For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

# similar for protocol version 2

HostbasedAuthentication no

# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes

# Kerberos options

#KerberosAuthentication no

#KerberosGetAFSToken no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

X11Forwarding yes

X11DisplayOffset 10

PrintMotd no

PrintLastLog yes

TCPKeepAlive yes

#UseLogin no

#MaxStartups 10:30:60

#Banner /etc/issue.net

# Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication. Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

UsePAM yes

# SparkleShare

# Please do not edit the above comment as it's used as a check by Dazzle

Match User storage

PasswordAuthentication no

PubkeyAuthentication yes

# End of SparkleShare configuration

GatewayPorts clientspecified

[cooper]

For arguments sake, could you place GatewayPorts just above that "Match User storage" line and if that doesn't change anything also specify the (sanitized) ssh client command you're using.

[TheHackerNextDoor]

For arguments sake, could you place GatewayPorts just above that "Match User storage" line and if that doesn't change anything also specify the (sanitized) ssh client command you're using.

Wow. That was the problem... I'm so stupid! xD