I have three linux boxes over a network (let them be A, B and C).

A is a server machine which provides a few services (ftp, samba, http). I want those services accessible only by B machine. Is there a way, maybe using ssh or VPNs to achieve this goal? Can you also provide links about this?

EDIT: From your answers I understand I haven't been very clear about the focus on authentication and also I simplified too much the problem. Basically there is no real network. There is only A which has a "floating" ethernet slot. When our client wants to do maintenance he attaches its laptop (B) using a normal cross cable. I just want to avoid that a malicious employee could attach its own laptop (C) and starts using services like ftp for example. Yes I could use passwords for services but I'd like to use protection on a lower level (i.e. on a connection basis instead of on service basis).

EDIT2: Basically I want only people with the right certificate to be able to make networking with A.


You can use iptables to block everything but SSH.

The SSH service (sshd) can be configured to require key based logins and not allow password based logins. You could generate RSA key-pairs on the server for each user and give the user a copy of the generated private key after installing the public key in their ~user/.ssh/authorized_keys file.

The authorized users can then use SSH tunnelling for the SAMBA and HTTP services (and use SFTP instead of FTP)

You can revoke/disable access by renaming ~user/.ssh/authorized_keys

I'm not entirely sure how you'd control, at the server end, unexpected other uses of the tunnel. But maybe that's not an issue - as long as the trusted user protects their private key, no untrusted user can access the server.


There are several different ways to accomplish this task, depending on how much work you want to put into this and what level of paranoia you want to have.

  • Physical networking : You can set up a private VLAN where B and A have a connection and have B's services only listen on that particular network. This isn't necessarily the most flexible, since any host you want to access B's services would also have to be wired into that VLAN.
  • TCP Wrappers: Are much less fussy than doing this in iptables and an order of magnitude easier to troubleshoot.
  • IPtables : used in conjunction with the physical networking, would be fairly tight and you can follow Zypher's link for that.

You're best bet, and most simple way to do this would be to use iptables.

let server B's ip be
On Server A create a chain like:

iptables -A INPUT -m tcp -p tcp -s --dport 80 -j ACCEPT
iptables -A INPUT -m tcp -p tcp -s --dport 21 -j ACCEPT
iptables -A INPUT -m tcp -p tcp -s --dport 389 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED --j ACCEPT
iptables -A INPUT -j DROP

This basically tells the firewall to allow connections fromt he one IP on the specific ports, as well as thier related traffic. for ftp you'll have to install the ftp_contrak module as well.

Some iptables documentation to get you started.


In the case example you gave, I would just shutdown the port and not have it come up on boot. When you need to do maintenance, turn the port on. Also if your employee has physical access and malicious intents, well network connectivity is the least of your worries.

  • Turning on the port only when necessary could be a practical solution but it doesn't solve the authentication problem. – Emiliano Nov 11 '10 at 16:24

Have you thought about using a VPN? For example, install OpenVPN on the servers, and set up iptables so that only the OpenVPN port is allowed on this crossover maintenance interface. And maybe DHCP if you want to give them an address as opposed to them having to manually bring up an IP. Then allow FTP and the other protocols you want only to the network addresses on the VPN.

Each authorized employee would have their own key, and then if an employee left you could revoke their key. So you'd even be protected against previous employees. Or if you didn't want this level of protection you could use a shared key rather than a certificate authority.

  • This could work as well I think. I don't know the practical difference between openvpn and ssh tunneling though and I don't really need a high paranoia level. – Emiliano Nov 15 '10 at 9:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.