Hacker News Reader

They started on this in the late 2000s when I was an intern there. But there was a lot to untangle. It’s the biggest refactoring job you can imagine. A decade long effort.

Back then they didn’t really understand the point of ssh though. They had a vision of remote management via .net RPC and powershell.

I dont know if that means they didnt understand it. It reads like they were trying to solve the underlying problems with a different approach.

SSH is an awesome tool & capability as a relatively high level network channel. The defacto “shell” approach leads to a lot of problems when used as a management device. It encourages adhoc, unstructured, and opaque changes. Managing your hosts via Secure Shell simply leads to bespoke, unrepeatable, outcomes and crushing debt.

Moving to a well structered, repeatable, management paradigm is the only way to survive large or long term deployments. I see “systems configuration” and “orchestration” as the most common ways to achieve that. Personally Ive been trying to move linux/bsd host management off of SSH for 10 years now. I will be very very happy when SSH shell instantiations approach zero per day.

> Managing your hosts via Secure Shell simply leads to bespoke, unrepeatable, outcomes and crushing debt.

SSH is not for management. SSH is for remote access. What people do with their remote access is not SSH's concern. Ad-hoc management is just as possible and easy via RSAT and PowerShell. Hell, I've seen management via ansible devolve into a mess of unmaintainable, unrepeatable script heap.

> Moving to a well structered, repeatable, management paradigm is the only way to survive large or long term deployments.

And how would such a paradigm remotely access the machines? The tool I use uses SSH for:

1. Running commands on remote machines, interactively & non-interactively;

2. Synchronising files on remote machines, via SFTP and Rsync;

3. Forwarding network ports to provide secure access to remote services, e.g. Redis.

Personally, I've been trying to move app deployment and debugging onto SSH in every team I've worked with, and I will be very happy when developers are able to treat a remote machine (development or production) as little more than just a well-managed local machine.

I tried to distinguish between SSH the multiplexed secure network channel provider and Secure Shell, the default and overwhelmingly popular use case of SSH. Theyre different, but generally conflated. I have no real problem with the transport mechanism.

To answer your questions you probably have a dedicated on host agent. See MCollective or AWS SSM for examples Im familiar with. It doesnt really matter that the transport or message model is. Its more important that your actions are discrete, well modeled, with defined & structured inputs and outputs. Its also inportant that theres an intermediary so you can get the scope of control away relying on client and end hosts.

For #1 interactive is almost orthoganal. For #1 & #2 Its that you have structure, repeatability, validation, auditing, testability, etc. #3 again a transport problem, or similar.

For your last point my issue is if you treat dev and prod as similar change and access problems. The environment can certainly look or feel the same. But the output of dev should be discrete managed artifacts. If you need to do adhoc exploratory stuff on prod thats a good sign you lack control or valid synoptic model of your systems.

That said, we may be trying to solve different problems. I have lots of teams, more ICs, and many hosts. Getting from artifice to industry is important at some point.

Edit: go check out the mcollective demos to get an idea of how you can change the access/use model.

They already had group policy for structured administration. What Windows was missing specifically was a non-GUI way for that unstructured "get in there and fix the problem" work flow. Structured workflows may well be better for you, but quick and dirty has a lot of appeal.

Sometimes you just have to give people the candy they want - even if its not good for them.

Group Policy can't manage Exchange, Active Directory, etc - prior to the introduction of Powershell you were at the mercy of what was provided with the RSAT and RDP for anything else.

> "get in there and fix the problem" work flow

Isn't this an anti-pattern considering the cloud tenants of treating machines as cattle not pets?

Windows had this problem much earlier with every employee getting a PC on their desk. They solved it with Group Policy and domains. That still works well.

SSH and Remote Desktop solve a different problem. It may not be the one you have - but some of us just need to log into the machine because we have needs that don’t fit into some predefined workflow. Or we have so few boxes it’s not worth it.

