The set up of the network is as follows:

The house has Verizon DSL, Verizon router, several personal computers
In the garage, there is a small linux based R&D lab so-to-speak with 6 systems, a Linksys router (default firmware, I think it's a WRT300N) with Wifi A.P. using the Verizon router as it's internet source (essentially a cascading network)
The garage network is separated from the main network because in the lab we're testing network monitoring and filtering which we'd like to not have effect the main house

The idea is to have one of the systems (Dell optiplex 330s) setup to accept SSH connections from outside the network (across town), and from there to SSH to the others. This is all new territory for me though so I have a few questions before I start anything.

1) The software we are using requires a web interface to manage (on localhost), and there are some items in the desktop's menu so I'd need to access the machines desktops as well as terminal. How would I do this with only ssh? My thought is have the machine start a new X session on my host somehow, but I'm not sure how to do that, or if it's even possible.

2) The power in the garage is minimal, plus the power bill would sky rocket if all these machines were always on. What is the easiest method to set the machines to wake up when an ssh connection is attempted?

3) Security for this is crucial, so what I was planning was to only have one system facing the internet directly, sshing externally to that main terminal, then sshing to the local machines from that point. Is this the most secure setup, or is there a better/simpler method?

3.1) How would I set up the other systems to only accept ssh requests from that main terminal, but still have access to the internet?

Eventually these systems are going to be used in business environments that I will ssh to for administration purposes and imaging for backups and restoration, so eventually I'll need to secure every box to the external internet, so whatever I set up on them to only accept local ssh connections will need to be altered in the future.

Pertinent system information:

Main terminal will be dual booting openSUSE 12.3 and CentOS 6.4
Two machines are running Untangle (built on Debian)
One machine is running Security Onion (built on Xubuntu)
One machine is running Zentyal (built on Ubuntu)
The extra is backup, eventually will be Untangle

I am running a Debian 7.1 system which I will be connecting from, my partner will be connecting from openSUSE 12.3.

SSH allows you to tunnel other protocols so what you'd do is open a tunnel connection from your remote workstation to your SSH Gateway machine then open a (SSH, VNC, RDP-like) connection over that tunnel to the machine you want to connect to. Searching Sourceforge for the "souptonuts" SSH tutorial should explain the tunneling stuff in easy to follow steps.


The concept is called Wake On LAN (WOL).


As long as the Gateway is properly hardened and you only SSH in as unprivileged user with pubkey auth then that should do, else see OpenVPN.


Limit the firewall to only accept new connections to TCP/22 from your bastion host if you require SSHing into that first else if you allow remote connections set up a firewall white list (preferring ipset over tcp_wrappers), rate limit new SSH connections, add fail2ban, in sshd_config deny root SSH access (also see Allow*/Deny* directives), allow only pubkeys, and if you don't use sshd_config Allow*/Deny* directives use a pam_listfile white list for accounts.

1 members found this post helpful.

Found his sourceforge page, didn't see anything about an ssh tutorial. I did see an article about breaking firewalls with ssh but that's not quite what I'm looking to do.

Yes, that's what I thought, but wasn't sure.
Is there a way to have the WOL set up to allow ssh from the get go, like from grub and onward? I'm thinking not, because of grub having less to do with the OS, and being closer to the BIOS, but I don't know for sure.

**EDIT**
I looked into ssh for WOL but it seems that the WOL packet needs to be issued from inside the network. If I'm sshing from outside to the main terminal, if that's shutdown then what do I do?

Well, I'm not sure how to properly harden the gateway. What I do know I need to do is set up the ssh config file to prevent the basic vulnerabilities, but from there I'm not certain... Forgive my ignorance, but I don't know where I'd find a reliable 'hardening how-to' so-to-speak. I've found this regarding ssh security, but that's only one aspect of security I'd need to look at I'm sure.

I think I understood all of this, but just to be clear:
- The secondary machines (after the gateway) should have the firewall set to only accept new TCP/22 from the gateway (is it smarter to use MAC white listing in that case?)
- Throttle new SSH connections that aren't from gateway
- Install fail2ban (I should have known that, but it totally slipped my mind, thanks!)
- Deny root login from ssh

But then you mention Allow*/Deny* directives and ya lost me.

SSH into the gateway, then have gateway 'etherwake' the host?


Best start with your distributions documentation because most of what you need to do wrt limiting exposure is common sense. The Securing Debian manual, the SANS Reading Room, OWASP, the CIsecurity profiles and the LQ FAQ: Security references (or better: the cleaned version at http://sourceforge.net/apps/trac/rkhunter/wiki/SECREF) may be of additional help. Also scan the gateway from a remote location using not only nmap but something like OpenVAS or equivalent.


...unless the machine should answer requests from other networks. And no, IPv[4,6] filtering should be enough.


If the machine should answer requests from other networks, yes.


That is a sane default and security best practice. Do combine with public key auth and drop accepting passwords.


Off to 'man sshd_config' then?..

1 members found this post helpful.

Ah, that makes sense! Thanks.

Thanks for the tips, I'll give that a go.

Only the main terminal will be answering requests from other networks, so that handles that.[/quote]

Makes sense, thanks again.

Ha yes I suppose so. Again, thanks for the advice, tips, and quick answers!

1 members found this post helpful.