Managing Hyper-V
-
@stacksofplates said in Managing Hyper-V:
My point is I don't understand why you go with salt because of the concern of security with SSH but you leave a web page open directly to the internet.
Because I can turn access on and off with Salt.
-
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
-
Or if you can lock it down to a local tunnel through SSH that would be better. Ours isn't set up yet so I'm not sure if you can do that.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
The hosts get daily updates from SCALE? And SSL updates don't fix bugs in PHP or JS or whatever they use.
-
@stacksofplates said in Managing Hyper-V:
Or if you can lock it down to a local tunnel through SSH that would be better. Ours isn't set up yet so I'm not sure if you can do that.
I figure anything you can do through a web or SSL tunnel, you can do through SSH, too. And I've been trying to figure out how to automate that well with a "reach out" system and if that is logically a good approach.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
The hosts get daily updates from SCALE? And SSL updates don't fix bugs in PHP or JS or whatever they use.
Oh, on the Scale specifically? No, not daily. But regularly. It alerts you whenever there is an update to apply. I don't get SSH regularly either. I update systems daily and go weeks or months between OpenSSH or OpenSSL library updates at times. But they are released on any given day as needed, and the same with the Scale.
Language bugs exist for everything, including for SSH.
-
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
Or if you can lock it down to a local tunnel through SSH that would be better. Ours isn't set up yet so I'm not sure if you can do that.
I figure anything you can do through a web or SSL tunnel, you can do through SSH, too. And I've been trying to figure out how to automate that well with a "reach out" system and if that is logically a good approach.
But web isn't key based. A 4096 bit key is better than a login page no matter how long the password is. And mitigates brute forcing (whether that's even still a concern anymore).
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
The hosts get daily updates from SCALE? And SSL updates don't fix bugs in PHP or JS or whatever they use.
Oh, on the Scale specifically? No, not daily. But regularly. It alerts you whenever there is an update to apply. I don't get SSH regularly either. I update systems daily and go weeks or months between OpenSSH or OpenSSL library updates at times. But they are released on any given day as needed, and the same with the Scale.
Language bugs exist for everything, including for SSH.
That's my point tho. You get them immediately when they are available.
-
@scottalanmiller said in Managing Hyper-V:
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
You can do that with local tunnels too which is why I mentioned that. To me that would be the preferable way. Tunnel to 127.0.0.1
-
@stacksofplates said in Managing Hyper-V:
But web isn't key based.
Actually it is. That's an option with every web server and browser that I know. Just no one uses it. But it is the same mechanism that OpenVPN uses for its key based VPN authentication. Literally the same one, same keys, same libraries used. Long ago we had to learn that for web management certs. Today, it's been like forgotten. But it is there and a totally viable mechanism if you are considering the same approach with a VPN or SSH.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
I trust SSH on a bastion host which gets daily updates and bug fixes more than I trust a web page that gets development but not daily updates.
As the web page uses the same daily updates for the encryption as SSH, I don't think that this is an issue. Both rely on the same OpenSSL library equally.
The hosts get daily updates from SCALE? And SSL updates don't fix bugs in PHP or JS or whatever they use.
Oh, on the Scale specifically? No, not daily. But regularly. It alerts you whenever there is an update to apply. I don't get SSH regularly either. I update systems daily and go weeks or months between OpenSSH or OpenSSL library updates at times. But they are released on any given day as needed, and the same with the Scale.
Language bugs exist for everything, including for SSH.
That's my point tho. You get them immediately when they are available.
Right, and you do with Scale, too. That was what I was saying. When a critical bug is released, you get the update. It's not a scheduled thing like "once a month" or something like that. If you used SSH in the same places as web, you'd have the same update pattern regardless.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
You can do that with local tunnels too which is why I mentioned that. To me that would be the preferable way. Tunnel to 127.0.0.1
Six of one, half a dozen of the other. Same tunnel mechanism, same security.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
But web isn't key based.
Actually it is. That's an option with every web server and browser that I know. Just no one uses it. But it is the same mechanism that OpenVPN uses for its key based VPN authentication. Literally the same one, same keys, same libraries used. Long ago we had to learn that for web management certs. Today, it's been like forgotten. But it is there and a totally viable mechanism if you are considering the same approach with a VPN or SSH.
But hat either needs server side support for SOCKS or some kind of challenge file, or some way for your local browser extension for the keys.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
You can do that with local tunnels too which is why I mentioned that. To me that would be the preferable way. Tunnel to 127.0.0.1
Six of one, half a dozen of the other. Same tunnel mechanism, same security.
Not really because the form is still open. I. Can eliminate passwords with SSH completely or use Kerberos tickets.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
But web isn't key based.
Actually it is. That's an option with every web server and browser that I know. Just no one uses it. But it is the same mechanism that OpenVPN uses for its key based VPN authentication. Literally the same one, same keys, same libraries used. Long ago we had to learn that for web management certs. Today, it's been like forgotten. But it is there and a totally viable mechanism if you are considering the same approach with a VPN or SSH.
But hat either needs server side support for SOCKS or some kind of challenge file, or some way for your local browser extension for the keys.
No extension needed, it's native and has been for decades. We used to use it in the late 1990s for security to prove who the end user was automatically. It's the same as the server side certs but in the opposite direction. It's always there, ready to be used, but somehow, the world has forgotten about this powerful mechanism available to us for web authentication and it only gets used in other projects using the same code, like OpenVPN, and people associate it as part of a VPN solution and don't realize it's just part of normal web traffic capabilities.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
You can do that with local tunnels too which is why I mentioned that. To me that would be the preferable way. Tunnel to 127.0.0.1
Six of one, half a dozen of the other. Same tunnel mechanism, same security.
Not really because the form is still open. I. Can eliminate passwords with SSH completely or use Kerberos tickets.
That's what I'm saying - it's THE SAME. Anything you think is different has to be a misunderstanding of how web SSL works. OpenSSH is using the same library for all of that as the web page is. The web server itself, not the page it loads, can do the same password and/or key system that SSH does because it's the same one, actually the same one. The idea that you need to authenticate someone "inside" of the web page is a later concept and is application level, not the web level. You can do both, if you want, adding yet another level of security to web that SSH would not have... but if you made someone log into an application inside of SSH (say a password to get into the MySQL client) then that would be analogous.
-
The PKI used on the web is bidirectional. It's symmetric. Just everyone has ignored that for so long that it's often overlooked as a security mechanism.
-
I've been looking, and I just can't find anything.
Your best option might be to just put the hyper-v hosts on their own little LAN, and restricted to only secure VPN access.
This way you can use Failover Cluster Manager (I just noticed now that you said cluster earlier), or Hyper-V Manager if needed.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
But with web, you have good choices like adding reverse proxies and such. It's easy to lock down SSL based channels in standard but still accessible ways.
You can do that with local tunnels too which is why I mentioned that. To me that would be the preferable way. Tunnel to 127.0.0.1
Six of one, half a dozen of the other. Same tunnel mechanism, same security.
Not really because the form is still open. I. Can eliminate passwords with SSH completely or use Kerberos tickets.
That's what I'm saying - it's THE SAME. Anything you think is different has to be a misunderstanding of how web SSL works. OpenSSH is using the same library for all of that as the web page is. The web server itself, not the page it loads, can do the same password and/or key system that SSH does because it's the same one, actually the same one. The idea that you need to authenticate someone "inside" of the web page is a later concept and is application level, not the web level. You can do both, if you want, adding yet another level of security to web that SSH would not have... but if you made someone log into an application inside of SSH (say a password to get into the MySQL client) then that would be analogous.
I'm not saying it's not possible. I'm saying you can't do it with SCALE unless you modify their systems. So YOU (as in Scott not as in everyone) can't do it with SCALE.
The whole conversation I started is about SCALE not webservers in general.