Consider SSHing into a large build machine for compiling as an example.

Cloud is irrelevant. Its scope and repeatable results. A decade ago I had these problems with owned facilities, owned hardware, and dedicated internal teams. But it was thousands of hosts, multiple datacenters, and thousands of internal users. My personal break point is/was “a few hundred” hosts. Below that bespoke management can scale at a reasonable human:resource ratio. Above that you need too many people, and then you cant control or inspect the rate of change or variance.

Where does your opinion on Ansible lie then? It's a systems configuration and orchestration tool that by default, uses SSH as the transport.

For Ansible users, Windows getting OpenSSH is a huge win, since we (presumably) will no longer have to jump through all the hoops WinRM throws you in order to configure Windows machines remotely.

See sibling. I dont have a problem witb using ssh as transport per se. Its using adhoc/bespoke Shell for introducing change. Its a bit unrelated but I, personally, lean more towards declarative than procedural and highly value intermediated access. Which doesnt quite match ansible afaik.

Right, so your issue is with shell access and using it for arbitrary systems changes then, and not SSH per se. You'd be just as annoyed if someone logged into a shell on the server via the console and started making unmanaged changes.

SSH was originally intended to replace the aging unencrypted protocols that were used for remote access (telnet, rsh etc). It comes from a time when configuration management tools like ansible, puppet et all didn't exist, and most system management was ad-hoc, or done by home grown scripting. So it makes a sense that it behaves the same way as rsh for the most part.

WinRM (which this Microsoft implementation of OpenSSH will replace for most Ansible/UNIX users that are managing Windows systems) also allowed arbitrary command execution as well, so it was really no better.

> Back then they didn’t really understand the point of ssh though.

As an outside observer, it really looked to me like Microsoft had their head in the clouds up until about 2011. It's like the whole decade between 2005-2015 for MS was about recognizing and coming to terms with the multiple "whole worlds out there" and getting past NIH syndrome.

They understood the GUI couldn’t be everything but NIH was definitely in full swing at that time. It was enforced from the top: If you wanted to use an external product and MSFT had a competitor you needed VP approval. Same went for Open Source. Only the most senior people would even attempt it, and it was understood they were spending political capital.

The one place this didn’t apply was your choice of code editor. You could use whatever you wanted and that had long been tradition. I spent a lot of effort getting VIM to work only to realize it didn’t scale well to multi-million LOC code bases.

As someone who uses Vim on relatively large files daily (500k - 1.5M lines), where were the hangups?

The speed of navigating the code base. Ctags existed but people using SlickEdit or Source Insight were able to navigate the code base dramatically faster. As a new hire I wasn't going to get code annotations emitted as part of the build, so an editor with a proper parser was key.

Really had nothing to do with the size of the file.

To be fair to Kodak, it is very hard to invent digital photography but fail greatly to use it. Or Xerox, ... or IBM who is the largest PC seller exactly the time when it was overwhelmed by Microsoft.

An organisation large enough would have middle management and people who promote from within. And they are successful in one culture and it worked even for customers.

Then ...

This makes you seem like you don't understand the point of PowerShell remoting.

Passing serialised scriptblocks to the remote host, executing them, and getting serialized objects back. Meaning you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection.

Because it's integrated into the language, you can pull PowerShell modules over from the remote host to the local host automatically generating proxy stubs for them ("implicit remoting"). E.g. to manage and Exchange server you can remote to it, and bring the Exchange cmdlets back, and then import them locally as if they were a local module.

It's also able to do that and edit the proxies as it builds them for you, to allow and restrict what commands you get - based on your permissions and perhaps which tier of service you're paying for. And not just allow or restrict commands, but allow or restrict individual parameters on those commands, if desired.

you can pass serialisable objects around, handle errors, the multiple output streams, etc. over the remoting connection.

That's fine in theory, except that some very common Windows Objects can't be serialized in any meaningful way (most painful one for me being the Windows Update Client), which means that certain "remote" operations are actually affecting the client machine, or are failing because the client lacks support for certain operations.

