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.
-
@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.
-
@Tim_G said in Managing Hyper-V:
Your best option might be to just put the hyper-v hosts on their own little LAN, and restricted to only secure VPN access.
The cluster is on a LAN itself already, yes. It's the management piece that is the only pain. For us, a Windows server on top of the Scale cluster will work. Then remote into that through any normal means. But it's not ideal, but works.
-
@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:
@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.
Oh, but we had talked about a reverse proxy in front as well, and you put that on the proxy, not on the Scale itself. And if you call it SCALE instead of Scale like you did in the very first post, I actually thought you were trying to highlight that were you talking about ability to scale (as in scaling) not the product by Scale the company until later in the conversation.
With the Scale HC3 out of the box, yes, you need a reverse proxy like Nginx to add that feature. But Scale doesn't offer an SSH management option, so if we are talking Scale, web is the answer.
-
@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:
@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.
Oh, but we had talked about a reverse proxy in front as well, and you put that on the proxy, not on the Scale itself. And if you call it SCALE instead of Scale like you did in the very first post, I actually thought you were trying to highlight that were you talking about ability to scale (as in scaling) not the product by Scale the company until later in the conversation.
With the Scale HC3 out of the box, yes, you need a reverse proxy like Nginx to add that feature. But Scale doesn't offer an SSH management option, so if we are talking Scale, web is the answer.
Ya the whole thing was about Scale the company. That's my whole point here. There is nothing protecting you against anything on that login page unless you put something in front of it. Which is why I said "if" they allow you to SSH in. That was my whole point here. If you have an appliance with a public facing web interface you are trusting that single web page 100% to be your first and last line of defense. Having a jump box/bastion host in front may be 'LAN' security, but it's better than a wide open login page that you can't modify.
