Remote management of VMs hosted in colocation
-
@eddiejennings said in Remote management of VMs hosted in colocation:
Allowing an SSH connection to the managementVM from the Internet
I have not tried this approach yet, and it appears more risky than the Screen Connect approach, since SSH to that VM would be open to the Internet. Unless I'm missing some benefit to this approach, I'll not be using it.
Use a strong key, lock to your IP. Very safe. Add Fail2Ban, of course.
Or add Salt and open/close based on need so it doesn't stay open.
-
@scottalanmiller said in Remote management of VMs hosted in colocation:
@eddiejennings said in Remote management of VMs hosted in colocation:
Allowing an SSH connection to the managementVM from the Internet
I have not tried this approach yet, and it appears more risky than the Screen Connect approach, since SSH to that VM would be open to the Internet. Unless I'm missing some benefit to this approach, I'll not be using it.
Use a strong key, lock to your IP. Very safe. Add Fail2Ban, of course.
Or add Salt and open/close based on need so it doesn't stay open.
Or do none of that and just use ZT. Way fewer things to fail.
-
@scottalanmiller said in Remote management of VMs hosted in colocation:
@eddiejennings said in Remote management of VMs hosted in colocation:
Allowing an SSH connection to the managementVM from the Internet
I have not tried this approach yet, and it appears more risky than the Screen Connect approach, since SSH to that VM would be open to the Internet. Unless I'm missing some benefit to this approach, I'll not be using it.
Use a strong key, lock to your IP. Very safe. Add Fail2Ban, of course.
Or add Salt and open/close based on need so it doesn't stay open.
I could see that in a situation where your office has a static IP. For me, I wouldn't be able to lock down the allowed IP, since there's a chance it'll change.
-
ZeroTier makes it super easy and safe. If you want, you could make a ZeroTier Bridge VM. I would still setup Fail2Ban and use key-based authentication.
-
@eddiejennings said in Remote management of VMs hosted in colocation:
@scottalanmiller said in Remote management of VMs hosted in colocation:
@eddiejennings said in Remote management of VMs hosted in colocation:
Allowing an SSH connection to the managementVM from the Internet
I have not tried this approach yet, and it appears more risky than the Screen Connect approach, since SSH to that VM would be open to the Internet. Unless I'm missing some benefit to this approach, I'll not be using it.
Use a strong key, lock to your IP. Very safe. Add Fail2Ban, of course.
Or add Salt and open/close based on need so it doesn't stay open.
I could see that in a situation where your office has a static IP. For me, I wouldn't be able to lock down the allowed IP, since there's a chance it'll change.
Not really an issue, use Salt to maintain it so not a problem even for dynamic.
-
@black3dynamite said in Remote management of VMs hosted in colocation:
ZeroTier makes it super easy and safe. If you want, you could make a ZeroTier Bridge VM. I would still setup Fail2Ban and use key-based authentication.
I'd argue that it doesn't really make it safer. ZT is just key based access, like SSH is. If you are concerned that SSH with keys isn't enough, ZT isn't either. ZT exposes even more should it be compromised, as well. In both cases, being compromised is pretty bad, but one is a lot more limited and able to be limited. If you feel someone can breach your keys with SSH, why not ZT just the same?
-
@scottalanmiller said in Remote management of VMs hosted in colocation:
@eddiejennings said in Remote management of VMs hosted in colocation:
@scottalanmiller said in Remote management of VMs hosted in colocation:
@eddiejennings said in Remote management of VMs hosted in colocation:
Allowing an SSH connection to the managementVM from the Internet
I have not tried this approach yet, and it appears more risky than the Screen Connect approach, since SSH to that VM would be open to the Internet. Unless I'm missing some benefit to this approach, I'll not be using it.
Use a strong key, lock to your IP. Very safe. Add Fail2Ban, of course.
Or add Salt and open/close based on need so it doesn't stay open.
I could see that in a situation where your office has a static IP. For me, I wouldn't be able to lock down the allowed IP, since there's a chance it'll change.
Not really an issue, use Salt to maintain it so not a problem even for dynamic.
That would be another thread.
Spin up a Salt VM for maintaining stuff on my host and accessing it from afar. -
@scottalanmiller said in Remote management of VMs hosted in colocation:
@black3dynamite said in Remote management of VMs hosted in colocation:
ZeroTier makes it super easy and safe. If you want, you could make a ZeroTier Bridge VM. I would still setup Fail2Ban and use key-based authentication.
I'd argue that it doesn't really make it safer. ZT is just key based access, like SSH is. If you are concerned that SSH with keys isn't enough, ZT isn't either. ZT exposes even more should it be compromised, as well. In both cases, being compromised is pretty bad, but one is a lot more limited and able to be limited. If you feel someone can breach your keys with SSH, why not ZT just the same?
Not true.
- I never said I don't trust SSH key based auth. I said
@jaredbusch said in Remote management of VMs hosted in colocation:
Keys or not, I will not open SSH to the public internet if I have a simple way around it.
Because, while I may trust SSH, we live in reality where unknown vulnerabilities do exist. By not having it open, at all, to a public facing source, you drastically mitigate the attack surface.
ZT is access without a public inbound allowance. Someone would have to gain access to your ZT network before being able to then try and get your keys for the SSH session.
@scottalanmiller said in Remote management of VMs hosted in colocation:
ZT exposes even more should it be compromised, as well
This is a strawman. If you want to take up this argument, it would be a separate, yet related, discussion.
-
@jaredbusch said in Remote management of VMs hosted in colocation:
ZT is access without a public inbound allowance. Someone would have to gain access to your ZT network before being able to then try and get your keys for the SSH session.
that's my point. How is the access to your ZT network more secure than the keyed access to an SSH port? Both have the risk of vulnerabilities (but nothing has the eyes on it and reviews of OpenSSH, so if that's a concern that makes SSH the clean place to start), and both have access from the outside. Both rely on keys and both have known open ports.
-
@scottalanmiller said in Remote management of VMs hosted in colocation:
@jaredbusch said in Remote management of VMs hosted in colocation:
ZT is access without a public inbound allowance. Someone would have to gain access to your ZT network before being able to then try and get your keys for the SSH session.
that's my point. How is the access to your ZT network more secure than the keyed access to an SSH port? Both have the risk of vulnerabilities (but nothing has the eyes on it and reviews of OpenSSH, so if that's a concern that makes SSH the clean place to start), and both have access from the outside. Both rely on keys and both have known open ports.
I was wondering this exact same thing - why is ZT more trusted in this case than SSH?
-
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
If you're using an infested machine - when you use the apps to make that remote session to the colo, be it SSH or SC, the malware can likely grab the needed information and provide it to the hackers.
I'm guessing that the Salt idea might give the greatest protection here when combined with the IP lock option that Scott mentioned - but then I ask - how do you securely manage the Saltmaster, where ever it lives?
-
@dashrender said in Remote management of VMs hosted in colocation:
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
Umm, no. Exactly the opposite. The point is the reduced attack surface to the host.
@dashrender said in Remote management of VMs hosted in colocation:
I was wondering this exact same thing - why is ZT more trusted in this case than SSH?
@dashrender said in Remote management of VMs hosted in colocation:
but then I ask - how do you securely manage the Saltmaster, where ever it lives?
Because ZT has account level auth (your password to sign in to your account) and then device auth (approving the device that wants to join the network).
Why create all this overhead for no reason, when ZT already handles it?
Answer? Because Salt is SAM's shiny toy.
-
@jaredbusch said in Remote management of VMs hosted in colocation:
@dashrender said in Remote management of VMs hosted in colocation:
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
Umm, no. Exactly the opposite. The point is the reduced attack surface to the host.
@dashrender said in Remote management of VMs hosted in colocation:
I was wondering this exact same thing - why is ZT more trusted in this case than SSH?
@dashrender said in Remote management of VMs hosted in colocation:
but then I ask - how do you securely manage the Saltmaster, where ever it lives?
Because ZT has account level auth (your password to sign in to your account) and then device auth (approving the device that wants to join the network).
Why create all this overhead for no reason, when ZT already handles it?
Answer? Because Salt is SAM's shiny toy.
Pot calling the kettle black there. SSH is the simple, safe, battle tested option. ZT is great and I really like it, but if someone has a toy here, that's it. Yes, it has multiple log in spots, but you just up the key strength to match that and you are at the same security level.
Yes, ZT already handles some of this, but SSH is simple and easy and built in. ZT takes quite a bit more work and is much more complex to do something really simple, it's just not necessary or beneficial when the simple solution handles it.
-
@dashrender said in Remote management of VMs hosted in colocation:
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
The OP's goal is discovering good practices for managing remotely hosted VMs. I identified a potential risk with how I'm doing stuff now as "if my laptop gets compromised, then it's game over for my host, since there is an always-on connection to it via ZT."
-
@scottalanmiller said in Remote management of VMs hosted in colocation:
@jaredbusch said in Remote management of VMs hosted in colocation:
@dashrender said in Remote management of VMs hosted in colocation:
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
Umm, no. Exactly the opposite. The point is the reduced attack surface to the host.
@dashrender said in Remote management of VMs hosted in colocation:
I was wondering this exact same thing - why is ZT more trusted in this case than SSH?
@dashrender said in Remote management of VMs hosted in colocation:
but then I ask - how do you securely manage the Saltmaster, where ever it lives?
Because ZT has account level auth (your password to sign in to your account) and then device auth (approving the device that wants to join the network).
Why create all this overhead for no reason, when ZT already handles it?
Answer? Because Salt is SAM's shiny toy.
Pot calling the kettle black there. SSH is the simple, safe, battle tested option. ZT is great and I really like it, but if someone has a toy here, that's it. Yes, it has multiple log in spots, but you just up the key strength to match that and you are at the same security level.
Yes, ZT already handles some of this, but SSH is simple and easy and built in. ZT takes quite a bit more work and is much more complex to do something really simple, it's just not necessary or beneficial when the simple solution handles it.
More work than your gimmicky Salt setup? As if.
-
Cyber security is just like physical security. Nothing is 100% secure if it's usable.
Isn't the point of security to delay the attacker long enough so he can be detected? That's why we need layers and some kind of intrusion detection.
Don't know anything about it but ZT sounds like one layer of security. Does it at have 2FA?
-
@eddiejennings said in Remote management of VMs hosted in colocation:
@dashrender said in Remote management of VMs hosted in colocation:
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
The OP's goal is discovering good practices for managing remotely hosted VMs. I identified a potential risk with how I'm doing stuff now as "if my laptop gets compromised, then it's game over for my host, since there is an always-on connection to it via ZT."
I'm not sure the always connected bit matters - does it? If you have an SSH client with the key stored in it - and why wouldn't you - this is likely just as bad as ZT. The attacker can just launch the SSH client on your machine and tada - he's got a connection to your host.
The same might be say able about SC - your laptop is compromised - they still your SC creds - hell, they now use your creds from their own machine to connect to SC.
I'm not seeing anything that offers protection from you using a compromised machine.
-
@jaredbusch said in Remote management of VMs hosted in colocation:
@scottalanmiller said in Remote management of VMs hosted in colocation:
@jaredbusch said in Remote management of VMs hosted in colocation:
@dashrender said in Remote management of VMs hosted in colocation:
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
Umm, no. Exactly the opposite. The point is the reduced attack surface to the host.
@dashrender said in Remote management of VMs hosted in colocation:
I was wondering this exact same thing - why is ZT more trusted in this case than SSH?
@dashrender said in Remote management of VMs hosted in colocation:
but then I ask - how do you securely manage the Saltmaster, where ever it lives?
Because ZT has account level auth (your password to sign in to your account) and then device auth (approving the device that wants to join the network).
Why create all this overhead for no reason, when ZT already handles it?
Answer? Because Salt is SAM's shiny toy.
Pot calling the kettle black there. SSH is the simple, safe, battle tested option. ZT is great and I really like it, but if someone has a toy here, that's it. Yes, it has multiple log in spots, but you just up the key strength to match that and you are at the same security level.
Yes, ZT already handles some of this, but SSH is simple and easy and built in. ZT takes quite a bit more work and is much more complex to do something really simple, it's just not necessary or beneficial when the simple solution handles it.
More work than your gimmicky Salt setup? As if.
Well - I think Scott was dumbing it down to simply using SSH, and not using salt to open IPs to allow connections, etc. That would be simpler than using ZT.
-
@dashrender said in Remote management of VMs hosted in colocation:
@eddiejennings said in Remote management of VMs hosted in colocation:
@dashrender said in Remote management of VMs hosted in colocation:
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
The OP's goal is discovering good practices for managing remotely hosted VMs. I identified a potential risk with how I'm doing stuff now as "if my laptop gets compromised, then it's game over for my host, since there is an always-on connection to it via ZT."
I'm not sure the always connected bit matters - does it? If you have an SSH client with the key stored in it - and why wouldn't you - this is likely just as bad as ZT. The attacker can just launch the SSH client on your machine and tada - he's got a connection to your host.
The same might be say able about SC - your laptop is compromised - they still your SC creds - hell, they now use your creds from their own machine to connect to SC.
I'm not seeing anything that offers protection from you using a compromised machine.
You can password protect the key. Or if you use Apps like MobaXTerm and such, they can be set to require a password before the app is usable.
-
@dashrender said in Remote management of VMs hosted in colocation:
@jaredbusch said in Remote management of VMs hosted in colocation:
@scottalanmiller said in Remote management of VMs hosted in colocation:
@jaredbusch said in Remote management of VMs hosted in colocation:
@dashrender said in Remote management of VMs hosted in colocation:
The main thing I see the OP trying to save himself from is his control workstation being pwned. But in reality, I'm not sure there is anything one can do if they are using a pwned machine connect to their colo.
Umm, no. Exactly the opposite. The point is the reduced attack surface to the host.
@dashrender said in Remote management of VMs hosted in colocation:
I was wondering this exact same thing - why is ZT more trusted in this case than SSH?
@dashrender said in Remote management of VMs hosted in colocation:
but then I ask - how do you securely manage the Saltmaster, where ever it lives?
Because ZT has account level auth (your password to sign in to your account) and then device auth (approving the device that wants to join the network).
Why create all this overhead for no reason, when ZT already handles it?
Answer? Because Salt is SAM's shiny toy.
Pot calling the kettle black there. SSH is the simple, safe, battle tested option. ZT is great and I really like it, but if someone has a toy here, that's it. Yes, it has multiple log in spots, but you just up the key strength to match that and you are at the same security level.
Yes, ZT already handles some of this, but SSH is simple and easy and built in. ZT takes quite a bit more work and is much more complex to do something really simple, it's just not necessary or beneficial when the simple solution handles it.
More work than your gimmicky Salt setup? As if.
Well - I think Scott was dumbing it down to simply using SSH, and not using salt to open IPs to allow connections, etc. That would be simpler than using ZT.
But that is not what I was arguing. Thus, as I mentioned before, strawman.
