In which @Captain is confused by Windows
-
@ben_lubar X11 can be used for remote access. Therefore, yes, it is a problem.
If you happen to be using it locally, then it's not. But since it can be used remotely, it sure as shit should be secure by default. And right now it's not.
-
@blakeyrat said in In which @Captain is confused by Windows:
But since it can be used remotely
In X11's architecture, the server is the computer connected to the monitor and the client is the program running on the computer. And unless you're using SSH tunneling, there's no way to have those two computers be different.
And if you are using SSH tunneling, there's your encryption and authentication.
-
@ben_lubar said in In which @Captain is confused by Windows:
In X11's architecture, the server is the computer connected to the monitor and the client is the program running on the computer.
The communication is via a network link. Yes, I agree, 99.5% of the time the network address is "localhost" and it's all local and yay. But that doesn't change the fact that X11 can be used for remote access, and because it can, should be properly designed to be safe and secure.
@ben_lubar said in In which @Captain is confused by Windows:
And unless you're using SSH tunneling, there's no way to have those two computers be different.
My understanding is that that is not true.
Even if it was, SSH tunneling is too fucking difficult and that requirement places the functionality out of reach but all but the geekiest of user, so my opinion hasn't changed.
-
@blakeyrat said in In which @Captain is confused by Windows:
SSH tunneling is too fucking difficult
ssh -X username@remotehostname
Seriously?
-
@flabdablet I would QFT, but it's a huge post, so instead I'll just post this.
That's probably the best high-level overview I've read on this topic.
-
@ben_lubar said in In which @Captain is confused by Windows:
ssh -X username@remotehostname
Yup!
I mean it sounds easy if you utterly ignore the fact that before you run that command (and it is a command with no GUI, natch, because why make anything easy?) you have to run a bunch of difficult gibberish commands like:
ssh-keygen -t rsa -C "plop@horseshit.com"
Then somehow transfer the contents of the resulting file to the remote machine without using the normal method of transferring files to remote machines, because that doesn't work yet because you haven't finished setting up SSH.
Seriously, Ben L, at this point I think you're just trolling. If you think SSH setup is accessible to novice computer users, you're either utterly out-of-touch with all of humanity, or just fucking lying to be a little snot to me. I hope it's the former, but either way: get a grip.
-
@blakeyrat said in In which @Captain is confused by Windows:
@ben_lubar said in In which @Captain is confused by Windows:
ssh -X username@remotehostname
Yup!
I mean it sounds easy if you utterly ignore the fact that before you run that command (and it is a command with no GUI, natch, because why make anything easy?) you have to run a bunch of difficult gibberish commands like:
ssh-keygen -t rsa -C "plop@horseshit.com"
Are you intentionally complicating things?
ssh-keygenon its own is perfectly fine for that. You don't need a useless comment or the default value of an argument specified for no reason.
-
@ben_lubar If you Google "setup SSH" that's what appears. So now you're saying the default instructions that come up with you google the task you want done are wrong, while simultaneously arguing that setting up SSH is easy.
This... doesn't hurt your brain at all? Twisting it in two different directions like that?
-
@blakeyrat come to think of it, since you're comparing SSH to RDP, we may as well just skip the key and use password authentication because that's what RDP uses.
-
@blakeyrat said in In which @Captain is confused by Windows:
Even if it was, SSH tunneling is too fucking difficult and that requirement places the functionality out of reach but all but the geekiest of user, so my opinion hasn't changed.
But I'm not a "user" on this network. I'm the administrator, trying to administer. And the information I want is in the middle of some GUI workflow in some GUI machine, which means that I have to (possibly) change the state of the machine to find information so that I can be sure all the relevant configurations are in sync.
Maybe PowerShell would be ideal, but none to few of the Microsoft tutorials use it so that is too hard, given the project-oriented nature of the work. It is certainly much harder than figuring out SSH once, and then reading through and doing a "just works" tutorial that covers all the basic configuration steps for a service.
And, by the way, none to few of the Microsoft enterprise IT tutorials "just work" either. Something is always missing.
-
@ben_lubar said in In which @Captain is confused by Windows:
@blakeyrat said in In which @Captain is confused by Windows:
X11, have zero encryption and zero authentication by default
I'm not sure why you think that's a problem. Does the Win32 graphics API encrypt your pixels on the way to your monitor?
Let me introduce you to HDCP...
-
@ben_lubar said in In which @Captain is confused by Windows:
And unless you're using SSH tunneling, there's no way to have those two computers be different.
False.
-
@blakeyrat said in In which @Captain is confused by Windows:
since it can be used remotely, it sure as shit should be secure by default. And right now it's not.
This is a really good example of exactly the kind of thing I'm talking about.
The way you're presenting it, you expect a remote desktop protocol to solve every problem associated with accessing a computer remotely. But here's the thing: most of those problems already have solutions that can be applied in exactly the same way to a large class of related use cases.
The thing that RDP does really, really well is ship GUI interaction over one bidirectional byte stream connection. It does that better than most other protocols. It does it way better than VNC.
Everything you've said about making RDP usable by n00bs are points well taken, but here's the thing: there's no reason at all why MS had to reinvent well-known, readily-available techniques for setting up and securing the bidirectional streams that RDP ships its bytes over. It could have been done in a manner completely equivalent to what actually ships as the RDP suite, just by bundling a core RDP protocol with existing connection and security technologies.
That way, long suffering netadmins would be able to use everything they already know about hooking up and securing bidi byte streams for other purposes to set up and secure them for RDP as well. And if their first exposure to that stuff happened in the course of setting up RDP, they would walk away with new knowledge that's generally applicable.
Why have an "RDP connection broker" when you could just have a connection broker? Why have an "RDP load balancer" when you could just have a load balancer?
Note well: I am not complaining about anything I perceive to be a deficiency in RDP specifically. In fact you can (and I just have) run it perfectly satisfactory over the general-purpose secure tunnels provided by other mechanisms (ssh, in my case). The fact that you can't avoid the overhead of its own native encryption while doing this doesn't really matter in 2016.
What I am doing is using RDP as an example of the contrast between Windows systems thinking, where every facility must be seen to sport every conceivable feature to avoid being perceived as inadequate, and Unix systems thinking where solving single problems well is the main aim and completeness is far less important than composability with minimal glue.
Nobody with a Unix mindset would ever entertain the thought of exposing a raw remote desktop protocol to the wider Internet, any more than doing the same thing with a raw file serving protocol or a raw database access protocol. All of these pipes require condoms, and there's a wide variety of those available.
In the Windows world, though, exposing RDP to the Internet is just fine. Not that there's anything wrong with that, but it does encourage people to take the same risk with, say, CIFS/SMB - and that's not even slightly fine even though CIFS/SMB also has its own kind of "security" designed in.
The main advantage of separating the act of securing a pipe and the act of making what flows over it useful is that those two things can be improved completely independently, and those improvements benefit all the cases where each of those things is done. It's the same basic reason why DLLs are a still a better thing than statically linked executables, even though the original motivation (saving storage) is completely obsolete: fixing a bug in a DLL fixes it in everything that links to that DLL.
-
@flabdablet You're basically arguing, as far as I can tell having barely read any of that wall of text, that Microsoft should have focused on making their product great for the 0.05% of people who are system administrators and fuck everybody else.
-
@ben_lubar said in In which @Captain is confused by Windows:
unless you're using SSH tunneling, there's no way to have those two computers be different
Totally not true. I've run X11 unencrypted over a trustworthy LAN and it works fine.
-
@blakeyrat said in In which @Captain is confused by Windows:
I mean it sounds easy if you utterly ignore the fact that before you run that command (and it is a command with no GUI, natch, because why make anything easy?) you have to run a bunch of difficult gibberish commands
I don't think ssh asking for a password before you've got your id_rsa files sorted out is any worse than RDP whining about self-signed certs before you've got your server PKI nailed down.
For what it's worth, each of my end users gets a folder they can take home on a USB stick, and they're told to double-click "schoolname-theirdomain-theirname" inside that folder, and that launches a fullscreen RDP connection tunneled over ssh using an individually revocable key that they don't even know exists. And setting that up was less trouble for me than messing about with SSL certs could ever hope to be.
-
@blakeyrat You can read and comprehend my wall of text, or you can keep your ill-informed opinion about something that bears no resemblance to my point. Entirely your call.
-
@blakeyrat said in In which @Captain is confused by Windows:
@flabdablet You're basically arguing, as far as I can tell having barely read any of that wall of text, that Microsoft should have focused on making their product great for the 0.05% of people who are system administrators and fuck everybody else.
No, he's literally not.
He is explaining the difference in philosophy between Microsoft's all-in-one approach and the Unix multiple tool philosophy. Each of which has advantages and disadvantages.
-
@ben_lubar said in In which @Captain is confused by Windows:
@blakeyrat said in In which @Captain is confused by Windows:
SSH tunneling is too fucking difficult
ssh -X username@remotehostname
Seriously?
That's a unix command. As I understand these things are way harder on windows, because you're not in a preconfigured unix environment and you have to manually align whatever X server and SSH client you installed. I'd assume the GUI VNC clients support SSH tunnelling like they do on linux though.
-
@PleegWat The important thing isn't that they support it, the important thing is that they require it. Otherwise, they're putting their users at risk.
-
@blakeyrat said in In which @Captain is confused by Windows:
@PleegWat The important thing isn't that they support it, the important thing is that they require it. Otherwise, they're putting their users at risk.
There's that fundamental point of difference between Unix and Windows systems thinking again.
Windows thinking: Internet-facing connections are inherently risky. This RDP facility allows end users to set up an Internet-facing point of connection into their machines. Therefore we must build security features into RDP to ensure that users don't end up hurting themselves.
Unix thinking: Internet-facing connections are inherently risky. Here is a tool (ssh) designed to secure any kind of stream-based point of connection into your machine. By the way, it works well with a wide variety of remote desktop access protocols.
The advantage of the Windows approach is that in theory there's less to learn in order to get up to speed with any given single facility. The advantage of the Unix approach is that in practice there's less to learn in order to be able to make a system provide the wide range of facilities that the real world will demand of it, largely because the individual tools are less ambitious and correspondingly easier to master.
In my experience the advantage of the Windows approach is largely theoretical, because IT is just inherently complex and there's only so much of that you can sweep under the rug. The disadvantage is that in order to deal with that complexity when it arises, you need to know how a whole pile of different facilities attempt to solve the same problems over and over again in their own idiosyncratic ways.
Of course, neither system is as purist about this distinction as this distinction might suggest, and you'll easily find examples of special- and general-purpose tools in both. These are cultural tendencies, not hard and fast design principles.
-
@PleegWat said in In which @Captain is confused by Windows:
I'd assume the GUI VNC clients support SSH tunnelling like they do on linux though.
RDP over ssh is completely trivial to set up using a popular Linux remote desktop client (Remmina). Doing it with the official MS RDP client on Windows needs script wrappers.
This is because even inside that single tool, the security wrapper and the desktop protocol are conceptually separate. Remmina provides ssh tunneling to secure VNC and NX (or anything else you can plug into it) and there's simply no good reason not to allow it to be applied to RDP as well.
-
@blakeyrat That has been Microsoft's modus operandi for like 30 years. Too bad they suck at that too.
-
OK question time!
I have a user who is suddenly seeing a pop-up that complains about a missing shortcut.
When she opens a Word document (but only on the first document), a message pops up complaining that
jackie_stewart - Shortcut.lnkis missing. Jackie Stewart was an employee here, many years ago, but he doesn't even have a home directory any more (and hasn't for at least two weeks and probably much longer)The strange thing is, nothing has changed, at all.
Also, I find it strange that Word would "depend" on a random, ancient shortcut.
Any ideas other than wiping the box?
-
@Captain I think you accidentaly something there.
edit: you corrected it before I submitted
-
@Captain said in In which @Captain is confused by Windows:
Any ideas other than wiping the box?
Maybe you got some ancient word macro virus?
-
@groo HI-YAAAAAAAAAAAAAAAA
-
@Captain said in In which @Captain is confused by Windows:
OK question time!
I have a user who is suddenly seeing a pop-up that complains about a missing shortcut.
When she opens a Word document (but only on the first document), a message pops up complaining that jackie_stewart - Shortcut.lnk is missing.Improper add-in? If someone put a shortcut to Jackie's word doc as a macro template thing, this might exhibit this behavior.
Does it have the error message when starting Word in Safe Mode?
-
@Tsaukpaetra interesting question. I'll try it out on Monday.
-
In an unrelated note, i hate wuauserv.exe. trustedinstaller.exe might be on my shit list too.
-
@Captain said in In which @Captain is confused by Windows:
In an unrelated note, i hate wuauserv.exe. trustedinstaller.exe might be on my shit list too.
Yep.
