Managing Hyper-V
-
@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.
-
All of the marketing stuff that came with our cluster has it all in caps. So I just assumed thats how they wanted it represented.
-
@scottalanmiller said in Managing Hyper-V:
This shows some promise.
https://cloudbase.it/using-freerdp-to-connect-to-the-hyper-v-console/
This looks quite interesting. I didn't realize the OpenStack Compute bits could control Hyper-V. I may have to give that a go at work next week. I have a couple of Hyper-V servers this could work well on.
-
@stacksofplates said in Managing Hyper-V:
Ya the whole thing was about Scale the company.
Sorry, I was confused. I thought you were emphasizing like "but how will that scale". As if the RDP approach would be problematic for more than a handful of VMs.
-
@dafyre said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
This shows some promise.
https://cloudbase.it/using-freerdp-to-connect-to-the-hyper-v-console/
This looks quite interesting. I didn't realize the OpenStack Compute bits could control Hyper-V. I may have to give that a go at work next week. I have a couple of Hyper-V servers this could work well on.
Oh yes, all four hypervisors are available and work under OpenStack. Although once going OpenStack, is there a compelling reason to use Hyper-V over KVM?
-
@stacksofplates said in Managing Hyper-V:
All of the marketing stuff that came with our cluster has it all in caps. So I just assumed thats how they wanted it represented.
That's weird, I'll mention that to someone. It's not normally in caps.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
All of the marketing stuff that came with our cluster has it all in caps. So I just assumed thats how they wanted it represented.
That's weird, I'll mention that to someone. It's not normally in caps.
Well like the stickers and everything. I didn't read every piece of paper. I could have just looked at the website too, but I made an assumption.
-
@stacksofplates said in Managing Hyper-V:
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.
I agree now that we are on the same [web] page and what I'd really like to see is their "reach out" management system extended for customer use. It would be super easy to do. They have a "no open ports" system already, all the logic and even the interface are there. But customers can't use it.
I'll mention that , too.
-
@scottalanmiller said in Managing Hyper-V:
@dafyre said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
This shows some promise.
https://cloudbase.it/using-freerdp-to-connect-to-the-hyper-v-console/
This looks quite interesting. I didn't realize the OpenStack Compute bits could control Hyper-V. I may have to give that a go at work next week. I have a couple of Hyper-V servers this could work well on.
Oh yes, all four hypervisors are available and work under OpenStack. Although once going OpenStack, is there a compelling reason to use Hyper-V over KVM?
Because your bosses said you had to use hyper-V for some project or another? lol.
-
@dafyre said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@dafyre said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
This shows some promise.
https://cloudbase.it/using-freerdp-to-connect-to-the-hyper-v-console/
This looks quite interesting. I didn't realize the OpenStack Compute bits could control Hyper-V. I may have to give that a go at work next week. I have a couple of Hyper-V servers this could work well on.
Oh yes, all four hypervisors are available and work under OpenStack. Although once going OpenStack, is there a compelling reason to use Hyper-V over KVM?
Because your bosses said you had to use hyper-V for some project or another? lol.
I see. OpenStack there would be the letter of the law but not the intent of it. This would be the loophole situation we talked about the other day. 99% of the time when someone says something like that, they don't actually mean the hypervisor but the ecosystem. This is essentially a KVM ecosystem (or a third party one at least) that just happens to allow Hyper-V to be used. But Hyper-V as a product will be "gone". It's like telling someone that they have to run Windows, not Linux, and so you find a way (MS did this) to replace the Linux kernel with a Windows kernel plus an API to make it act exactly like Linux. It is Windows kernel under the hood? Yes. It is Linux? No. Does it quack like a duck though, yes.
-
basically if you enable winrm with an Enter-PSSession you can control the host from enywhere (firewall must be setup) in powershell.
what I do not find is a central management tool to have an overview of all hosts and their loading conditions.
-
@Dashrender said in Managing Hyper-V:
Now we come to my question.
Is there any reason to not put all the Hyper-V Hosts into a single domain to ease management?
For security and stability I've always seen at any real scale you run a Management domain. Also, given cases of Cyrtolocker hitting Hyper-V hosts I'd be damned careful with separate accounts/domains for Hyper-V hosts as someone encrypting your VM's can bypass a LOT of your protections.
-
@scottalanmiller said in Managing Hyper-V:
ecosystem
Also dropping Nano from being a supported path sucks for people who were hoping for it to be a true small secure embedded install (Core requires a 32GB DISK!)
