The consoles at big hosts typically require good 2fa to log in to the web management console, which typically can open a command line on the instance. This is a nice authN layer.
Note that it's possible to configure multi-factor authentication using e.g. one-time password (OTP) for those regular openssh logins. The setup to achieve that still seem quite involved though, so the reluctant sysadmin in me haven't got around to try it.
Multiple factors:
1FA: Password(1F) OR private key (password blank)(1F)
There's massive differences of using this compared to throwing some keys on a server and opening 22. These systems use the cloud provider's proxying and authz/authn to dynamically grant access.
One could have a box with no public IP and no open ports and still use this to connect.
No, through their in-house proxy tools such as Session Manager or Identity Aware Proxy or whatever Azure has.
> With an SSH key?
Not at the edge, and not an SSH key you manage. A dynamically generated one managed by the cloud provider which exists just for that session. So, not really, not like you're thinking.
The console in AWS allows access within its system. There is no point increasing the access area to the hosts. More surface area the easier it is to be penetrated by ssh vulnerabilities. You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation.
What you want to do is avoid fault, improve tolerance, but extend liability to the provider.
> AWS allows you to ssh into your hosts from within AWS.
This is where your argument breaks down IMHO. Unless you are saying "don't expose port 22 to the world...", which is a common (small) part of security-in-depth.
> You also shift fault to AWS rather than your company and team. You did your diligence, you just have to access control and nothing more. IF AWS has a security breach that access to your systems completely on AWS and you can demand compensation.
This appears to be an instance of the "appeal to authority"[0] fallacy and is of little solace should server(s) one is responsible for become compromised.
You still have to do your diligence. You established what is supposed be a secure system yet that system failed due to provider security. AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established? You are breaking convention, reinventing the wheel and complicating an already simple system.
This isn't fallacy it is reducing a businesses cognitive load.
> You established what is supposed be a secure system yet that system failed due to provider security.
This makes no sense. By your own recommendation, "provider security" is an AWS offering.
> AWS is far more staffed than any other company why wouldn't you shift left to AWS? Why would you hire a fleet of security engineers to do what AWS already established?
What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services?
> You are breaking convention, reinventing the wheel and complicating an already simple system.
Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention?
And what wheel did I "reinvent"?
Finally, was my identification of the common practice which is moving sshd off of port 22 the complication to which you refer?
Yeaaah you're trying poke holes. Problem is that there are larger holes in a network if you're setting up and safe guarding a VPN so you can SSH. Moving ssh if even needed at all should be to the provider's secured tools.
I really don't recommend extending responsibility for creature comforts. However you want to do this so be it.
> This makes no sense. By your own recommendation, "provider security" is an AWS offering.
Are you stating your system is infaliable? So why would you want to bear the infaliable claim and not shift it to the company providing it?
> What does Amazon's staffing have to do with best practices when securing a server deployed on their platform? Who said anything about "a fleet of security engineers"? How does any of that relate to securing that which one constructs, and ultimately is responsible for, when using said hosting services?
Tooling takes a team to support it. You think every company can afford a team to manage that tooling? And why should they? Not all businesses are tech companies but still need a digital footprint. They need to be selfconcious and choose provider practices to get the most out of them.
> Are you saying that your original statement of "You also shift fault to AWS rather than your company and team" is somehow an accepted convention?
Providers own the responsibility of their technology. In terms of failure if access is correctly configured and managed, yet their technology fails they owe your businesses it is very simple.
> And what wheel did I "reinvent"?
Implementing old security practices. Why wouldn't you move to be better pratices and prevent larger holes in your network? Often companies get into this repetitious cycle of reimplementation or reinvention of existing tools and technology just to manage access especially ssh. The convention of using a cloud platform is to use a cloud platform's security access not some sketched up VPN and SSH system.
This sums it up, "The convention of using a cloud platform is to use a cloud platform".
If you rent compute space, then you trust them to responsibly use the hypervisor instead of snooping. If you trust that or not, you are all in and may as well cement over the external port 22.
No, I am trying to remind you of the topic which was under discussion. To wit:
The Reluctant Sysadmin's Guide to Securing a Linux Server
> Are you stating your system is infaliable?
A straw man fallacy (sometimes written as strawman) is the
informal fallacy of refuting an argument different from
the one actually under discussion, while not recognizing or
acknowledging the distinction.[0]
> Tooling takes a team to support it.
See above quote.
> You think ...
You do not know what I think nor my experiences, so please do not be so arrogant as to assume so.
>> And what wheel did I "reinvent"?
> Implementing old security practices.
Again, please refer to the *article under discussion*. In the event it remains unclear, I will restate its title:
The Reluctant Sysadmin's Guide to Securing a Linux Server
> Why wouldn't you move to be better pratices and prevent larger holes in your network?
See previous strawman definition and link below.
> Often companies get into this repetitious cycle of reimplementation or reinvention of existing tools and technology just to manage access especially ssh. The convention of using a cloud platform is to use a cloud platform's security access not some sketched up VPN and SSH system.
Again, see previous strawman definition above and link below.
Note that the only ssh-related recommendation I proffered was:
Unless you are saying "don't expose port 22 to
the world...", which is a common (small) part of
security-in-depth.
This is a well-known, albeit very small and insufficient by itself, part of helping to reduce attack vectors.
As to "sketched up VPN and SSH system", I have no idea as to what you are referencing. Perhaps this is a recollection of a previous engagement wherein decisions made remind you of a bad situation similar to, but different than, this?
Strawman argument sometimes is used to draw out a point. You can not confidently say your security solution is infabiable and nor should you. The article is just a good runbook of things and less a guide. But if you are working on the cloud you shouldn't go using old management methods like they belong in your network.
You would not believe how many companies are dependent on patching through users through VPNs in order to access remote hosts. I mean some have to because of no other solutions like managing their own on-prem. I kind of would be interested in AWS access management capable of being implemented within an on-prem.
I have to agree with this notion. Fishing seems to be a community building shared relaxation space, one of my favorite activities to fill my increasingly limited free time. It's very offline and accessible to all, regardless of socioeconomic status.
I ran into the same thing when I built my house, where I couldn't find anyone local to take care of installing my split mini units without a wait of six weeks or more. I ultimately ended up purchasing a 25lb refrigerant tank, guage set, and vacuum pump to commission the units. I wasn't trying to DIY or save money per se, but this seemed to be the path of least resistance. Five years later all five heat pumps are going strong, this market dynamic doesn't seem to have changed much (here in Virginia USA) as I helped my neighbor bring her two heat pump units online in October 2022 after she couldn't get any of the local installers to schedule her either. I'm still puzzled why heat pumps are not dominant in the US market and why natural gas furnaces of any efficiency are still being installed, given that you can't power them from rooftop PV which is everywhere these days.
Watch the "Home Performance" channel on YouTube (see https://youtu.be/1Iiho2cm2LY) and note that there is a community of builders and installers who follow these practices and are likewise supporters of this channel.
Yeah I've considered this route... Mr Cool makes some precharged linesets for their heat pumps that are a still lower resistance path, but I'm at a bit of a loss how to take care of the refrigerant in the existing AC if I do end up DIYing it and swapping that unit out for a HP.
If the unit is still operational, it can usually be 'pumped down', which essentially means closing the 'out' valve and force-running the compressor to pull all the refrigerant back into the main compressor unit. You then might be able to take it to the waste facility, where they have people licensed to recover the refrigerant (for a fee).
I have my EPA cert, and I'd still probably go that route. The recovery pumps are expensive ($500+) and you need a recovery tank ($100), and then you still need to find somewhere that will take it from you. For a single job, it might be better to pay a HVAC company/moonlighting tech to do that part and do all the manual labor yourself.
Oh nice, that pump down process is something I hadn't heard of. I do have a good plumber and electrician, and our County has really good waste disposal options so that may work for me. Appreciate the heads up there.
