[Spce-user] Lost SSH after upgrade

[Alex Lutay]

Hi Maxwell,

Thank you for the detailed description. It explains a lot,
while I do not see correlation with Anthony's mr5.3.1 upgrade issue.

I have re-checked newly installed mr5.2.1 after enabling security.

It is true, SSH is only allowed for <sshd.permit_support_from>.
AFAIK it is described in documentation:
https://www.sipwise.com/doc/mr5.2.1/spce/ar01s14.html

> To add hosts or networks to the SSH whitelist they can be either added to key sshd.permit_support_from in /etc/ngcp-config/config.yml or a custom rule may be used: - '-A INPUT -s 198.51.100.0/24 --dport 22 - j ACCEPT'

but probably more highlights should be added into documentation
to prevent further confusions. I will take care here.

Also, enabling security in config.yml and 'ngcpcfg apply' is not enough
to lock yourself: https://www.sipwise.com/doc/mr5.2.1/spce/ar01s14.html
> Firewall configuration is applied by running ngcpcfg apply.> However, this will not activate new rules automatically to avoid
inadvertent self-lockout.
> To finally activate new firewall rules run iptables-apply.
> This will prompt for another system logon to verify access remains available.
> If the prompt is not confirmed, firewall rules will automatically be reverted to the previous state re-enabling access to the command line.

Which asks confirmation about successful NEW SSH connection:

> root at spce:~# iptables-apply
> Applying new iptables rules from '/etc/network/iptables.up.rules'... done.
> Can you establish NEW connections to the machine? (y/N) 
> Timeout! Something happened (or did not). Better play it safe...
> Reverting to old iptables rules... done.
> root at spce:~# 

As I can see it works perfectly from my side, rules were reverted as new
connection was not confirmed by me. Did you confirm it without checking
new SSH connection?

You can try it yourself on mr5.2.1 Vagrant image from your side.

Thank you for a pleasant feedback about mr5.3.1,
the team was working hard to fit everything there in time.

Have fun!

On 06/16/2017 11:21 PM, Maxwell Power wrote:
> Hi Alex,
> 
> This happened on a fresh install of 5.2.X. We were migrating a system manually. So when we initially configured it and had it ready for service, we enabled security. It was then that we got locked out. Since it was a new install and accessing the console via KVM was a pain, we just reimaged Debian and reinstalled.
> 
> I believe I had checked the default iptables after reinstalling and found that there was nothing allowing us access to SSH so all connection attempts were just being dropped. It was then I got the impression we needed to specifically allow hosts access. Since it seemed the only access was via the Sipwise jump box. Looking in the manual, I believe the issue was with this rule "-A INPUT -i <ssh_ext_interface> -p tcp -s <sshd.permit_support_from> --dport sshd.port -j ACCEPT". It seems to only allow access for the hosts listed in sshd.permit_support_from. For our purposes, we need many hosts. We could be logging in from a variety of IP's when working remotely or, from a customer site.
> 
> If the intention is to lock SSH down, I suggest adding a note to the docs or even an option in config.yml. Either to allow all access or using permit_support_from.
> 
> All that being said, I didn't spend a great deal of time on it. Simply adding that custom rule and moving on. We have since upgraded that box to mr5.3.1 without issues and left that rule in config.yml for the time being. It's running fine in production at the moment. We can't risk loosing access to that box; to test without said rule.
> 
> I must add, mr5.3.1 is a very nice release! Especially the new reports.
> 
> Cheers, 
> Maxwell Power 

-- 
Alex Lutay