1

I wasn't sure if this is the right sub-StackExchange for this question so feel free to boot me somewhere else if need be.

I am trying to work with two EC2 servers: one is a "workstation" and the other a "node" (think Chef). The security group of the workstation started out with just one incoming rule that allowed access to port 22 from my local machine's IP address.

I wanted the node server to be accessible from the workstation server, but also from my local machine. So rather than create a new security group, I just added a rule to the security group used on the workstation with its own security group id as the source. In plain English, what I was going for is a security group that allows access on port 22 either from my local machine's IP address or any machine that also has the security group applied. This was my understanding of how the default security group works (all traffic allowed, with the source being the self-referential security group id).

To my mind this was also in line with what I found here in the docs:

If there is more than one rule for a specific port, we apply the most permissive rule. For example, if you have a rule that allows access to TCP port 22 (SSH) from IP address 203.0.113.1 and another rule that allows access to TCP port 22 from everyone, everyone has access to TCP port 22.

My case is obviously a bit different in that I have a rule that allows specific access to port 22 from a specific IP address and a rule that allows specific access to port 22 from a security group rather than from "everyone," but wouldn't a security group source also be considered more permissive than a specific IP address and therefore allow the scenario I described above?

Unfortunately, with the security group set up this way I am only able to SSH into the node from my local machine. When I try to SSH from the workstation on EC2 (that shares the same security group), it times out.

Any ideas on what I might be doing wrong/missing?

2 Answers 2

1

I just added a rule to the security group used on the workstation with its own security group id as the source.

That is the opposite of what you needed to do.

You need to add a rule to the node's security group, specifying the workstation's security group as the source... not (add a rule to) the workstation's security group. A self-referential inbound rule in a security group means machines that are members of that group can access that port on other members of that same group.

I'm unsure why the documentation states such an obvious principle in such a convoluted way... it seems to only serve to confuse the issue. When any traffic matches any rule in a security group, the traffic is allowed. The concept of rule specificity seems like a distraction, here.

2
  • Thanks for taking the time to respond. I understand what you're saying but was hoping there'd be a way for me to do this without creating more than one security group. What I really want, I guess, is to allow 1) the IP address of my local machine, and 2) incoming traffic from any machine on the EC2 subnet. I'm a bit of a newbie with networking but I should be able to do #2 with a rule that uses 0's and subnet mask correctly, right?
    – sixty4bit
    Jul 10, 2016 at 2:20
  • The security group on the "node" needs a rule with the security group of the workstation as a source. The machines perform different roles, so sharing a single security group is inappropriate, but each class of machine only needs one group. It's probably a common mistake to think that fewer security groups will simplify things. It won't, and it increases the likelihood of inappropriately allowing traffic where it should not be allowed in the future. Jul 10, 2016 at 5:04
1

What in fact you did: you allow access to workstation from your IP and from any other instance in the same group (doesn't matter if there isn't any right now, if you add an instance to that group in the future - it will have access to ssh too.

What you need to do: configure SG which the node belongs to. Add rule with your IP, and rule with workstation group as the source. The last one will be read as 'allow access to port 22 from all instances which are in workstation_group.

"Permissive rule" note: I don't know if you're familiar with CIDR and subnets, but this is the topic you need to know to understand it in details. Let's see on two cases. Case 1, two rules:

allow from 192.168.0.0/24
allow from 192.168.1.0/24

Here 'rule of most permissive rule' won't be applied, because the ranges are not overlapped: they in fact mean

allow from 192.168.0.0 to 192.168.0.255
allow from 192.168.1.0 to 192.168.1.255

Case2

allow from 192.168.0.0/22 (note '2' at the end)
allow from 192.168.1.0/24

Here the rule will be applied, because the ranges are:

allow from 192.168.0.0 to 192.168.3.255
allow from 192.168.1.0 to 192.168.1.255

So the second range is inside the first one like a small box inside bigger one. 'The most permissive' here means the first line will work, the wider range.

Feel free to check ipcalc for details.

1
  • Thank you for taking the time to respond and for the detail. Since the core answer is the same as Michael's and his was first, I've marked his correct.
    – sixty4bit
    Jul 10, 2016 at 20:15

You must log in to answer this question.

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