2

Semi-newbie, so flame-throwers to 'singe only' please. ;-)

I have machine A at work, which I'd like to SSH into from a machine at home (call it machine B) -- machine A is behind our corporate firewall, which has only port 22 and port 80 open. On the machine A side of things, I want to change the port for SSH on machine A from 22 to (say) 2200, to minimize the number of script kiddies hammering away on port 22 (I have other SSH hardening policies in place, but would like to add moving the default SSH port from 22 to (say) 2200. This is easy enough within the SSHD config, but doing so kills anything inbound since port 2200 is blocked at the edge.

So, some sort of forwarding/tunnelling option. I've tried a few permutations on both the machine A and machine B side, but haven't found the magic combination. I was hoping one of the more learned types on this forum could advise:

1\ what do I need to set up for forwarding/port config on machine A?

2\ in terms of establishing the tunnel from machine B, what is the basic SSH command structure I need to try?

Apologies in advance for the extremely 'basic' level of the questions (and, if they've been answered before, apologies again, because what answers I could find weren't entirely accessible to someone at my level).

Many thanks in advance.

Johnny Canuck
  • 141
  • 1
  • 2

4 Answers4

4

Your corporate firewall only permits ports 22 and 80...so you can only run services on ports 22 and 80. If you want to establish port forwarding over ssh to access otherwise inaccessible ports, you first need to connect to the remote host, which you can't do unless you're able to traverse the corporate firewall.

In other words, you're going to have to leave ssh running on port 22. Your best bet, if you're worried about those ever industrious script kiddies, is to simply disable password authentication and always use ssh keys. This will render the system largely invulnerable to password-based brute-force attacks. It obviously doesn't help if someone were to discover some sort of ssh vulnerability that could be exploited pre-authentication, but it's probably the best you're going to get in your situation.

larsks
  • 43,623
  • 14
  • 121
  • 180
  • The only other option would be if there is another server running SSH on that network which you could then use SSH forwarding to tunnel your connection through that to the other server running on port 2200. – Jon Reeves Jan 18 '11 at 21:53
  • I was just typing something along those lines. Don't worry about script kids and make your own life easier in the process. – Alex Holst Jan 18 '11 at 21:53
  • I always worry about the script kiddies. That explains my hair loss. – Johnny Canuck Jan 19 '11 at 00:02
4

If the hole in the firewall is on TCP/22, then something has to be on TCP/22 to listen to connections. That can be your sshd process, or something else. Though if you want to ssh into it without having to knock on the door first, you're pretty much stuck with having ssd listening on TCP/22.

Another option is to use a door-knocker script of some kind. I haven't used these before, I just know they're out there. Have a service listening on TCP/22. When it receives the right magic string it unloads itself and brings SSHD up on TCP/22 for X minutes. When the SSH process closes the door-listener respawns on TCP/22 and waits for the next door-knock.

But in the end, securing SSH should be good enough. Rely on public-key and disable password auth and all the scriptkiddiez can do is fill your log files. Noisy, but the harmless kind.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
  • Public-key is an option, but annoying. But other suggestions are all good, and ones I've implemented. – Johnny Canuck Jan 19 '11 at 00:02
  • Public key authentication is generally easier to use than password authentication, and potentionally more secure. It's a good idea. Our standard configuration is to simply disable password authentication and require the use of key-based authentication. – larsks Jan 19 '11 at 01:20
4

Tunnel from work to home, and make a tunnel that allows you to connect from home..

A is at work, B is at home. You want to connect from B to A, but firewall blocks it. Instead, connect from A to B creating a tunnel back in to the server. This assumes you have an ssh server running at home and have opened port 22 on your router. If your home machine is Mac or Linux you probably have it running; if windows, install cygwin and set up sshd (link).

At work, put this in your .ssh/config file:

host home
 hostname B      # replace with your FQDN or IP
 user homeuser   # user at home
 LocalForward 2222 localhost:22

Now, when you run 'ssh home', port 2222 will be a tunnel in to your local machine's ssh server. I find if you just leave this sitting at a prompt in some window, the connection may become hung occasionally, or the filewall may close it after a while. I prefer to use a command like

while true; do ssh -n home sleep 600; sleep 3000; done &

This will start a tunnel that lasts ten minutes, closes, then start another the next hour. If there are tunneled connections, when the sleep is finished the ssh command waits for them to finish.
(sleep 3000 is not necessary; you can keep it open all the time, it's just some enterprises don't like seeing frequent or long lived persistent connections to outside machines)

Now, on the home side, put this in your .ssh/config file:

host worktunnel
 hostname localhost
 user     workuser
 port     2222
 UserKnownHostsFile ~/.ssh/known_hosts.worktunnel

Save it, and then when the tunnel is up on your home machine you can just type 

ssh worktunnel

and you're in.

The UserKnownHostsFile line is not necessary, but it prevents warnings when you use multiple tunnels with different ports for different hosts, so the localhost entry in the default known_hosts file won't match all those hosts.

You can add multiple LocalForward lines to the config file on A; e.g. LocalForward 2223 server2:22 # another server with ssh LocalForward 5900 qa:5900 # vnc LocalForward 3389 exchange:3389 # remote desktop LocalForward 3128 internalProxy:3128 # for surfing internal hosts # etc.

(For tunneling X connections, use 'ssh -X', not LocalForward.)

No changing of ssh server port numbers is required here.

Note this kind of remote access may be against your company's policies. Some places scan or audit these kind of connections, and may give you a warning about this. You can run the tunnel command for five minutes, sleep for 55; or have a script on the home machine that exits immediately when you don't need the tunnel. Logmein is another free solution that works nicely to allow remote access to (windows, mac) desktops behind firewalls

toddkaufmann
  • 141
  • 2
2

The other answers cover this pretty well, but I wanted to mention that you could use denyhosts on machine A to cut down on the bot exposure. denyhosts logs attempted ssh requests, and if an outside machine fails too many times it blocks that ip address vi /etc/hosts.deny. Thus for example a bot that tries to ssh in as users bob 100 times will be permanently blocked after the 5th failed attempt (all these parameters are tunable).

You should also follow good ssh server security practices, which I'm sure are covered at length in other serverfault answers. Disable logins for root. Disable logins for all but a very small number of other authorized users. Disable password logins and allow only public key ssh connections.

Phil Hollenback
  • 14,947
  • 4
  • 35
  • 52
  • Thanks to all the answers -- more or less confirmed my suspicions. I might try a trigger script, but as for the other 'hardening' tricks, already implemented those, plus a slew of others. Was just wondering if there was some secret 'trick' to get around the limits of our corporate firewall. Of course, when I asked the masters that be if I could poke another whole into our edge routers, they called me bad names. ;-) – Johnny Canuck Jan 19 '11 at 00:01