FQDN not Resolving
-
@johnhooks I already set it up where I don't use SSH.
-
@johnhooks said:
@Dashrender said:
@johnhooks said:
@JaredBusch said:
@johnhooks said:
You could also put an SSH tunnel in front. SSH into a VM and tunnel 3389. I do the same thing for my container VDI, just port 22 instead of 3389.
That is not useful for an RDS deployment. RDS deployments are meant to be either public to the LAN or public to the WAN. that is really the point of using RDS.
How is that any different than using RD Gateway or a VPN?
I guess I've never heard of using SSH as a VPN for other things.
Ya you can do
ssh -L 8080:<rdphost>:3389 user@host
and it will tunnel 3389 on the remote host to 8080 on your localhost. Plus it's fully encrypted this way.One good random use for it is if you're behind a proxy and you need to get to a site, you can do the same thing.
ssh -L 8080:sitename:80 user@host
and then visit localhost:8080 and you'll be at the site.Does that work on Windows?
I fully understand how this works on Linux (though I don't see the need to use RDS on a Linux GUI - if you have Linux on your desktop - aren't you more likely to be using PowerShell or other shell access solutions for your Windows boxes?
So I'm trying to understand the use case.
-
@Dashrender said:
@johnhooks said:
@Dashrender said:
@johnhooks said:
@JaredBusch said:
@johnhooks said:
You could also put an SSH tunnel in front. SSH into a VM and tunnel 3389. I do the same thing for my container VDI, just port 22 instead of 3389.
That is not useful for an RDS deployment. RDS deployments are meant to be either public to the LAN or public to the WAN. that is really the point of using RDS.
How is that any different than using RD Gateway or a VPN?
I guess I've never heard of using SSH as a VPN for other things.
Ya you can do
ssh -L 8080:<rdphost>:3389 user@host
and it will tunnel 3389 on the remote host to 8080 on your localhost. Plus it's fully encrypted this way.One good random use for it is if you're behind a proxy and you need to get to a site, you can do the same thing.
ssh -L 8080:sitename:80 user@host
and then visit localhost:8080 and you'll be at the site.Does that work on Windows?
I fully understand how this works on Linux (though I don't see the need to use RDS on a Linux GUI - if you have Linux on your desktop - aren't you more likely to be using PowerShell or other shell access solutions for your Windows boxes?
So I'm trying to understand the use case.
Yes, with PuTTY. But even if you are on a Linux desktop or laptop, wouldn't you want RDP access from that? Maybe I'm misunderstanding you. This is just so you can access RDP remotely inside your network.
-
@Dashrender said:
@johnhooks said:
@Dashrender said:
@johnhooks said:
@JaredBusch said:
@johnhooks said:
You could also put an SSH tunnel in front. SSH into a VM and tunnel 3389. I do the same thing for my container VDI, just port 22 instead of 3389.
That is not useful for an RDS deployment. RDS deployments are meant to be either public to the LAN or public to the WAN. that is really the point of using RDS.
How is that any different than using RD Gateway or a VPN?
I guess I've never heard of using SSH as a VPN for other things.
Ya you can do
ssh -L 8080:<rdphost>:3389 user@host
and it will tunnel 3389 on the remote host to 8080 on your localhost. Plus it's fully encrypted this way.One good random use for it is if you're behind a proxy and you need to get to a site, you can do the same thing.
ssh -L 8080:sitename:80 user@host
and then visit localhost:8080 and you'll be at the site.Does that work on Windows?
I fully understand how this works on Linux (though I don't see the need to use RDS on a Linux GUI - if you have Linux on your desktop - aren't you more likely to be using PowerShell or other shell access solutions for your Windows boxes?
So I'm trying to understand the use case.
SSH is just another way of setting up an SSL VPN. It's extremely common. Not OpenVPN common, but very common.
-
@johnhooks said:
Yes, with PuTTY. But even if you are on a Linux desktop or laptop, wouldn't you want RDP access from that? Maybe I'm misunderstanding you. This is just so you can access RDP remotely inside your network.
How does PuTTY give you this on a Windows machine? When I'm running PuTTY on my windows machine, I'm connecting to another server, not my local host. There's nothing local about it.
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
-
@Dashrender said:
@johnhooks said:
Yes, with PuTTY. But even if you are on a Linux desktop or laptop, wouldn't you want RDP access from that? Maybe I'm misunderstanding you. This is just so you can access RDP remotely inside your network.
How does PuTTY give you this on a Windows machine? When I'm running PuTTY on my windows machine, I'm connecting to another server, not my local host. There's nothing local about it.
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
There is a tunnel section in PuTTY to set the tunnel up. Once the tunnel is set, you RDP to localhost:8080 which tunnels you through the SSH server to the RDS server at port 3389.
-
@Dashrender said:
How does PuTTY give you this on a Windows machine? When I'm running PuTTY on my windows machine, I'm connecting to another server, not my local host. There's nothing local about it.
Putty on MY Windows desktop will set up a VPN link, yours will too. In fact, it ALWAYS does that. You just are not used to thinking about it that way.
-
@Dashrender said:
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
Actually that is where it is run. It's just done from the GUI.
-
@johnhooks said:
But even if you are on a Linux desktop or laptop, wouldn't you want RDP access from that? Maybe I'm misunderstanding you. This is just so you can access RDP remotely inside your network.
Sure I suppose you might want RDS access via your Linux box while away from the office, it just seemed like a fringe case.
What are the chances that you're going to have Linux as the Desktop OS you're running and you want to RDS into a Windows box? My assertion is that person would probably, more like want to use command line tools to manage their Windows box. But just because the norm is that, doesn't mean we shouldn't talk about alternatives
-
@scottalanmiller said:
@Dashrender said:
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
Actually that is where it is run. It's just done from the GUI.
I don't understand, please explain.
I do understand that the PuTTY client itself has it's own VPN connection via the SSH. What I'm trying to understand is how are you telling windows to do the port forward?
-
@Dashrender said:
@johnhooks said:
But even if you are on a Linux desktop or laptop, wouldn't you want RDP access from that? Maybe I'm misunderstanding you. This is just so you can access RDP remotely inside your network.
Sure I suppose you might want RDS access via your Linux box while away from the office, it just seemed like a fringe case.
What are the chances that you're going to have Linux as the Desktop OS you're running and you want to RDS into a Windows box? My assertion is that person would probably, more like want to use command line tools to manage their Windows box. But just because the norm is that, doesn't mean we shouldn't talk about alternatives
You don't need Linux box though, you can do it from Windows. Arguably it's easier with PuTTY since you can save the session preferences (I say arguable because you can make a script to do it on Linux).
Say you have a user that needs to work from home every once in a while. Isn't it cheaper to give them a chromebook to access an RDP session than to give them a full Windows laptop to use an RDP session?
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
Actually that is where it is run. It's just done from the GUI.
I don't understand, please explain.
I do understand that the PuTTY client itself has it's own VPN connection via the SSH. What I'm trying to understand is how are you telling windows to do the port forward?
It's in the tunnel section.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
Actually that is where it is run. It's just done from the GUI.
I don't understand, please explain.
I do understand that the PuTTY client itself has it's own VPN connection via the SSH. What I'm trying to understand is how are you telling windows to do the port forward?
SSH is, like anything of its type, a form of VPN in and of itself. If you use SSH, you are a VPN client under the hood.
-
@Dashrender said:
@johnhooks said:
Yes, with PuTTY. But even if you are on a Linux desktop or laptop, wouldn't you want RDP access from that? Maybe I'm misunderstanding you. This is just so you can access RDP remotely inside your network.
How does PuTTY give you this on a Windows machine? When I'm running PuTTY on my windows machine, I'm connecting to another server, not my local host. There's nothing local about it.
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
You can also do the reverse with ssh -R. This will allow you to connect a local port to a remote port on another system. A simple use case for this would be you are working on a web site locally and want to show someone else really quickly. They can open localhost:8080 on their remote system and see your site on their end. You don't have to use 8080 in these scenarios, just a port I picked.
-
@Dashrender I wanted to do a quick demo for you. This is on my Chromebook, but I used the default SSH app, because most people aren't going to have it set up the way I do. I used ChromeRDP and attempted to connect to 127.0.0.1:8080 to show it wouldn't work, then connected normally to my Server 2012. Then, I ssh with tunneling and connect to Server 2012 at 127.0.0.1:8080.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
Actually that is where it is run. It's just done from the GUI.
I don't understand, please explain.
I do understand that the PuTTY client itself has it's own VPN connection via the SSH. What I'm trying to understand is how are you telling windows to do the port forward?
SSH is, like anything of its type, a form of VPN in and of itself. If you use SSH, you are a VPN client under the hood.
Yes I understand that.. but how does PuTTY put itself into the network stack to do a redirection?
A normal VPN does exactly that - it inserts itself into the network stat and redirects as needed.
I think an SSL VPN client requires local admin rights to be able to do the same thing, but ON Windows, I know that RDS/RDP also has a way of tying into a browser to encapsulate the traffic into the SSL tunnel, but really only RDS, not other applications running on Windows, say the accounting softtware - that would require a full blown VPN Client install, or a SSL VPN client that did the same as the full blown one, and installed itself into the network stack.
Are you guys saying that PuTTY has a way to insert itself into the network stack?
-
@johnhooks said:
@Dashrender I wanted to do a quick demo for you. This is on my Chromebook, but I used the default SSH app, because most people aren't going to have it set up the way I do. I used ChromeRDP and attempted to connect to 127.0.0.1:8080 to show it wouldn't work, then connected normally to my Server 2012. Then, I ssh with tunneling and connect to Server 2012 at 127.0.0.1:8080.
But Chromebooks are based on Linux, so it's not the same as doing it on windows.
So with Chromebooks I totally understand how this is working... you are opening a terminal session to your local machine.. then running a command which will interact with the network stack.
-
@Dashrender said:
Yes I understand that.. but how does PuTTY put itself into the network stack to do a redirection?
A normal VPN does exactly that - it inserts itself into the network stat and redirects as needed.
No, that's not how they work
-
@Dashrender said:
@johnhooks said:
@Dashrender I wanted to do a quick demo for you. This is on my Chromebook, but I used the default SSH app, because most people aren't going to have it set up the way I do. I used ChromeRDP and attempted to connect to 127.0.0.1:8080 to show it wouldn't work, then connected normally to my Server 2012. Then, I ssh with tunneling and connect to Server 2012 at 127.0.0.1:8080.
But Chromebooks are based on Linux, so it's not the same as doing it on windows.
So with Chromebooks I totally understand how this is working... you are opening a terminal session to your local machine.. then running a command which will interact with the network stack.
How does being Linux or Windows change anything? What makes you feel that one is unique in how this works?
-
@Dashrender said:
I think an SSL VPN client requires local admin rights to be able to do the same thing,
Think about the fact that every HTTPS web page has a VPN tunnel opened by the user. They are able to open that channel without needing admin rights. Same here.