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.
SSH is an always encrypted connection. It doesn't even pass keys until an encrypted tunnel is setup, so using over VPN is.... 2 levels of encrypted communication.
-
@eddiejennings said in Remote management of VMs hosted in colocation:
The major problem I see with this:
If my laptop becomes compromised (think ransomware), then my host is pwn'd.Some other potential options.
You don't have to keep your laptop ZT permanently connected. Just enable it whenever you need to use it then disable it soon after.
You can also have VM (on you laptop) you use just for management.
-
@brandon220 said in Remote management of VMs hosted in colocation:
I thought virt-manager only used ssh to connect to the host. What about using key-based auth to the host and disable password auth? Seems it would be faster than going through ZT. I guess the laptop compromise still poses an issue in that scenario.
If you realize your laptop has been Pwned or stolen then kick it out of the ZT network.
-
@brandon220 said in Remote management of VMs hosted in colocation:
I thought virt-manager only used ssh to connect to the host. What about using key-based auth to the host and disable password auth? Seems it would be faster than going through ZT. I guess the laptop compromise still poses an issue in that scenario.
Keys or not, I will not open SSH to the public internet if I have a simple way around it.
That is what I like about using something like ZeroTier for. His KVM host has zero presence on the Public internet. It only uses an outbound SSL session to connect to the ZT network.
-
Perhaps if I wanted an extra thick tinfoil hat, I could have my managementVM connected to ZeroTier, setup
$remoteDesktopMechanismon the VM, and connect to the managementVM from my laptop via ZeroTier to manage the kvm host and all of the other VMs. -
@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.