I've been using Powershell since v2, but to me, it's essentially a walled garden automation environment. Just one more way for Microsoft not to give you the tools to efficiently manage your fleet.

How is that different from SSH? You can't serialise open sockets and pull them back over an SSH connection either.

a) I think the normal use is something like SCCM or InTune to automate Windows Updates, not manually connecting to a machine and trying to script the Windows Update Client.

b) Microsoft built Azure Stack with PowerShell automation. Are you saying Microsoft refused to give themselves the tools to efficiently manage their own fleet? What tools even are these?

The mental overhead of this is much higher than the concept of “I’m logged in to this remote machine - all actions happen there”.

That’s why I can guarantee Remote Desktop has more usage than these remote rpc calls for ad-hoc work. Powershell is quite powerful but it’s features are more for programmers than users.

Because of its complexity RPC is not a replacement for ssh where you are typing commands directly to the remote machine.

Is Enter-PsSession not "I’m logged in to this remote machine - all actions happen there"?

If I had to define one underlying architectural difference between UNIX and Windows, it's that Windows uses RPC (and some other kinds of structured communication) where UNIX uses pipes. This has advantages if you're Microsoft and developing both ends, but in most other cases it's a huge disadvantage to discoverability and transparency.

This is partly why nobody developed proper open source Exchange clients: the Exchange protocol is MAPI over DCE/RPC, and you need to build a lot of infrastructure before it will even talk to you.

OpenChange tried to build an exchange server, and it worked to a certain extent, but it's now dead I believe. Keeping up with the recent protocol changes in Exchange was too much, though ironically with the REST and MAPI over HTTP (not RPC over HTTP), it should be a lot easier to create an exchange replacement.

Samba still does amazing stuff on the directory RPC front.

The point of ssh is that I can easily manage some Windows boxes from a Linux server.

A customer of mine fires up servers to run tasks on them. A few of those tasks are programs that unfortunately run only on Windows (the pain of updating those boxes!) I install ssh to be able to perform some basic operations on them and move files over sftp. Hopefully an integrated ssh server works better (issues with terminal, etc.)

I understand that this is not a scenario Microsoft would advocate in the past, but eventually Microsoft lost the war for servers so it's giving us interoperability tools now.

I’ve been developing on and for Windows for 20 years and just started doing anything with Linux earlier this year.

If you told me I had to do anything advanced with Windows using only a CLI, I wouldn’t know where to start. On the other hand, I could maneuver my way around a bash shell. I haven’t thought about that before now.....

I think it's time for MS to develop a new ANSI/VT-compliant, text-oriented shell (to complement PowerShell, which is largely object- and API-oriented). There ought to be a default shell worth using on the other end when you ssh into a Windows server :)

cmd.exe and DOS were both text-oriented but extremely buggy and inconsistent. Perhaps MS could just focus on providing a very bash-like language (perhaps even include gnu utilities) while supporting the major interactive use cases for cmd.

Why would they do that when Powershell is literally that, but refined beyond what's commonly available on Linux?

I'm not great with it yet, but it feels intuitively like a step forward to be able to pass objects around instead of spending so much of my time using awk-ward 40 year old tools to tease text out of various fields.

PowerShell is great for when you want to interact with Windows APIs (local and remote) and/or work with objects. I have no problem with using it for those purposes.

But terminals and the tooling around them have always revolved around text. My point is that since Microsoft is (a) including OpenSSH, (b) upgrading their terminal infrastructure to support VT100 and ANSI codes, and (c) investing in WSL, it would make make a lot of sense to add a Windows-native shell that is more text-oriented. Not because I hate working with objects and APIs, but because plain text ought to be the primary, first-class supported data format when working on a terminal.

PowerShell is great, but it's an object-oriented (not text-oriented) shell.

> But terminals and the tooling around them have always revolved around text

That's because they're from the 70s, when literal terminals with no real computing power were connected to a centralized system that did all the work. They're archaic and silly.

> They're archaic and silly.

They may seem that way to some, but they still provide a surprisingly versatile and useful user interface. Terminal programs and scripts are easy and fast to write, easy to interact with, easy to change, and trivially portable across POSIX platforms; hence, when writing a tool for oneself or another developer, most developers will usually opt for a CLI-based UI. Terminal program UIs are also very stable (in addition to being text-based), making them arbitrarily composable into scripts and workflows without fear of them breaking in the future.

Modern graphical UIs are usually easy to use, but they are far-removed from the code and tools that are used to write them or interact with their APIs programmatically. Terminal program UIs, however, are very close to the environment they're built in -- so the line between using a terminal program and interacting with it programmatically is delightfully blurred.

I use a multi-paned iTerm2/zsh window every day as a front-end developer (I'm on a Mac running macOS Mojave). I can't imagine working without it. There are a lot of good reasons npm, git, and other popular mainstays in modern development workflows are terminal-based.

Terminal is not the same thing as CLI or TUI. I don't have a problem with either of the latter interfaces, I have a problem with archaic emulation of long obsolete hardware with in-band signaling.

Sorry, misunderstood. Yes, VT100 is rather archaic. Is there a more modern alternative?

A modern console would use out of band signaling for things like cursor position, colors, size changes, etc. Windows consoles work like that using API calls, which is perhaps not ideal for quickly hacking things together but at least doesn't wig out on you if something throws arbitrary bytes into the stream.

However it is far too verbose and without aliasing everything it's a big pain in the a to use.

> I think it's time for MS to develop a new ANSI/VT-compliant...

They are doing exactly that: https://blogs.msdn.microsoft.com/commandline/2018/08/02/wind...

That’s not a shell. Pwershell, bash, and zsh are shells. A TTY/PTY is the infrastructure on top of which a shell runs.

The point was that there wasn't much they could do to make nicer shells if the backing text infrastructure was poor.

Right, but my point was that now that they've done the work on the infrastructure, a bash-like native Windows shell would be really great.

I doubt you'd see Microsoft reinvent the wheel here. They'd more likely work to give WSL more ability to interact with Windows, and then let you just use that shell if you want to.

How likely is it that MS will include and enable WSL by default on Windows Server just to provide a better default shell for terminal and ssh users?

If I were a server admin, I’d probably turn all of that off because it’s more attack surface area. And cripple myself in the process. For that reason alone, I think a new shell is probably more likely to be helpful.

You start with PowerShell and MSDN. Type "Get-" and start guessing at the thing you want to interact with and hit tab to see what's available.

Shameless plug: There's also remote GUI support through Windows Admin Center. You can manage your headless server through the browser on your workstation. It's also a good way to learn CLI-based management (the implementation is almost all powershell scripts, and there is a "show script" feature) https://docs.microsoft.com/en-us/windows-server/manage/windo...

Still doesn't do AD and DNS etc. So I'm still RDPing from my Mac to get access to RSAT.

I think it's more a compatibility thing than an original desire for more CLI. All that deployment tooling built on top of scp, protocols like git over ssh. Without ssh, Microsoft would forever be out of that game. Those things are definitely not "not CLI", but the CLI question is not in focus.

I am not aware that windows is rendering any pixel while no active desktop session is launched. You have less binaries and probably a smaller memory footprint without desktop but I would be surprised if the performance difference was material.

How does RSAT compare to the new Windows Admin Center?

The Windows Admin Center currently doesn't cover everything that the RSAT does, notable omissions include anything related to Active Directory.

Personally, the Windows Admin Center is a nice-to-have tool for quick tasks by inexperienced or occasional admins - but you really should just learn Powershell.

WAC is a lot like the new settings panels Microsoft keeps pushing. Bloated and with half the functionality of their predecessor.