in reply to Re^5: Windows Service Pack Information
in thread Windows Service Pack Information

Erm . . .

However, the Ftp, and Rexec connectivity tools all rely on cleartext password authentication by the remote computer. Cleartext passwords are not encrypted before being sent over the network. This enables another user equipped with a network analyzer on the same network to steal a user's remote account password.

And reading what I presume to be the rshsvc docs says that it depends on the same "if it looks like the right host come on in" access checks that the original forms provide. Once you let one user in passwordless through a .rhosts you've put a screen door that anyone that can spoof traffic can open.

It's a network hygiene thing; 99.9% of the time it may be find that you leave your car unlocked because you park in a private deck, but by refusing to take a trivial step (getting in the habit of locking your car; installing something that's not an open vulnerability waiting to happen) you've only got yourself to blame that one time when a miscreant makes it past the other layers.

Live dangerously if you like, just be careful cavalierly advising others to do the same without letting them know there's risks involved. That's all.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Replies are listed 'Best First'.
Re^7: Windows Service Pack Information
by BrowserUk (Patriarch) on Apr 17, 2008 at 23:27 UTC

    Microsoft® Windows® Services for UNIX 3.5 has nothing to do with the TCP/IP Remote Utilities. Nothing. Compeletely different animals for entirely different purposes. The former has to operate as the *nix tools do, in order that it can iteroperate with them. The clue is in the title.

    The rsh that comes with OS uses the same NT Auth mechanism used by the OS itself. That is, you have to be authorised at the domain, subject to all the same controls, restrictions and ACLs as if you were stting at the machine itself. Identical.

    Once you let one user in passwordless

    It's a network hygiene thing;

    Live dangerously if you like, just be careful cavalierly advising others to do the same without letting them know there's risks involved. That's all.

    None of this applies....... to the native rsh utility. None. Not one iota. Zip. Nadda.

    When you know what you are talking about (win32!!!!!!!), then give me lectures on the subject.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      Fine, it can be set to use NTLM between WIndows hosts. If that's the case then I stand corrected on that. Then again you can of course point to the simple instructions to do NTLM authentication using Solaris rsh to a Windows host (as the OP is trying to do). And the magic incantation that will make rsh encrypt its traffic so sensitive information (aside from authentication tokens) isn't sent in the clear.

      OpenSSH is open, cross platform, under active development, and secure. Windows rsh is closed source, doesn't support secure authentication cross platform (without going through whatever arcane machinations are needed to get not-Windows talking NTLM), seems to be if not deprecated on the way out (going by this Vista document), and sends normal traffic in the clear.

      Again: choose wisely.

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

[reply]

        The distinction, as I pointed out earlier, is that the rsh service is already installed, and possible running on the N tens, hundreds (thousands?) of internal systems the OP is trying to catalog.

        Getting permission to role out a new piece of software, that doesn't use an approved authentication mechanism that integrates with Domain-level and/or Active Directory GINAs in any vaguely security aware MS-based organisation, would at best take months of negotiations and testing, and probably never happen.

        And it doesn't need to be NT_AUTH... it can use any of the other Windows integrated Authentication mechanisms, including Kerberos, which is open, cross-platform, and perfectly secure.

        As for the "send normal traffic in the clear": That's why I stipulated "a secure network". Within most secure, corporate networks, most normal traffic, from emails to file transfers is sent in the clear. That's the reason for DMZs, to isolate internal from external traffic.

        Again: choose wisely.

        Wise words. I was. 10 years ago when setting up an NT-based network for the government departments of an entire medium-sized European country. After a year of investigation and testing rsh (the Windows version with NT_AUTH) was deemed secure. Not by me, but by people who know. FUD doesn't cut it.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom