 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> I said that Windows allows it *by default*
So how exactly would I transfer a file to you from my Windows?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/09/2011 11:25 AM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> Now I haven't tried it, but I'm told is approximately /impossible/ to
>> actually configure X so that you can access it remotely. Even though
>> that's its entire design goal.
>
> I don't know what you mean.
>
> For the sake of it, I just now tried to do a "ssh -X" to a friend's computer
> (who is also running linux) and ran xclock. It opened nicely on my screen,
> even though the program itself is running on my friend's computer (which is
> physically located something like 200 km from here).
Like I said, I haven't personally tried to run X remotely. (I wouldn't
know how.) I'm told it requires spending hours editing the X
configuration files to set up authentication and so forth, and then to
make sure the server is started, and then to tell the application you
want to run to open on the remote machine rather than the local one (by
using CLI options that vary for every individual program so you have to
look them up), and then...
And that's without encryption. If you want encryption, now you have to
also install and configure an ssh server and client, set up
authentication and encryption keys and god-knows what else.
>> And yet, Windows is the one where I run a command, type in the name of
>> any networked PC, and I have remote access. By default. No special
>> configuration required.
>
> What kind of configuration did I do to be able to log in into my friend's
> computer and run an app remotely? Or to transfer files for that matter (which
> was the original point)?
So you're seriously telling me that with a default Linux install, not
only is an ssh server installed, but it's actually configured to allow
incoming connections and service them? And that X will actually work in
this configuration?
I know nothing about X, but I do remember setting up my old laptop to be
an ssh server so I could RDP into my Windows box over the Internet. It
was a hellish nightmare of wading through manpages finding out how the
hell to do what I actually wanted to do...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/09/2011 11:40 AM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> I said that Windows allows it *by default*
>
> So how exactly would I transfer a file to you from my Windows?
You can't. My PC is firewalled.
You also can't transfer a file using Unix, for the same reason.
That said, Windows file sharing is designed for the LAN. It really
doesn't work properly over the Internet. You would need some kind of VPN
connection to make it work properly. Unix, on the other hand, has tools
which *do* work over the Internet. Things like FTP and so forth.
If both machines are on the same LAN, sharing files between Windows
hosts becomes trivial.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 13/09/2011 11:40 AM, Warp wrote:
>> Invisible<voi### [at] devnull> wrote:
>>> I said that Windows allows it *by default*
>>
>> So how exactly would I transfer a file to you from my Windows?
>
> You can't. My PC is firewalled.
>
> You also can't transfer a file using Unix, for the same reason.
>
> That said, Windows file sharing is designed for the LAN. It really
> doesn't work properly over the Internet. You would need some kind of VPN
> connection to make it work properly. Unix, on the other hand, has tools
> which *do* work over the Internet. Things like FTP and so forth.
>
> If both machines are on the same LAN, sharing files between Windows
> hosts becomes trivial.
If both Unix machines are on a LAN, sharing files becomes as trivial.
There are Linux distros that start ftpd, remote shell and NFS by
default, or at least ask you if you want to do it at installation time.
Same thing for Solaris, AIX and other *NIX variants.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-09-13 04:07, Invisible a écrit :
> On 12/09/2011 10:20 PM, Jim Henderson wrote:
>> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:
>>
>>> I'm not aware of any Unix system which *defaults* to letting remote
>>> users access the entire filesystem if they know the root password.
>>> Probably because it's a stunningly bad idea, unless the local network is
>>> trusted. But anyway...
>>
>> Every unix system can do this with something like sshfs installed - on
>> the client side only - and sshd running on the server.
>
> Yes, if you /install stuff/ you can do it.
>
> My point is that Windows lets you do this by default.
> Nothing to install,
Correction: Everything required is installed as part of the default
installation.
> nothing to configure.
Correction: Everything is preconfigured as part of the default
installation.
> It's the *default* configuration state,
> unless you purposely changed it.
SO, if I was to provide you with a Linux distro that had ftpd and sshd
installed by default, and allowed remote root logins, would you concede
the point?
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 13/09/2011 11:25 AM, Warp wrote:
>> Invisible<voi### [at] devnull> wrote:
>>> Now I haven't tried it, but I'm told is approximately /impossible/ to
>>> actually configure X so that you can access it remotely. Even though
>>> that's its entire design goal.
>>
>> I don't know what you mean.
>>
>> For the sake of it, I just now tried to do a "ssh -X" to a friend's
>> computer
>> (who is also running linux) and ran xclock. It opened nicely on my
>> screen,
>> even though the program itself is running on my friend's computer
>> (which is
>> physically located something like 200 km from here).
>
> Like I said, I haven't personally tried to run X remotely. (I wouldn't
> know how.)
Google X-Windows HOWTO.
It's almost like people have sorted this out 20 years ago.
> I'm told it requires spending hours editing the X
> configuration files to set up authentication and so forth,
So, basically, your only gripe with UNIx is that userIDs are important,
whereas a standard Windows home edition assumes everything is honky dory
with Administrator.
> and then to make sure the server is started,
And you don't need to do do that on Windows? Try remote logging on a
server that had Terminal Services disabled, or crashed, since it's one
of the few services that can not be remote-restarted by pstools.
> and then to tell the application you
> want to run to open on the remote machine rather than the local one (by
> using CLI options that vary for every individual program so you have to
> look them up), and then...
Add
export DISPLAY=my.pcs.ip.address:screenno
To your login script and then EVERY X program will run on your screen,
not the remote machine's. Where did you get the idea that the CLI
argument would differ from one program to the next, if you've obviously
haven't RTMFed?
> And that's without encryption. If you want encryption, now you have to
> also install and configure an ssh server and client, set up
> authentication and encryption keys and god-knows what else.
Installing an ssh server on your *NIX machine is relatively easy.
Probably easier than making the required regisrty hacks to install
Terminal Services on a Windows XP home edition.
Installing an ssh client on the other end is trivial.
>
> So you're seriously telling me that with a default Linux install, not
> only is an ssh server installed, but it's actually configured to allow
> incoming connections and service them? And that X will actually work in
> this configuration?
Depending on the distribution, yes. Distros aimed at desktop users
(Ubuntu, Gentoo, etc...) will usually not have these on by default, but
"server" distributions (SLES, Red Hat, Etc...) will have them on by
default, or as I mentioned in another post, will ask you at installation
time.
This is exactly the same for Windows. Compare the options and default
settings between a Home edition, Profesionnal edition or the Advanced
server versions.
>
> I know nothing about X, but I do remember setting up my old laptop to be
> an ssh server so I could RDP into my Windows box over the Internet. It
> was a hellish nightmare of wading through manpages finding out how the
> hell to do what I actually wanted to do...
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It's the *default* configuration state,
>> unless you purposely changed it.
>
> SO, if I was to provide you with a Linux distro that had ftpd and sshd
> installed by default, and allowed remote root logins, would you concede
> the point?
It's news to me that any distro actually does this. But sure, then I
could concede that Windows and Linux both make it equally trivial.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> On 13/09/2011 11:40 AM, Warp wrote:
> > Invisible<voi### [at] devnull> wrote:
> >> I said that Windows allows it *by default*
> >
> > So how exactly would I transfer a file to you from my Windows?
> You can't. My PC is firewalled.
> You also can't transfer a file using Unix, for the same reason.
Most firewalls have the ssh port open because it's considered safe.
(And if it's not, it's easy to open in most distros).
Then you can use scp, rsync or any equivalent tool to transfer files.
(There probably isn't any linux distro that doesn't come by default with
scp and rsync.)
(Btw, the great thing about rsync is that it can resume interrupted file
transfers, a rather important feature that, oddly, most file transfer tools
completely lack.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> On 13/09/2011 11:25 AM, Warp wrote:
> > Invisible<voi### [at] devnull> wrote:
> >> Now I haven't tried it, but I'm told is approximately /impossible/ to
> >> actually configure X so that you can access it remotely. Even though
> >> that's its entire design goal.
> >
> > I don't know what you mean.
> >
> > For the sake of it, I just now tried to do a "ssh -X" to a friend's computer
> > (who is also running linux) and ran xclock. It opened nicely on my screen,
> > even though the program itself is running on my friend's computer (which is
> > physically located something like 200 km from here).
> Like I said, I haven't personally tried to run X remotely. (I wouldn't
> know how.) I'm told it requires spending hours editing the X
> configuration files to set up authentication and so forth, and then to
> make sure the server is started, and then to tell the application you
> want to run to open on the remote machine rather than the local one (by
> using CLI options that vary for every individual program so you have to
> look them up), and then...
> And that's without encryption. If you want encryption, now you have to
> also install and configure an ssh server and client, set up
> authentication and encryption keys and god-knows what else.
Didn't you read what I wrote above?
Short answer: No, you don't. (I didn't have to do any configuration to get
that test working. I just did it, and it worked. The only thing I had to
know was that you have to give ssh the parameter -X to enable X forwarding,
which is disabled by default for safety reasons. And the connection is,
obviously fully encrypted because it happens through ssh.)
> So you're seriously telling me that with a default Linux install, not
> only is an ssh server installed, but it's actually configured to allow
> incoming connections and service them? And that X will actually work in
> this configuration?
I don't remember if sshd is enabled by default on OpenSuse, but it's
as easy to enable as doing a couple of mouse clicks (and typing the root
password, so that yast can perform the system modifications). IIRC it even
offers you to automatically open the ssh port on the firewall.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 13/09/2011 08:30 AM, Warp wrote:
>
>> I like how to you everything in Windows is "trivial". Like using soft or
>> hard links (which, btw, I have still no idea how to do, regardless of
>> your
>> assurances that it's very easy).
>
> End users aren't supposed to use this technology. It's used "under the
> hood" by various Windows features. Remember, the desktop Windows OS is
> designed to be operated by morons.
>
> (For example, most of our salesman have a Windows laptop. And trust me,
> they are idiots of the highest calibre.)
>
>> If this so "trivial", why haven't I ever heard of this "RDP"?
>
> Because Microsoft refers to it by half a dozen different names.
>
> Terminal Services.
> Remote Desktop.
> Remote Assistance.
>
> RDP stands for Remote Desktop Protocol, and is the actual wire protocol
> underlying all of the above /product features/.
>
> Terminal Services is where you have an expensive server-class version of
> Windows, you install all your complicated applications on that, and then
> end users use their Windows-based desktop PC to log into the server and
> run the applications on that. In other words, each desktop PC becomes
> essentially a dumb terminal for connecting to the server where the
> applications actually run.
Nope, that's Citrix (it may have changed names since MS acquired them,
but everyone in the industry still calls it Citrix) and it runs on a
different port than RDP. Terminal Services is the service running on
the remote machine that receives the connection from MSRTC.EXE running
on your computer to allow remote desktop connections.
>
> Remote Desktop is where you log in to a remote desktop system in the
> same way you'd log in to it remotely. Except... it's remote. To anybody
> looking at the desktop locally, it just looks like the system is locked.
> Because it's a /desktop/ system, only one user can be logged in to it at
> once, remotely or locally.
Nein. You can have two remote sessions on top of the "console" session
on a machine running Terminal Services. since NT4.
> What all these systems have in common is that one computer is displaying
> the video output of another. Like a remote X session. Except that it
> also connects the sound card, network drives, printers [but that never
> ****ing works properly], clipboard, and probably a few other things as
> well.
Sound card, printers, clipboard and drive mappings are all optional and
off by default, on the client side.
>
> This is literally how when I have a day off work, I can sit at my home
> PC and reboot servers, install software updates, and all kinds of other
> stuff, from my house. (Obviously, there's a VPN involved as well.
> Otherwise all this traffic would be unencrypted...)
So why were you griping about having to install ssh because X11 was
unencrypted?
The VPN tunnel also allows you to bypass the NAT done by your company's
firewall.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
