6

I have an Ubuntu 12.04 server set up with Gitlab and OpenVPN to serve as a git and vpn server for us.

Currently I have opened up port 1194 in the firewall to open for OpenVPN and let users authenticate by a rsa certificate and a google auth key.

I have not opened the firewall up for SSH traffic yet, as I do not want SSH fully exposed to WAN. However we need to be able to push and pull without being connected to vpn.

How can open the ssh access to WAN only for the limited git user, while allowing admins to access the server from the LAN?

I suspect that I should be looking for something in the direction of using match groups in the sshd_config file. As seen in this question: "How can I setup OpenSSH per-user authentication methods?", does anybody have experience with this?


Edit:

I initially accepted the answer of using access.conf to limit the login access. But later answers indicate that the same can be achieved in sshd.conf either by a match directive or using the username@hostaddress syntax.

At first thought I find it more intuitive to put this in sshd, and it will probably be easier to maintain and understand for other administrators. Are there any strong advantages to using access.conf over sshd.conf?

If I were to range the options mentioned here on how intuitive they are I would say: 1. sshd.conf 2. access.conf 3. IpTables

Do you agree?

5 Answers 5

5

You can control where users are allowed to log in from using the AllowGroups, AllowUsers, DenyGroups, and DenyUsers directives in sshd_config. They are processed in the order DenyUsers, AllowUsers, DenyGroups, AllowGroups. AllowUsers can include the host as well as the username; I think the others just allow names.

Let's say your

  • LAN is 192.168.1.0/24
  • git user is named git
  • admins users are named alice and bob

In sshd_config you would say

AllowUsers [email protected]/24 [email protected]/24 git

Alternately, you could do this with the Match directive. The match directive lets you alter sshd's behavior based on conditions, such as the address from which a user is connecting.

In the global part of the sshd_config you would have

AllowUsers git

the at the end of the file you would override this for your LAN with

Match Address 192.168.1.0/24
    AllowUsers alice bob git
5

You're looking for pam_access, with it you can configure sshd to accept authentication for all users from the local network and for the git user from anywhere.

Something like:

+ : ALL : 10. crond :0 tty1 tty2 tty3 tty4 tty5 tty6
+ : git : ALL
- : ALL : ALL

in your access.conf should do the trick

2
  • Hi, this is my first encounter with pam_access. Could you help me explain the lines a little? + : ALL : 10. crond :0 tty1 tty2 tty3 tty4 tty5 tty6 This lines allows ALL users to connect from: LAN ip: 10.*.*.*, and run cron-jobs, and connect through serial ports. But what is the :0? + : git : ALL Allows git user from anywhere - : ALL : ALL Denies access to anyone else Am I right?
    – Trygve
    Dec 8, 2013 at 20:09
  • Read the access.conf manpage, it explains it all. Dec 8, 2013 at 20:12
3

You can use sshd_config file to control access per user/host and network basis besides that You can use iptables as well as tcpwrappers. I would recommend you to use tcpwrappers to control access in this case in addition to iptables. Using iptables:

Use the -s option of iptables. It accepts an IP of the form nnn.nnn.nnn.nnn or with a mask (nnn.nnn.nnn.nnn/nnn.nnn.nnn.nnn or nnn.nnn.nnn.nnn/nn). So to allow for example connections from nnn.nnn.nnn.* you can write

iptables -A INPUT -s nnn.nnn.nnn.0/255.255.255.0 -i em1 -p tcp --dport XXXXX -m state --state NEW,ESTABLISHED -j ACCEPT

or

iptables -A INPUT -s nnn.nnn.nnn.0/24 -i em1 -p tcp --dport XXXXX -m state --state

If you cannot create a netmask, then I'm afraid you will have to duplicate the rule for each of the IP addresses you want to allow to connect to your server.

Using tcp wrapers, open /etc/hosts.allow to allow access:

sshd: 192.168.0.0/255.255.255.0 1.2.3.4

Above it will allow your LAN and a single WAN IP which is 1.2.3.4 in this case. and then you can simply deny access to all other hosts.

To deny access:

Open file /etc/hosts.deny in text editor. This file list of hosts/IPs that are not allowed to access the system. To deny ssh for all:

sshd: ALL

Please see the following TCP Wrapper's reference on RedHat's website for further detail.

My recommendation is that you should use multiple layers of security in order to make your server more secure and of-course you should use key-based authentication with password for ssh.

3
  • Can I still allow ssh access for the limited Git user from all addresses when using IP Tables and tcpwrappes like this? Our developers may be on dynamic IP's and I would like to allow them to push code.
    – Trygve
    Dec 8, 2013 at 17:04
  • It depends on the use case... lets say all the developers will be accessing it from network 192.168.1.0/24 and one user named 'git' needs to access it from 1.2.3.4. In those scenarios it's good to go. Otherwise, use sshd_config and list 'git' user in there. Use rsa-keys and change the port 22 to some unknown port before exposing it to WAN and don't forget to disable password based login into sshd_config file. I hope that helps
    – Zeeshan
    Dec 8, 2013 at 17:20
  • Okay, I'm working on the latter case, where we have multiple developers off-site who would like to push code to the git user. Thanks for the good help here, I think the sshd_config option might be a good way to go.
    – Trygve
    Dec 8, 2013 at 19:57
1

pam_access could be an option, but I use it only I need to restrict both ssh and console accesses

For ssh, the following config line should work for you:

AllowUsers git *@localhost
0

its pretty simple to lock down box with iptables..... if all you want is to drop traffic, except for a single ip for ssh mgmt, and local lan can hit tcp/80 (for http)

iptables -F
iptables -A INPUT -P tcp -p 22 -s [your-ip-address]/32 -j ACCEPT
iptables -A INPUT -P tcp -p 80 -s [your-local-network-addr]/[your-local-netmask] -j ACCEPT
iptables -A INPUT -j DROP

im not clear what the internal network address / internal netmask for you is, but if the internal lan is a /16, and the network address is 192.168.0.0, this may be allowing non-rfc private ip adddrs to access port 80 (assuming this config is on perimeter device with direct incoming ip traffic).

you can and should have more elaborate / specific iptables rules, but as a bare minimum, this should work

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .