Is it possible to expose the ssh port 22 to the world? #28
Comments
|
I don't see many reasons why you'd want to do this on a container session. There are also more dangers you could be exposing. It is funny though, because I was trying to get this to work when I was starting the QEMU support, where I did feel it necessary to make SSH to the VM available. I couldn't get it to work then either, but I didn't dig much deeper. This will be a good issue to track that. |
|
I actually try to install xrdp to connect to it remotely and work with two screens.
The ssh is not too important.
I managed to export the pod to a point where xrdp connects but the credentials did not work.
I can try with xvnc as well if that’s better
… On 1 Mar 2021, at 16:46, Avi Zimmerman ***@***.***> wrote:
I don't see many reasons why you'd want to do this on a container session. There are also more dangers you could be exposing.
It is funny though, because I was trying to get this to work when I was starting the QEMU support, where I did feel it necessary to make SSH to the VM available. I couldn't get it to work then either, but I didn't dig much deeper.
This will be a good issue to track that.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Multiple monitors is another thing on my radar. But is also a very complicated rabbit hole by itself. VNC doesn't really have any concept of monitors, just the one "display" (which may span multiple physical monitors). But a lot of the kvdi internals that are already there could theoreticaly make it possible to sorta "trick" it. But then the UI side of that is a whole other story, and then I start wondering about a full blown client app 😆 . No matter what, I want to make exposing ports to a session easier. And will have to think on it a bit to decide what the best way to implement that would be. |
|
You might be able to trick xrdp. I haven't tried it myself. But if you do a The container users themselves don't have any passwords by default. And I can't think of a clean way to make it synced with the users password or anything like that. |
|
I didn’t try it yet.
Isn’t there a default password for root?
… On 1 Mar 2021, at 17:23, Avi Zimmerman ***@***.***> wrote:
You might be able to trick xrdp. I haven't tried it myself. But if you do a passwd while in the session, can you then login with that password?
The container users themselves don't have any passwords by default. And I can't think of a clean way to make it synced with the users password or anything like that.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Nope - should be locked by default. But again you can set it by executing But then xrdp has other weirdies you might run into along the way. Namely I'm very curious how it would react to no virtual monitors to work with. These are the sorta features that led me to ultimately go for adding QEMU support. We are stretching the bounds of what a container can do here. I like the idea of having container templates for simple workloads, and QEMU ones for more complex workloads. |
|
I will try that but it has one big flaw.
The idea for me at least it to provide a remote machine as a service that requires nothing from the end user. So I need to somehow make the xrdp work out of the box.
I can play around with init scripts probably but it would be better to accomplish via deployment. That again brings me to suggest that variables will be possible in the template file. So I can add a CMD that will do the trick for the user with the password stored in the secrets.
… On 1 Mar 2021, at 17:36, Avi Zimmerman ***@***.***> wrote:
Nope - should be locked by default. But again you can set it by executing passwd in the container. Or passwd <user> to set a password for a specific user.
But then xrdp has other weirdies you might run into along the way. Namely I'm very curious how it would react to no virtual monitors to work with.
These are the sorta features that led me to ultimately go for adding QEMU support. We are stretching the bounds of what a container can do here. I like the idea of having container templates for simple workloads, and QEMU ones for more complex workloads.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Again - You are asking for things that are pretty complicated because of the fact that these are just containers. Now you are talking about adding your own CMD, but we need to take into account that You can extend the images. Make a template that uses its own init script. Just make sure it also does everything else the existing one does.
This sorta completely ignores my previous comment. What you are trying is probably not going to work anyway for more reasons related to "you are in a container". What you are trying is what I do want to make possible, and to do so I think the cleanest approach is the QEMU support. Like I said above, containers are for simple workloads. When you start getting into more customization and wanting multiple monitors, multiple services on many ports, more complex volume configurations, this list goes on. You need a VM. The intent is for the end-user experience to remain identical. They wouldn't know if it's a container or a VM backing their session. They would just see that some templates offer WAY more features than others. The grind of it would still remain strictly in admin territory. |
|
That isn't to say any of the fundamental APIs available to QEMU templates won't be available to container templates. Just that they would work far better and be way more stable in the former. |
|
I see. I agree that a client app will be the bomb since you will have allot more options. |
When I am trying to expose the pod with:
kubectl expose pod hanan -n kvdi --name=hanan-svc --type=LoadBalancer --port=22 --target-port=22
I get an ip but even after installing sshd and making sure its running, I can't ssh to the machine.
The text was updated successfully, but these errors were encountered: