Holy SSH-it! Microsoft promises secure logins for Windows PowerShell Microsoft has finally decided to add support for SSH to PowerShell, allowing people to log into Windows systems and use software remotely over an encrypted connection. Users of Linux, the BSDs, and other operating systems, will know all about OpenSSH and its usefulness in connecting machines in a secure way to execute commands …
"Hi! I'm SShitty, your personal cute connectivity agent. It looks like you're trying to log in to another computer securely using some brand new key exchange based system we've never heard of before. Would you like me to constantly get in your face while you attempt to do that? "
"Microsoft promises secure logins for Windows PowerShell"
Powershell already has remote secure logins - either via HTTPS (TLS) or via WS-Man (Kerberos).
You seem to be confusing that with the fact that Microsoft have now added support for secure access from legacy OSs that don't support more modern methods...
I'll bite.
SSH was written from the ground up to be secure, unlike HTTPS (or FTPS) where it was basically bolted on top of an existing legacy protocol.
SSH has been the standard login to all other modern server platforms for years.
This just means Windows is finally catching up with existing business practice.
And what does 'from legacy OSs' mean? Most of my SSH sessions are initiated from Windows Desktop using PuTTy, is that the legacy OS your talking about?
Err... I will bite.
The so called "Legacy" (quotes intended) OSs have been able to do Kerberos long before Windows and can still do it today. It is not popular in "Legacy OS" land because it is an admin nightmare in a heterogeneous environment. It used to be crippled by massive export issues before Windows adopted it and its unavailability outside USA is exactly what caused the birth of SSH.
While availability problem is no longer an issue all of the admin problems still are.
Back to your flawed reasoning: the reason why "Legacy" (quotes again intended) OSes cannot connect to a Windows system using their own LEGACY protocol (Kerberos) is that Microsoft deliberately made their implementation non-interoperable when baking it into Win2K circa 1999.
"the reason why "Legacy" (quotes again intended) OSes cannot connect to a Windows system using their own LEGACY protocol (Kerberos) is that Microsoft deliberately made their implementation non-interoperable when baking it into Win2K circa 1999."
Not true. Microsoft Kerberos is fully compatible to replace older Kerberos 5 versions and legacy / *nix OSs can quite happily connect to Microsoft Kerberos. Not the other way round though as Active Directory requires some specific RFC extensions...MIT are slowly catching up though: http://web.mit.edu/kerberos/krb5-devel/doc/mitK5features.html
Not the other way round though
My exact point. Your preliminary condition for interoperability is to throw out everything and put your network 100% under Windows control the windows way or the highway.
That proposition would have had some extremely dubious merit if Microsoft was properly investing into the full compatibility suite for Windows including emulating and mapping to/from NIS, providing NFS to SMB mapping, etc and was honest about it. That never happened - these were always second fiddle, crippled and with one or more caveats deliberately designed to push people from their existing platforms onto Windows.
As a result most people stay away from it. ALL large organizations I know with mixed environments do not use the compatibility services at all. They export AD instead and build NIS maps and various password backends using custom scripting or 3rd party products. The only place where the Microsoft compatibility tools and Kerberos "The Microsoft Way" on Unix/Linux are in use are clueless medium enterprises. Usually not for long too - people get fed up with the limitations and give up.
"if Microsoft was properly investing into the full compatibility suite for Windows including emulating and mapping to/from NIS, providing NFS to SMB mapping, etc and was honest about it. That never happened"
Again wrong. We have been running our NFS on Windows Server for years - its always been fastest - and it was the first fully clustered NFS 4.1 implementation that was commercially available. Coexistence with SMB access has also always been supported.
"ALL large organizations I know with mixed environments do not use the compatibility services at all"
All the ones I have worked (many banks for instance) with use Active Directory / certificate based LDAP authentication for pretty much all infrastructure and small / midrange *Nix systems. Pretty much no one sane uses NIS or NIS+ these days regardless of the provider. I have yet to come across anyone using MIT Kerberos but i'm sure there must be someone...
"Usually not for long too - people get fed up with the limitations and give up."
Yes I noticed that Unix Risc based mid range market share had dropped again...lots of companies are still migrating to SQL Server, etc.
Indeed, if they ship a version of the Bourne shell (for ./configure scripts, etc), start using / for directory separators, add support for symbolic links at the filesystem and UI levels, and do away with silly drive letters in favour of more readable mountpoints (e.g. /mnt/cdrom instead of D: or was it E:?), they'll be at risk of becoming a serious operating system instead of a toy.
Hell, whilst they're at it, native EXT4/BTRFS support would be nice too. I'm sure Apple would love HFS+ support as well, and how about shipping an X server?
This post has been deleted by its author
POSIX more based on Korn and Korn is a lot more viable as a daily driver. As for filesystems what you name is not what comes to mind when I am thinking enterprise UNIX. As for X server according to Poettering and his ilk we should all be using Wayland instead on our laptops (only form factor he cares about) by now.
support for symbolic links at the filesystem and UI levels
Could you expand on that comment? Windows has had symbolic links for a while now and I've encountered them while iterating file system objects and when looking at a folder using Explorer.
It's also had mount points for a while but users don't seem keen on them.
support for symbolic links at the filesystem and UI levelsCould you expand on that comment? Windows has had symbolic links for a while now and I've encountered them while iterating file system objects and when looking at a folder using Explorer.
Seems funny, any time I've browsed an smb:// share on a Linux machine, symbolic links are visible. On Windows Explorer, they look like two completely different files. I also haven't spotted a way to create symbolic links in the UI either.
MacOS X Finder has a "create alias" function which in Unix parlance, is a symbolic link.
It's also had mount points for a while but users don't seem keen on them.
Yes, but plug a USB stick in, where does it get mounted? On a drive letter, and the OS partition is also on a drive letter. Everything else can be mounted as mountpoints, but you'll always have an OS drive letter (probably C:) and one for hotplugged devices.
Contrast this to MacOS X which puts them under /Volumes, or Linux where the modern convention is /media.
any time I've browsed an smb:// share on a Linux machine, symbolic links are visible. On Windows Explorer, they look like two completely different files. I also haven't spotted a way to create symbolic links in the UI either.
I'm not sure about your first two sentences - are they a mis-type? As stated they seem to say the same thing. Not trying to be funny - I'm just unclear. You're right that there's only a command line tool provided by Microsoft though. I guess they've just not seen enough demand to provide a GUI mechanism. Other people have written them though.
Yes, but plug a USB stick in, where does it get mounted? On a drive letter, and the OS partition is also on a drive letter. Everything else can be mounted as mountpoints, but you'll always have an OS drive letter (probably C:) and one for hotplugged devices.
True but what's wrong with that? Again I'm not trying to be funny but it seems to me like you're complaining about Windows because it isn't Unix. We all feel happier working with the tools we know and doing things the way we're used to. Do you have a particular process in mind where having drive letters instead of mount points causes a problem? Personally I quite like knowing when I'm working on a different volume and drive letters usually signal that clearly under Windows.
As for the symbolic links in Windows, ideally source control systems would be able to seamlessly work with symbolic links in both Linux and Windows on the same code base but in my experience that has not been the case. Then again I haven't used Windows 8 or 10 much or played with source control systems on windows in the last few years that much so maybe this is resolved.
>Yes, but plug a USB stick in, where does it get mounted? On a drive letter,
That is the default, although you can, of course, turn that off, and set it to automount inside a folder
>and one for hotplugged devices
That is the default, although you can, of course, turn that off, and set it to automount inside a folder
Sometimes I think that some people think that knowing about Linux gives them some special insight into how Windows works.
"You forgot access to raw devices from the command line. Or is there a way to do that in Windows nowadays?"
Yes, Powershell is like a UNIX shell but much more powerful and with more features - such as being object orientated, supporting true multipath parallel branching and supporting multiple data types - not just text.
And meanwhile /mnt just sits there, unused.
Depends, I use /media for things like USB sticks that are transient devices, and for things like my DVD drive; I have /mnt/cdrom or fileshares /mnt/net/…. Once upon a time I had /mnt/floppy too.
In fact, I think the latter still lives on somewhat. So for me it's /mnt for stuff I configure in /etc/fstab and /media for stuff I mount using pmount.
And meanwhile /mnt just sits there, unused.
And a good thing that it is unused, too, because the FHS explicitly reserves its use for temporary mounts by a system administrator. In other words, it's a directory that has to stay available at all times: its whole purpose is to sit there unused until a sysadmin actually needs it.
3.12. /mnt : Mount point for a temporarily mounted filesystem
3.12.1. Purpose
This directory is provided so that the system administrator may temporarily mount a filesystem as needed.
This post has been deleted by its author
You forgot access to raw devices from the command line. Or is there a way to do that in Windows nowadays? In the same way that I can blank a disk on my OpenBSD machine with
There's nothing in the standard install I don't think but then your typical Windows user wouldn't want it anyway - most of them just don't have any use for it. That the difference between a Windows user and a Unix user and why (I suspect) Linux never came close to pushing Windows off its pedestal. Windows users like the easy life and if they want to take a disk image (if they know what one is) they will use something with a graphical UI of which there are several. Many, possibly. I think most if not all commercial software has the ability to take an image. The default will be to ignore unused areas of the disk but a lot of them allow the user to select a 'forensic' image like DD does. One feature usually present is the ability to put the image back down and adjust the volume to a different disk size.
If someone wants to write the equivalent of DD..well I have done that for both DOS and Windows because I used to write data recovery software. In Windows you use CreateFile() which is the universal 'open a thing wot contains data' API call.
In that article search for 'You can use the CreateFile function to open a physical disk drive or a volume,' if you want the gory details. Note the different paths available:
"\\.\PhysicalDrive0" Opens the first physical drive.
"\\.\C:" Opens the C: volume.
You can open tape drives by using a file name of the following form: "\\.\TAPEx" where x is a number
Once you've got that open you can use SPTI to send SCSI commands using the file handle if you need to get clever. It works on all device types although unsurprisingly IDE drives don't support all commands.
Internally the kernel has a path structure much like the Unix model. The infamous drive letters are actually aliases below the cover with everything being in a folder structure as far as the kernel is concerned. There's a lot more going on under the cover where devices are concerned than most users of Windows realise (or, frankly care about) which is the way it should be. A good OS shouldn't (in my opinion) require users to know anything technical. Same as a car shouldn't require you to know what goes on under the bonnet :)
""A good OS shouldn't (in my opinion) require users to know anything technical."""
Yes, the same argument most people writing badly formatted word and excel documents make when I try to explain why they are having a problem; "I'm not an IT guy, I didn't study IT."
The key difference here is not that there aren't any Windows users/admins who know about how the kernel uses paths internally or that MS is rewriting Win32 into some kind of futuristic sandboxed API wrapper, or that the registry is these days virtualized for legacy apps, or that System32 in a 64bit machine contains the 64bit versions of the OS libraries.
That is not the issue, the issue is that when you compare the majority of Windows admins with the majority of the Unix sysadmins, the Windows ones know very little about computing in general, they are just "windows" users/admins partly because Windows does not expose much of the technical stuff (which is still there lurking in the shadows waiting to bite by the way).
If I had a penny for all the times I had to explain to Windows developers the difference between %HOMEDRIVE% and %SYSTEMDRIVE% I would be retired by now and filthy rich.
Same with Email, same with DNS, same with most basic bits of internet infrastructure.
On the other hand most Linux guys that I know have no problem setting up Windows environments with AD and GPOs and all the usual MS lore, if they do not know how to do so, they may mourn a lot, but they can learn quickly how to do whatever that it is required, most Linux guys I know can deal with switching firewalls and routing, load balancers, VPNs, etc, I know many more Linux sysadmins that understand BGP than I know network engineers, heck I know at least two Linux chaps who understand Hyper-V better than the Windows guys I worked with in my previous job.
I'm not saying Linux guys are know-it-all encompassing wonders, but they tend to know about different subjects and have an interest in technology, not just MS latest fart.
I'm eagerly awaiting the day that windows is all Powershell and no GUI, it is heading that way, I bet that day there will be even less Windows sysadmins.
Disclaimer: I know there are plenty of Linux/Unix ignorants too, I have to deal with them daily.
This post has been deleted by its author
It's funny how little about the true Windows architecture some people know. They would be surprised to know that actually drive letters are just symbolic links to device paths. It's the Windows Shell built around the drive letter metaphor, in the beginning for compatibility reasons.
Download Sysinternals' WinObj utility, and take a look at Windows internal namespace tree, including devices. Windows API can also use device paths with the proper syntax.
1) Powershell already uses forward slashes.
2) Drives can be referenced without drive letters although I give you that they aren't very readable.
i.e. \\?\Volume{ebc79032-5270-11d8-a724-806d6172696f}\
3) You've been able to mount drives as folders anywhere in the directory tree for years.
4) Windows installed in Bootcamp reads HFS+ just fine so drivers are already out there.
5) xming gives you x for windows although I grant you it's not built in.
You did know that Microsoft used to make a Unix, right? It was called Interix, and ran alongside win32 as another personality on top of the Windows NT kernel. It interoperated with win32 seamlessly, so you could combine the win32 GUI with full Posix semantics with processes, sockets, hard and soft links, etc. It even came with gcc. It worked really rather well. It felt very much like an old-school Unix, so Korn shell, an old libc, non-ELF, etc. But it was so, so much nicer than Cygwin. For a while you could even install Debian packages on it.
Unfortunately it never got much maintenance and suffered from institutional rot. Despite being reinvented as Services For Unix, and then Subsystem for Unix Applications (gotta love those names), the last released version was for Windows 8.
More information here: https://technet.microsoft.com/en-us/library/cc779522(v=ws.10).aspx
Win8 download here: https://www.microsoft.com/en-us/download/details.aspx?id=35512
(The actual Posix layer gets shipped in higher end Windowses by default; but you need to install the userland yourself before you can actually do anything with it.)
Yes I'm sure Microsoft wish they never released it. You wonder what Linus would've done if there was no Xenix with all its documentation to replicate all major design decisions from.. I think we can thank Microsoft for Linux.
http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml
Linux has more to do with Minix than Xenix, that's what Linus was using back in the early 90's that inspired his development of this "new kernel for 386 computers" that he announced on comp.os.minix in mid-1991.
Him and Andrew S Tannenbaum had many arguments over kernel design principles.
Xenix more or less lives on in Windows as the OS that gave DOS the concept of directories. Original DOS, and CP/M didn't have directories.
Interix is a joke, a bad one. Did try it, thought it would give me some level of sanity on Windows at the time, was sorely disappointed by the result.
>You did know that Microsoft used to make a Unix, right?
Did you read my post above which was exactly to prevent some know it all from telling me about something I used long ago (guess not). In fact if you want to go even farther back you can say Microsoft Xenix was POSIX before POSIX. Everything full circle, etc.
To be fair, OpenSSH didn't quite exist 20 years ago. SSH has barely existed that long, the company that markets it only coming into existence in December 1995. OpenSSH didn't exist until 1999.
This post has been deleted by its author
I'm on what I expect is probably average spec Win 7 PC (a Lenovo T420).
From click to > prompt, took about 7 seconds for PowerShell
Out of curiosity, Cygwin64 Terminal on the same PC, about 3 seconds from click to prompt.
For reference, this is running on mains, not battery, the spinning rust was not sleeping, and the machine was otherwise idle.
No doubt sticking an SSD would give me a big boost. but that's not likely to happen in any typical corporate environment, as they cost money! (Damn penny pincher's)
I fail to see what the usefulness of this Powershell SSH is unless they come with an updated terminal with full VT100 emulation at the very least.
Also will it integrate with Explorer so it can be used as a VFS/sftp client? What about the server part?
So many questions...
And yes, I think its a trap, MS doesn't acknowledge technologies/formats other than their own unless they want to destroy/screw/muddy them. (check the ISO OOXML disaster) Everything they do is cold calculated.
So far their contributions to the GPL have been a bit lacking, just drivers so they can run Linux Hosts in Hyper-'Vi' more or less decently (not great, just decently) it took them forever and only completed them for kernel integration because Hyper-Vi was building up a reputation of being shit for Linux support. One could overhear some "grunting" about not wanting to look in those checklists they publish every now and then to claim to be superiority to VMWare (Its a redmondian obsession of them) when they did the commits.
I have been thinking that if MS is really so good willed these days they could release an official GPL mstsc.exe client for Linux (impossible and almost redundant now, I know), stop taking over the boot process, stop claiming that a disk format they do not recognize is a non-formatted disk, and cut the crap dictating to OEMs what functionality should they include in the hardware or else they lose the windows sticker and the Windows discount.
This post has been deleted by its author
That's annoying and I agree that Windows should have been more clear about the problem. But creating partition tables and formatting disks probably should require Administrator rights.
Personally I wouldn't touch a hotel Windows machine with a ten-foot bargepole. I kinda 'wub' Windows but I'd have to admit there's too much risk of picking up something nasty and bringing it home. That would hopefully be less of a risk with a Linux box but I'd still not want to do anything on it that involved supplying my own user credentials. I'm sure that keyloggers and the like exist on Linux.
I've no idea if MS have finally fixed this, but it always used to amuse me that if you have more than one partition on a USB stick, Windows would only "see" the first one automatically (well, at least assign a drive letter to it - I guess fiddling with Disk Management manually might allow you to map extra drive letters, but that's probably beyond most people...). Put the stick in a Linux box and all the partitions would be mounted fine automatically...
Does this include scp? I've been writing software and testing it on multiple platforms using VMs, and Windows is a massive pain the arse to work with in a target VM unless you purchase some third party stuff. Having ssh and scp as standard would be a huge improvement.
If Microsoft keeps going in this direction, within a couple of years they'll be announcing that they're binning Windows and replacing it with Microsoft WINE.
Cygwin has a decent ssh/scp. Port fowarding works also. Pick the 32 or 64 bit "setup.exe" to match your windows OS then also add "openssh" (or do it after the initial minimal install). Then google for the manual..
ssh-host-config
ssh-user-config
..as there's some choices to be made. No doubt you'll try it on a throwaway VM first which is ideal to see what happens (use at least 'dsa').
Tip: if you install cygwin onto many windows then you can point "setup.exe" repository to a writable share which all can see rather than have each VM keep its own copy. eg: Map W:
W:\App\cygpkg\setup-x86.exe
W:\App\cygpkg\setup-x86_64.exe
Set W:\App\cygpkg as local package directory.
You can use \\sharename\App\cygpkg notation, no need to map a drive. The repo you select will be populated in a folder under the above.
I've been using Cygwin ssh support to do this for years. I developed and run an automated multi-node test infrastructure that uses python and ssh to drive the remote systems. Between Cygwin and python, all the sins of different directory name separators and other OS-isms are handled cleanly, and the test tools I need to run just work whether the target system is Unix/Linux or Windows + Cygwin. It's definitely handy to be able to do all the remote stuff with portable ssh.
Let's just hope Microsoft puts some code quality investment into whatever ssh source they use, so they don't get hit with the next Heartbleed or whatever like everyone else.
This post has been deleted by its author
>allowing people to log into Windows systems and use software
>remotely over an encrypted connection.
RDC, using RDP 5.2 with TLS (Windows server 2003)?
or
SecurePipes, the older method of logging into a Windows system and using software remotely?
SSH has long been a strange omission. Still, only a MS marketing drone would pretend that there were no earlier alternatives.
A trade show which no longer exists. Anyhow I've seen a sales droid marketing the many advantages of Windows 2000. The 2 main ones which stood out for me were "harddisk encryption" and "networking", though both were readily available on Linux even back then. Now finally, after 15 years the second point is finally on the horizon and Windows might get some normal networking functionality.
"Networking" was available somewhat earlier than Windows 2000.... 95/98 and NT had full networking capabilites - even DOS and 3.x had some networking support.
The real advantages of Windows 2000 were the introduction of Active Directory replacing the old NT-style domains, and Terminal Services.
Also, Windows 2000 replaced the old "control panel applets" with the new Microsoft Management Console plug-ins. Many don't known that most MMC plug-ins have fully remoting support - just install them on any client (it's the "Administrative tools" package) and you can manage a server with no need to log on locally, or through a remote session. Of course the lack of a common remoting framework in Linux didn't allow to develop something like that, and a remote shell like SSH was needed.
Now that MS too pushes GUI-less remote management, and DCOM was too complex to master for the average developer (especially its security which is very granular, down to the single remote call), something simpler is needed, and SSH is readily available, no need to reinvent the wheel.
"And yes, I think its a trap, MS doesn't acknowledge technologies/formats other than their own unless they want to destroy/screw/muddy them. (check the ISO OOXML disaster) Everything they do is cold calculated."
This has certainly been true in the past. I think in this case, the move may be calculated but here's how I see this calculated move. They want a secure remote access protocol for Powershell, and ssh can provide that. It'll be much easier to make some patches for Powerhsell and/or OpenSSH so they work together than to create a secure protocol, with a secure implementation, from scratch. With the plenty of shops now having a mix of Windows and Linux servers or VMs, having Windows support ssh would make admin'ing this much less of a pain. Not that Microsoft would necessarily be interested in this out of the goodness of their hearts, but being "less of a pain" could help retain some uses of Windows that'd otherwise be migrated off of it.
"So far their contributions to the GPL have been a bit lacking, just drivers so they can run Linux Hosts in Hyper-'Vi' more or less decently "
I do fully expect the contributions to OpenSSH to amount to "here's patches so it integrates with Windows". *shrug*
@ Henry Wertz 1
My thoughts go along those lines, something Windows people does not know about most windows technologies and protocols is that they heavily depend on the rest of windows infrastructure, this is most MS protocols are not really protocols, but specific implementations of a protocol.
While OpenSSH can be used to encapsulate lots of things and it is much more than a single secure shell, it does not absolutely depend on a Linux or a BSD kernel.
However ask the SAMBA guys what it took to implement SAMBA 4, they had to recreate many parts of windows including a registry!!!!
Microsoft's RDP's modern implementation requires half of Windows to work if you intend to connect through a TS Gateway.
And so on and so on.
The point is they will implement some OpenSSH functionality that they need to tick some boxes off on some marketing product brouchure, and to try to keep Windows sysadmins from running any form of Linux/Mac through convenience.
The SAMBA guys had to implement a registry because /that's what SAMBA 4 is/
You might perhaps be under the mistaken belief that SAMBA 4 is just an implementation of SMB, like SAMBA 1?
SAMBA 4 is an implemenation of Active Directory. Active Directory is a replicated database system. Wait for it ...
... the "SAMBA guys" had to implement a replicated database system to implement AD....
"What next SFTP added to IIS?"
That's been an option for about 7 years now:
http://www.iis.net/learn/get-started/whats-new-in-iis-7/what39s-new-for-microsoft-and-ftp-in-iis-7
Security and support for new Internet standards:
One of the most significant features in the new FTP service is support for FTP over SSL.
Erm, no SFTP is not supported in IIS.
Even the article you link to specifically states SFTP is not supported!
Quote from the page you linked: "Microsoft currently does not provide a solution for securing FTP traffic using FTP over SSH (SFTP).".
FTP over SSL is FTPS, not SFTP, completely different protocols!
Quote: "Why would they want to when they already support FTP over SSL / TLS which is a far more sensible, flexible and more commonly used solution for secure FTP."
In my experience, at enterprise level integration for the last 8-9 years, I'd say the number of SFTP (SSH) connections outnumbered FTPS (SSL) connections by around 5 to 1.
FTPS is still plain old FTP underneath, which is a legacy out of date protocol, that should have died a death years ago.
The Integration and Security Policies for several clients I've worked for (corporate sized UK, US and French clients), consider FTPS (SSL) a depreciated legacy protocol, and do not allow it on new applications or services.
The preference being HTTPS for real time or near real time, or SFTP (SSH) for batch or large data transfers (e.g. 50MiB+).
FTPS - SSH (in comparison with FTPS - SSL) is easier to configure and manage, more resilient (auto restarting etc), better through Firewalls (only 1 port to configure, rather than a command port and data port range), easier to use with load-balancers etc etc.
It's also helped by the fact that most applications servers tend to be *NIX based, which of course supports SSH out-of-the-box. So why bother setting up FTPS, when SFTP is so much easier and more common.
Okay, so they've announced support - but no dates yet. Will it be in time for the Win10 launch? Will it be this year, next year or so far in the future that it's actually irrelevant?
I am pleased that they are finally acknowledging demand and catching up with 20 year old authentication protocols, but a vague promise that it will eventually become available is about as much use as an ashtray on a motorbike!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
