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
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
