>> No, I mean there's a *hardware* firewall in the way. You know, with the
>> big Cisco sticker on it and the 3-digit price tag? (Although obviously
>> that's only because I'm at work right now. My house doesn't have one of
>> those...)
>
>    And that hardware firewall is completely incapable of forwarding ssh
> connections? Pretty useless, I'd say.

No, I don't have the password to configure it. (And besides, have *you* 
tried configuring Cisco stuff? It's not exactly intuitive. You probably 
need Certified Engineer status to figure it out.)

>> Actually, I was wondering... can you use rsync to synchronise, say, the
>> files on an external storage device? Or does it only work if the other
>> endpoint is a *computer*?
>
>    Try http://en.wikipedia.org/wiki/Rsync

Hmm, interesting. It looks like this might be a convenient way to update 
my MP3 player...

Post a reply to this message

On 09/13/2011 11:06 AM, Warp wrote:
> 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.
>
confirm this last part as I'm on OpenSuse as well ... t'was a piece of 
cake from Yast, but if you know the process the command-line method is 
not /that/ cumbersome either

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Damn. Setting up SSH has got a whole lot easier than when I tried to do 
> it with Debian a few years ago.

> I'm presuming it defaults to password authentication though? As I 
> recall, half the trouble was figuring out how to permanently and 
> irrevocably disable password authentication and *only* allow public key 
> authentication. (For one thing, you have to work out how to create a 
> keypair...)

  Hmm, for some reason the sshd configuration module of yast is not
installed by default nowadays (it used to be with older versions of
opensuse). Well, it can be installed easily enough, though. (Although,
admittedly, you have to first figure out that you have to do this. I don't
understand why it isn't installed by default.)

  But yes, you can select RSA or public key authentication there.

http://doc.opensuse.org/products/opensuse/openSUSE/opensuse-security/cha.ssh.html#sec.ssh.yast

-- 
                                                          - Warp

Post a reply to this message

On Tue, 13 Sep 2011 03:57:59 -0300, Jim Holsenback wrote:

> On 09/12/2011 06: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.
>>
>> Jim
> yep .. that's what I use to get/put files between my system and the pov
> server ... both are "nix" machines. The ssh is just used to establish a
> secure connection, but the underlaying protocol is ftp to transfer
> files. BTW: there are windows versions of the the same tool set ...
> stelnet, sftp (etc) that I used when I was exclusive on a doze box

No, sshfs is different than sftp - sshfs actually uses fuse to allow you 
to mount the remote filesystem locally using just the sshd daemon.

Quite handy if you don't want to have an ftp daemon running.

Jim

Post a reply to this message

On Tue, 13 Sep 2011 03:24:25 -0400, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> 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.
> 
>   Anyways, sharing an entire file system is often overkill, if your goal
> is to simply transfer one file to another person.

Sure, that's what scp is for.

Jim

Post a reply to this message

On Tue, 13 Sep 2011 09:07:26 +0100, Invisible wrote:

> 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.

sshd is installed by default with Linux.  I have to put something on the 
client side only, not on the server.

> My point is that Windows lets you do this by default. Nothing to
> install, nothing to configure. It's the *default* configuration state,
> unless you purposely changed it.

That's because back in the early days of Windows, Bill Gates infamously 
said that the OS shouldn't come between the user and what the user wants 
to do.  The default model back in the early days was no security at all.

And since then, there has been a desire to maintain backwards 
compatibility while adding a security layer on top of it.

*nix, OTOH, was designed from the start with security in mind.

(Yes, NT arguably was as well - but the backwards compatibility thing 
still was an issue with NT)

Jim

Post a reply to this message

On Tue, 13 Sep 2011 15:00:57 +0100, Invisible wrote:

>>> 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.

openSUSE includes ftpd and sshd by default, though I don't recall now if 
the firewall is open by default or if the services are enabled by default.

openssh's manpage says that "PermitRootLogin" defaults to yes, which 
means root can login by default.

Jim

Post a reply to this message

On Tue, 13 Sep 2011 09:06:42 +0100, Invisible wrote:

> Yes indeedy. (I also know that they got the usual meanings of "server"
> and "client" backwards too.)

Um, no, not that I'm aware of.  What do you mean?

Jim

Post a reply to this message

On Tue, 13 Sep 2011 11:42:31 +0100, Invisible wrote:

> 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...

Nonsense.

ssh -X hostname
<Launch X application>
Application launches and X interface is on my machine while the code runs 
on the remote machine.

No configuration necessary at all.

Jim

Post a reply to this message

On Tue, 13 Sep 2011 15:23:09 +0100, Invisible wrote:

>>> 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.
> 
> Damn. Setting up SSH has got a whole lot easier than when I tried to do
> it with Debian a few years ago.
> 
> I'm presuming it defaults to password authentication though? As I
> recall, half the trouble was figuring out how to permanently and
> irrevocably disable password authentication and *only* allow public key
> authentication. (For one thing, you have to work out how to create a
> keypair...)

Yes, it defaults to password authentication.

To disable password authentication, modify /etc/ssh/sshd_config to 
include:

PasswordAuthentication no

Done.

Jim

Post a reply to this message