Partial SNAFUs - X11Forwarding etc.
Mike
Having some fun setting up SSH. Looking for URLs, hints, tips,
and legitimate (but informative) chortlings.
P1 = Client machine
P2 = Server machine
# P2 /etc/ssh/sshd_config
Port 22
Protocol 2
ListenAddress 192.168.1.2
AllowUsers user...@192.168.1.?
PermitRootLogin no
HostKey /etc/ssh/ssh_host_dsa_key
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
TCPKeepAlive yes
UseLogin no
UsePrivilegeSeparation yes
PermitUserEnvironment no
Compression delayed
UseDNS no
Subsystem sftp /usr/libexec/sftp-server
# P1 ~/.ssh/ssh_config
Port 22
Protocol 2
ForwardAgent no
ForwardX11 no
ForwardX11Trusted no
RhostsRSAAuthentication no
RSAAuthentication no
PasswordAuthentication no
HostbasedAuthentication no
StrictHostKeyChecking ask
IdentityFile ~/.ssh/id_dsa
EscapeChar ~
1)
This works...
consolecommand "ssh -XY username@P2"
then in the P2/SSH console
consolecommand "firefox"
2)
This doesn't...
consolecommand "ssh -XY username@P2 firefox"
ERROR "bash: firefox: command not found"
3)
However, this works...
consolecommand "ssh -XY username@P2 dillo"
4)
but this doesn't...
consolecommand "ssh username@P2 mc"
ERROR "Cannot get terminal settings: Invalid argument (22)"
"TERM environment variable needs set"
5)
But this does...
consolecommand "ssh username@P2"
then in the P2/SSH console
consolecommand "mc"
Then there is the question of introducing a working command like "ssh
-XY username@P2 dillo" into an IceWM application menu file. No
visible response, as if nothing happened.
Dug out this from http://www.openssh.com/faq.html
Add "shopt -s huponexit" to ~/.bashrc
to prevent connection failed apps hanging.
(Seems to do something about those hanging GUI apps.)
Questions...
Q: What is missing with regard to some apps working and some
not? Why does Dillo fire up but Firefox fail? (And only
with a direct command?)
Q: Why does MC fail as a direct command, but work ok in an
established SSH console?
I suspect something is not finishing it's initialisation
before the command is issued. So, how to add a "wait until..."
into the login-command sequence? (Assuming it might be required?)
Q: As a parent terminal for an X11 application is just residual
screen junk, how to initiate an X11 application command without
using a terminal?
Q: And last but not least, is there an option to avoid using
the -Y flag as there are reasons the default was changed
to "ForwardX11Trusted no" ?
Damn! But SSH is an untidy tool!
(Or, I'm making a real hash of using it.)
P.S. Yes, I've read the man pages, read up on what I could
find on the web, and tried a few variations. Still not
quite getting that clue though. :(
--
Yellow Submarine?
Nah. Its a TeaPot!
www.tinyurl.com/382gmp
Per Hedeland
<N...@Arizona.Bay> writes:
>
>1)
>This works...
>consolecommand "ssh -XY username@P2"
>then in the P2/SSH console
>consolecommand "firefox"
>
>2)
>This doesn't...
>consolecommand "ssh -XY username@P2 firefox"
>
>ERROR "bash: firefox: command not found"
I have no idea what "consolecommand" might be, but anyway this is due to
your $PATH being set up differently when you do an actual login as in 1)
vs when you just request execution of a command as in 2) - this should
really be in a SSH FAQ somewhere, but I couldn't find it...
With a shell in the "/bin/sh family" such as bash, $HOME/.profile is
sourced in 1) but not in 2), so if you set a "custom" $PATH there, it
has no effect in 2). For [t]csh it's the same thing with $HOME/.login,
but the solution there is to set your $path in $HOME/.[t]cshrc instead,
which I've been doing since 'rsh' was the only thing that could do 2). I
believe there is a way to make at least some /bin/sh-family shells do
the right thing too, but someone else will have to say what it is, I
keep forgetting...
>3)
>However, this works...
>consolecommand "ssh -XY username@P2 dillo"
Presumably "dillo" is in the "standard" $PATH hardwired in sshd (tends
to be /bin:/usr/bin or so).
>4)
>but this doesn't...
>consolecommand "ssh username@P2 mc"
>
>ERROR "Cannot get terminal settings: Invalid argument (22)"
> "TERM environment variable needs set"
It needs a (pseudo-)tty, which you can give it by using the -t option to
ssh - see the man page. This should fix the TERM problem too.
>5)
>But this does...
>consolecommand "ssh username@P2"
>then in the P2/SSH console
>consolecommand "mc"
You always get a (pseudo-)tty when doing a full login.
>Then there is the question of introducing a working command like "ssh
>-XY username@P2 dillo" into an IceWM application menu file. No
>visible response, as if nothing happened.
No idea about that. Well, there's some probability that it fails to
authenticate - if your ssh commands above prompt for a password or
passphrase, there's no obvious way to do that in the X11 session -
generally you need to install an "askpass" program (there are multiple
to choose from), that the ssh client can invoke to prompt for the
password/phrase via a X11 window popup.
>Questions...
>
>Q: What is missing with regard to some apps working and some
> not? Why does Dillo fire up but Firefox fail? (And only
> with a direct command?)
>
>Q: Why does MC fail as a direct command, but work ok in an
> established SSH console?
See above.
>I suspect something is not finishing it's initialisation
>before the command is issued. So, how to add a "wait until..."
>into the login-command sequence? (Assuming it might be required?)
No.
>Q: As a parent terminal for an X11 application is just residual
> screen junk, how to initiate an X11 application command without
> using a terminal?
In your window manager's "application menu file"?:-) It *should* work
when you have things set up correctly.
>Q: And last but not least, is there an option to avoid using
> the -Y flag as there are reasons the default was changed
> to "ForwardX11Trusted no" ?
You can set 'ForwardX11Trusted yes' in your $HOME/.ssh/config, but you
should think hard about it, since the requirement was added for a
reason. You should probably combine it with 'Host' entries such that it
is only applied for connections to hosts that you trust.
(It's also a bit of a pain if your home directory is NFS-mounted and you
occasionally use ssh on hosts that have a version that is old enough to
not know about -Y/ForwardX11Trusted (getting rare, but I recently had
reason to work on QNX, and the most recent pre-built version was
3.7.1p1...) - in that case any use of ssh will fail.)
>Damn! But SSH is an untidy tool!
>
>(Or, I'm making a real hash of using it.)
Neither really - none of the above are actual issues with ssh as such,
it's just that the things you can do with it put somewhat "advanced"
requirements on your environment - at least if you aren't previously
used to "rsh", and (thankfully enough I guess) few people are these
days.
--Per Hedeland
p...@hedeland.org
Mike
> In article <cxwMi.64186$BW4....@fe1.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>
>>1)
>>This works...
>>consolecommand "ssh -XY username@P2"
>>then in the P2/SSH console
>>consolecommand "firefox"
>>
>>2)
>>This doesn't...
>>consolecommand "ssh -XY username@P2 firefox"
>>
>>ERROR "bash: firefox: command not found"
>
> I have no idea what "consolecommand" might be, but anyway this is due to
> your $PATH being set up differently when you do an actual login as in 1)
> vs when you just request execution of a command as in 2) - this should
> really be in a SSH FAQ somewhere, but I couldn't find it...
Aha! A clue! Neat!
(consolecommand simply means a command entered in a console.)
> With a shell in the "/bin/sh family" such as bash, $HOME/.profile is
> sourced in 1) but not in 2), so if you set a "custom" $PATH there, it
> has no effect in 2). For [t]csh it's the same thing with $HOME/.login,
> but the solution there is to set your $path in $HOME/.[t]cshrc instead,
> which I've been doing since 'rsh' was the only thing that could do 2). I
> believe there is a way to make at least some /bin/sh-family shells do
> the right thing too, but someone else will have to say what it is, I
> keep forgetting...
Still a clue, so thanks.
>>3)
>>However, this works...
>>consolecommand "ssh -XY username@P2 dillo"
>
> Presumably "dillo" is in the "standard" $PATH hardwired in sshd (tends
> to be /bin:/usr/bin or so).
More clues! Excellent!
>>4)
>>but this doesn't...
>>consolecommand "ssh username@P2 mc"
>>
>>ERROR "Cannot get terminal settings: Invalid argument (22)"
>> "TERM environment variable needs set"
>
> It needs a (pseudo-)tty, which you can give it by using the -t option to
> ssh - see the man page. This should fix the TERM problem too.
consolecommand "ssh -t username@P2 mc"
Yup. That worked. Now for that pesky $PATH thingy!
>>5)
>>But this does...
>>consolecommand "ssh username@P2"
>>then in the P2/SSH console
>>consolecommand "mc"
>
> You always get a (pseudo-)tty when doing a full login.
Seems useful. :)
>>Then there is the question of introducing a working command like "ssh
>>-XY username@P2 dillo" into an IceWM application menu file. No
>>visible response, as if nothing happened.
>
> No idea about that. Well, there's some probability that it fails to
> authenticate - if your ssh commands above prompt for a password or
> passphrase, there's no obvious way to do that in the X11 session -
> generally you need to install an "askpass" program (there are multiple
> to choose from), that the ssh client can invoke to prompt for the
> password/phrase via a X11 window popup.
Or maybe its that pseudo-terminal problem...?
Just tried "ssh -XY username@P2 dillo" as a menu command. Got a
console, Dillo's startup text output, and Dillo. Closed Dillo and got
left with the console and no prompt to exit from. Had to kill the
console. Hoping this didn't leave a process hanging somewhere. :(
Changed that menu command to "ssh -tXY username@P2 dillo", got the
same procedure, but this time everything shut down nicely.
>>Questions...
>>
>>Q: What is missing with regard to some apps working and some
>> not? Why does Dillo fire up but Firefox fail? (And only
>> with a direct command?)
>>
>>Q: Why does MC fail as a direct command, but work ok in an
>> established SSH console?
>
> See above.
Yes. Good clues.
>>I suspect something is not finishing it's initialisation
>>before the command is issued. So, how to add a "wait until..."
>>into the login-command sequence? (Assuming it might be required?)
>
> No.
Didn't think so, just grasping at theoretical straws.
>>Q: As a parent terminal for an X11 application is just residual
>> screen junk, how to initiate an X11 application command without
>> using a terminal?
>
> In your window manager's "application menu file"?:-) It *should* work
> when you have things set up correctly.
See above Dillo experiment. Still got that redundant console though. :(
>>Q: And last but not least, is there an option to avoid using
>> the -Y flag as there are reasons the default was changed
>> to "ForwardX11Trusted no" ?
>
> You can set 'ForwardX11Trusted yes' in your $HOME/.ssh/config, but you
> should think hard about it, since the requirement was added for a
> reason. You should probably combine it with 'Host' entries such that it
> is only applied for connections to hosts that you trust.
As all the machines on this network are mine and in the same room,
and the only one acting as an SSH server is the same one, I guess I
can trust them in this physical environment, but this is not what the
concern was I think.
> (It's also a bit of a pain if your home directory is NFS-mounted and you
> occasionally use ssh on hosts that have a version that is old enough to
> not know about -Y/ForwardX11Trusted (getting rare, but I recently had
> reason to work on QNX, and the most recent pre-built version was
> 3.7.1p1...) - in that case any use of ssh will fail.)
Good job I'm not using NFS connections then. :)
>>Damn! But SSH is an untidy tool!
>>
>>(Or, I'm making a real hash of using it.)
>
> Neither really - none of the above are actual issues with ssh as such,
> it's just that the things you can do with it put somewhat "advanced"
> requirements on your environment - at least if you aren't previously
> used to "rsh", and (thankfully enough I guess) few people are these
> days.
I've been getting the idea using SSH was not quite as simple as "do
this, get that" and that some other things needed to be set up to
construct a working and reasonably secure connection process for the
various tasks I want it to do.
Thanks for the clues. If you find any more, send 'em in! :)
Mike
> In article <cxwMi.64186$BW4....@fe1.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>
>>1)
>>This works...
>>consolecommand "ssh -XY username@P2"
>>then in the P2/SSH console
>>consolecommand "firefox"
>>
>>2)
>>This doesn't...
>>consolecommand "ssh -XY username@P2 firefox"
>>
>>ERROR "bash: firefox: command not found"
>
> I have no idea what "consolecommand" might be, but anyway this is due to
> your $PATH being set up differently when you do an actual login as in 1)
> vs when you just request execution of a command as in 2) - this should
> really be in a SSH FAQ somewhere, but I couldn't find it...
>
> With a shell in the "/bin/sh family" such as bash, $HOME/.profile is
> sourced in 1) but not in 2), so if you set a "custom" $PATH there, it
> has no effect in 2). For [t]csh it's the same thing with $HOME/.login,
> but the solution there is to set your $path in $HOME/.[t]cshrc instead,
> which I've been doing since 'rsh' was the only thing that could do 2). I
> believe there is a way to make at least some /bin/sh-family shells do
> the right thing too, but someone else will have to say what it is, I
> keep forgetting...
>
And the update is...
The -t option does indeed sort things out for console applications.
It seems redundant with some, but seems to do no harm leaving it in.
The problem with issuing commands from the IceWM menu was down to my
(bad) writing out of the commands in the menu file. All fixed now.
The "some work, some don't" problem was, as you spotted, the $PATH
thingy. I fixed that by adding relevant $PATH statement lines from
.bash_profile (read on initial machine login) to .bashrc (read on
each console generation, even over SSH).
Following on from that, just to save some complication, I created a
dir .config and simlinked in the various configs required for the
apps I need to run over SSH, then added that to the .bashrc $PATH
statement.
Everything works just fine and dandy now. :)
Many thanks Per.
Just got that ForwardX11Trusted thing to work around now.
I may have got this wrong but, is the idea behind not allowing
ForwardX11Trusted to prevent security issues between those logging in
to the base server machine via SSH, or it it also supposed to protect
against problems coming in to the base server machine and getting
back "up the line" to the client machine(s)?
If its just to stop clients messing around with each other's stuff,
then thats not a problem here as its a home network. If its to
protect clients from problems the base server itself might incur,
then that would be another story.
If it is indeed to protect the clients from the server, then it
probably would be a good idea to work toward running things without
it enabled.
Currently getting this:
$ ssh -X username@P2 firefox
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
(Details: serial 196 error_code 5 request_code 20 minor_code 0)
(Note to programmers: normally, X errors are reported
asynchronously; that is, you will receive the error a while after
causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error()
function.)
...but
$ ssh -XY username@P2 firefox
...works fine.
And:
$ ssh -X username@P2 dillo
dillo_dns_init: Here we go! (threaded)
Disabling cookies.
Nav_open_url: Url=>file:///home/username/HomePage/index.html<
Dpi_parse_token: {<cmd='start_send_page'
url='file:///home/username/HomePage/index.html' '>}
Dpi: [Dpi_process_io] IOClose
Type check: [Srv: text/html Det: text/plain]
Dpi_parse_token: {<cmd='start_send_page'
url='file:///home/username/HomePage/icon.gif' '>}
Dpi_parse_token: {<cmd='start_send_page'
url='file:///home/username/HomePage/121x135.gif' '>}
Dpi: [Dpi_process_io] IOClose
Dpi: [Dpi_process_io] IOClose
Type check: [Srv: image/gif Det: image/gif]
Type check: [Srv: image/gif Det: image/gif]
Dillo: normal exit!
Gdk-ERROR **: BadAccess (attempt to access private resource denied)
serial 2990 error_code 10 request_code 102 minor_code 0
...works ok, but with the error on exit, and
$ ssh -XY username@P2 dillo
dillo_dns_init: Here we go! (threaded)
Disabling cookies.
Nav_open_url: Url=>file:///home/username/HomePage/index.html<
Dpi_parse_token: {<cmd='start_send_page'
url='file:///home/username/HomePage/index.html' '>}
Dpi: [Dpi_process_io] IOClose
Type check: [Srv: text/html Det: text/plain]
Dpi_parse_token: {<cmd='start_send_page'
url='file:///home/username/HomePage/icon.gif' '>}
Dpi_parse_token: {<cmd='start_send_page'
url='file:///home/username/HomePage/121x135.gif' '>}
Dpi: [Dpi_process_io] IOClose
Dpi: [Dpi_process_io] IOClose
Type check: [Srv: image/gif Det: image/gif]
Type check: [Srv: image/gif Det: image/gif]
Dillo: normal exit!
...works fine.
Q: How to get things to work without the -Y flag?
Hints, tips, and/or URLs on this one gratefully received.
Per Hedeland
<N...@Arizona.Bay> writes:
>
>Just got that ForwardX11Trusted thing to work around now.
>
>I may have got this wrong but, is the idea behind not allowing
>ForwardX11Trusted to prevent security issues between those logging in
>to the base server machine via SSH, or it it also supposed to protect
>against problems coming in to the base server machine and getting
>back "up the line" to the client machine(s)?
>
>If its just to stop clients messing around with each other's stuff,
>then thats not a problem here as its a home network. If its to
>protect clients from problems the base server itself might incur,
>then that would be another story.
>
>If it is indeed to protect the clients from the server, then it
>probably would be a good idea to work toward running things without
>it enabled.
Well, terminology gets a bit confused with X11 since the server is local
and the client remote, but reading your last line as "protect the ssh
client (host) from the ssh server (host)", the answer is "yes". I.e. if
the ssh server host is compromised or otherwise untrustworthy, programs
there can connect to your X11 server via the SSH forwarding and
potentially do very evil things, e.g. read the contents of your (other)
windows, eavesdrop on keypress events directed to other windows, or even
generate keypress (or mouse-button) events directed at other windows.
"Potentially" because IIRC, at least some of those things can be
prevented by the applications owning those other windows - but who knows
if they do that...
>Currently getting this:
>
>
>$ ssh -X username@P2 firefox
>The program 'firefox-bin' received an X Window System error.
>This probably reflects a bug in the program.
>The error was 'BadAtom (invalid Atom parameter)'.
If you get stuff like that, you only have two choices AFAIK - use -Y or
refrain from running the program via ssh X11 forwarding - there's no
"workaround". My experience is that without -Y, the set of X11 clients
that can run at all is pretty limited, and among those, their
functionality is quite restricted - e.g. you can't even *intentionally*
paste text from other windows into them, and I think I've come across
clients that keel over and die if you try.
>Q: How to get things to work without the -Y flag?
I think the best way to go is what I mentioned earlier, use it for
"trusted" hosts only, most conveniently via $HOME/.ssh/config - e.g. if
you are reasonably sure that there is no evil stuff on P2, you can put
this in $HOME/.ssh/config:
Host P2
ForwardX11Trusted yes
--Per Hedeland
p...@hedeland.org
Mike
> In article <K8yNi.257480$xp6.2...@fe3.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>
>>Just got that ForwardX11Trusted thing to work around now.
>>
>>I may have got this wrong but, is the idea behind not allowing
>>ForwardX11Trusted to prevent security issues between those logging in
>>to the base server machine via SSH, or it it also supposed to protect
>>against problems coming in to the base server machine and getting
>>back "up the line" to the client machine(s)?
>>
>>If its just to stop clients messing around with each other's stuff,
>>then thats not a problem here as its a home network. If its to
>>protect clients from problems the base server itself might incur,
>>then that would be another story.
>>
>>If it is indeed to protect the clients from the server, then it
>>probably would be a good idea to work toward running things without
>>it enabled.
>
> Well, terminology gets a bit confused with X11 since the server is local
> and the client remote,
Yup. I'd noticed that. And the man page(s) seems to switch focus too.
> ....but reading your last line as "protect the ssh
> client (host) from the ssh server (host)", the answer is "yes". I.e. if
> the ssh server host is compromised or otherwise untrustworthy, programs
> there can connect to your X11 server via the SSH forwarding and
> potentially do very evil things, e.g. read the contents of your (other)
> windows, eavesdrop on keypress events directed to other windows, or even
> generate keypress (or mouse-button) events directed at other windows.
> "Potentially" because IIRC, at least some of those things can be
> prevented by the applications owning those other windows - but who knows
> if they do that...
Good point, seeing as things like Firefox are not GNU, and therefore
not properly "reviewed" with regard to security and "appropriate"
behaviour (plus, the direct connection to AOL/Time/Warner cannot be
dismissed with ease). I'm thinking here that with ForwardX11Trusted
set to yes, the client running it over SSH is vunerable to Firefox
security holes and exploits, as if they had it running on the client
machine directly. Other apps may also have the potential to become a
channel into the client machine, and NOT using ForwardX11Trusted is a
way to significantly limit that potential route back to the client.
>>Currently getting this:
>>
>>
>>$ ssh -X username@P2 firefox
>>The program 'firefox-bin' received an X Window System error.
>>This probably reflects a bug in the program.
>>The error was 'BadAtom (invalid Atom parameter)'.
>
> If you get stuff like that, you only have two choices AFAIK - use -Y or
> refrain from running the program via ssh X11 forwarding - there's no
> "workaround". My experience is that without -Y, the set of X11 clients
> that can run at all is pretty limited, and among those, their
> functionality is quite restricted - e.g. you can't even *intentionally*
> paste text from other windows into them, and I think I've come across
> clients that keel over and die if you try.
The only option I'm seeing here is to work on each desired app to
find a workaround to the apps problems with being called via SSH. For
instance, both Opera and Dillo complain without the -Y flag, but do
function acceptably. Firefox just kicks out a stroppy error message
and refuses to play. If Firefox, for example, could be cajoled into
accepting a pseudo process on the server it live on, then the SSH
client could benefit from having "fooled it".
>>Q: How to get things to work without the -Y flag?
>
> I think the best way to go is what I mentioned earlier, use it for
> "trusted" hosts only, most conveniently via $HOME/.ssh/config - e.g. if
> you are reasonably sure that there is no evil stuff on P2, you can put
> this in $HOME/.ssh/config:
I'm as reasonably sure as one can be with amachine connected directly
to a broadband modem. IOW, a pretty restrictive firewall and a huge
/etc/hosts file with all kinds of addresses linked to 127.0.0.1
It would be nice to know that if something managed to sneak into P2,
then there would be at least some form of restriction on just how far
up the SSH connection it could reach, and that restriction seems to
be not to use ForwardX11Trusted.
My next project, therefore, is going to be trying to fool P2's
Firefox into thinking everything is happening on the P2 SSH server
machine.
(Thinks: Maybe I should start with Dillo? ;)
Per Hedeland
<N...@Arizona.Bay> writes:
>
> I'm thinking here that with ForwardX11Trusted
>set to yes, the client running it over SSH is vunerable to Firefox
>security holes and exploits, as if they had it running on the client
>machine directly.
I'm not sure I follow you here, but anyway the problem that the
ForwardX11Trusted disabling is addressing isn't with the clients you run
via the X11 forwarding, but rather with *other* clients that are
displaying on the same X11 server. I.e. the evil things would use the
X11 tunnel "itself" to spy on or manipulate those other clients -
doesn't matter if yo have *any* clients using the tunnel as long as it's
there. Of course the tunnel could also be used to attack clients that
*are* running via the tunnel, but if the assumption is that the remote
host is compromised, there are more direct ways to attack those clients
anyway.
>The only option I'm seeing here is to work on each desired app to
>find a workaround to the apps problems with being called via SSH. For
>instance, both Opera and Dillo complain without the -Y flag, but do
>function acceptably. Firefox just kicks out a stroppy error message
>and refuses to play. If Firefox, for example, could be cajoled into
>accepting a pseudo process on the server it live on, then the SSH
>client could benefit from having "fooled it".
No, it's not Firefox that is unhappy specifically with being pointed to
a ssh X11 tunnel, it's ssh that is preventing certain X11 protocol
messages from getting through the tunnel. If you use some kind of X11
proxy on the remote host, Firefox won't care one way or the other, but
the proxy will still end up trying to forward those protocol messages
through the tunnel and fail. Well, in theory you could have something
that wasn't just a proxy, and fooled Firefox into believing that the X11
request suceeded, but that can get arbirtrarily complex, since that
first lie will likely require more and more follow-on lies...
...and then you basically end up implementing a virtual X11 server, but
others have already done that, and in fact that may *be* a workaround -
i.e. you simply don't forward the X11 protocol at all. You could e.g.
run Firefox under Xvnc, and then make a "forward" vnc connection via ssh
port forwarding to interact with it. (I've periodically made extensive
use of this technique, with other clients and for other reasons.)
And of course you could run Firefox locally and tell it to use the
builtin SOCKS server a.k.a. "dynamic forwarding" in the ssh client, if
your problem is that you can't get a direct Internet connection from the
client host.
--Per Hedeland
p...@hedeland.org
Mike
> In article <x7MNi.257672$xp6.2...@fe3.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>
>> I'm thinking here that with ForwardX11Trusted
>>set to yes, the client running it over SSH is vunerable to Firefox
>>security holes and exploits, as if they had it running on the client
>>machine directly.
>
> I'm not sure I follow you here, but anyway the problem that the
> ForwardX11Trusted disabling is addressing isn't with the clients you run
> via the X11 forwarding, but rather with *other* clients that are
> displaying on the same X11 server. I.e. the evil things would use the
> X11 tunnel "itself" to spy on or manipulate those other clients -
> doesn't matter if yo have *any* clients using the tunnel as long as it's
> there. Of course the tunnel could also be used to attack clients that
> *are* running via the tunnel, but if the assumption is that the remote
> host is compromised, there are more direct ways to attack those clients
> anyway.
So, if all my client machines can be trusted, as in, they are all in
my home and only used by people I trust, the ForwardingX11Trusted yes
option does not really present any real problems with regard to a
compromised server machine?
IOW: P2 being the machine connected to the internet, and running
sshd. P1, P3, P4 etc. can ssh into P2 and run P2's applications. All
the P* (!P2) machines will be used by people who will not be seeking
to compromise the house network. I have something heavy and blunt to
prevent that ever happening. ;)
>>The only option I'm seeing here is to work on each desired app to
>>find a workaround to the apps problems with being called via SSH. For
>>instance, both Opera and Dillo complain without the -Y flag, but do
>>function acceptably. Firefox just kicks out a stroppy error message
>>and refuses to play. If Firefox, for example, could be cajoled into
>>accepting a pseudo process on the server it live on, then the SSH
>>client could benefit from having "fooled it".
>
> No, it's not Firefox that is unhappy specifically with being pointed to
> a ssh X11 tunnel, it's ssh that is preventing certain X11 protocol
> messages from getting through the tunnel. If you use some kind of X11
> proxy on the remote host, Firefox won't care one way or the other, but
> the proxy will still end up trying to forward those protocol messages
> through the tunnel and fail. Well, in theory you could have something
> that wasn't just a proxy, and fooled Firefox into believing that the X11
> request suceeded, but that can get arbirtrarily complex, since that
> first lie will likely require more and more follow-on lies...
Damn! So much for that brillant idea then. :(
> ...and then you basically end up implementing a virtual X11 server, but
> others have already done that, and in fact that may *be* a workaround -
> i.e. you simply don't forward the X11 protocol at all. You could e.g.
> run Firefox under Xvnc, and then make a "forward" vnc connection via ssh
> port forwarding to interact with it. (I've periodically made extensive
> use of this technique, with other clients and for other reasons.)
Would this improve the protection of the client machine should the
server be compromised? Or is it just to protect client machines from
each other on the internal network?
> And of course you could run Firefox locally and tell it to use the
> builtin SOCKS server a.k.a. "dynamic forwarding" in the ssh client, if
> your problem is that you can't get a direct Internet connection from the
> client host.
Not so much can't, as won't. I need the offline machines to be able
to access internet browsing, Email etc. without them actually going
online themselves. I need them as isolated from the internet as I can
get them. SSH into P2 user accounts seemed to be the way to do this.
Could SOCKS/dynamic forwarding be another solution here? Or am I
knocking too much china off the shelves right now?
man ssh (-D port section)
Only root can forward privileged ports.
Could be a problem. I install apps in user's dirs to prevent them
having root access as much as possible. this might breach that
protection?
Per Hedeland
<N...@Arizona.Bay> writes:
>Responding to Per Hedeland...
>>
>> I'm not sure I follow you here, but anyway the problem that the
>> ForwardX11Trusted disabling is addressing isn't with the clients you run
>> via the X11 forwarding, but rather with *other* clients that are
>> displaying on the same X11 server. I.e. the evil things would use the
>> X11 tunnel "itself" to spy on or manipulate those other clients -
>> doesn't matter if yo have *any* clients using the tunnel as long as it's
>> there. Of course the tunnel could also be used to attack clients that
>> *are* running via the tunnel, but if the assumption is that the remote
>> host is compromised, there are more direct ways to attack those clients
>> anyway.
>
>So, if all my client machines can be trusted, as in, they are all in
>my home and only used by people I trust, the ForwardingX11Trusted yes
>option does not really present any real problems with regard to a
>compromised server machine?
No - I guess I confused things again with the unqualified used of
"client" here.:-) Protecting against a compromised (or just generally
untrustworthy) *ssh server* is what 'ForwardX11Trusted no' is for.
>> ...and then you basically end up implementing a virtual X11 server, but
>> others have already done that, and in fact that may *be* a workaround -
>> i.e. you simply don't forward the X11 protocol at all. You could e.g.
>> run Firefox under Xvnc, and then make a "forward" vnc connection via ssh
>> port forwarding to interact with it. (I've periodically made extensive
>> use of this technique, with other clients and for other reasons.)
>
>Would this improve the protection of the client machine should the
>server be compromised?
In the sense that 'ForwardX11Trusted no' does, yes - if you don't use
X11 forwarding, there's no need to trust it.:-)
>> And of course you could run Firefox locally and tell it to use the
>> builtin SOCKS server a.k.a. "dynamic forwarding" in the ssh client, if
>> your problem is that you can't get a direct Internet connection from the
>> client host.
>
>Not so much can't, as won't. I need the offline machines to be able
>to access internet browsing, Email etc. without them actually going
>online themselves. I need them as isolated from the internet as I can
>get them. SSH into P2 user accounts seemed to be the way to do this.
>
>Could SOCKS/dynamic forwarding be another solution here?
Sure - and it's generally more efficient too, since you're sending http
rather than the more voluminous X11 protocol through the ssh tunnel.
> man ssh (-D port section)
> Only root can forward privileged ports.
>
>Could be a problem.
No, there is no need to forward privileged ports in this case, the
standard SOCKS port is 1080 and it's generally configurable in the
browser anyway. The drawback is that if the clients do not have *any*
Internet connectivity, both browser and ssh must do SOCKS v5, which can
do DNS lookups via SOCKS (or at least avoid doing them outside SOCKS) -
and the browser has to use this functionality. OpenSSH has had SOCKSv5
for quite a while, and my semi-old Firefox has a selection button for it
- but I wouldn't bet that it actually uses the DNS functionality. You'll
find out soon enough if you try it...
> I install apps in user's dirs to prevent them
>having root access as much as possible.
Hm, that's clearly at odds with standard Unix practice and generally
*reduces* security - if apps are installed as root-owned, in root-owned
directory trees (/usr/bin etc), it's impossible for both evil users and
malware running as those users to tamper with them. Being able to
execute root-owned programs doesn't imply "having root access".
--Per Hedeland
p...@hedeland.org
Mike
> In article <ytUNi.266638$xp6....@fe3.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>Responding to Per Hedeland...
>>>
>>> I'm not sure I follow you here, but anyway the problem that the
>>> ForwardX11Trusted disabling is addressing isn't with the clients you run
>>> via the X11 forwarding, but rather with *other* clients that are
>>> displaying on the same X11 server. I.e. the evil things would use the
>>> X11 tunnel "itself" to spy on or manipulate those other clients -
>>> doesn't matter if yo have *any* clients using the tunnel as long as it's
>>> there. Of course the tunnel could also be used to attack clients that
>>> *are* running via the tunnel, but if the assumption is that the remote
>>> host is compromised, there are more direct ways to attack those clients
>>> anyway.
>>
>>So, if all my client machines can be trusted, as in, they are all in
>>my home and only used by people I trust, the ForwardingX11Trusted yes
>>option does not really present any real problems with regard to a
>>compromised server machine?
>
> No - I guess I confused things again with the unqualified used of
> "client" here.:-) Protecting against a compromised (or just generally
> untrustworthy) *ssh server* is what 'ForwardX11Trusted no' is for.
Its those pesky words again! So basically, a function of
ForwardX11Trusted is to protect an "ssh_client_machine" from an
"ssh_server_machine".
>>> ...and then you basically end up implementing a virtual X11 server, but
>>> others have already done that, and in fact that may *be* a workaround -
>>> i.e. you simply don't forward the X11 protocol at all. You could e.g.
>>> run Firefox under Xvnc, and then make a "forward" vnc connection via ssh
>>> port forwarding to interact with it. (I've periodically made extensive
>>> use of this technique, with other clients and for other reasons.)
>>
>>Would this improve the protection of the client machine should the
>>server be compromised?
>
> In the sense that 'ForwardX11Trusted no' does, yes - if you don't use
> X11 forwarding, there's no need to trust it.:-)
Yeah, that seems logical. :)
>>> And of course you could run Firefox locally and tell it to use the
>>> builtin SOCKS server a.k.a. "dynamic forwarding" in the ssh client, if
>>> your problem is that you can't get a direct Internet connection from the
>>> client host.
>>
>>Not so much can't, as won't. I need the offline machines to be able
>>to access internet browsing, Email etc. without them actually going
>>online themselves. I need them as isolated from the internet as I can
>>get them. SSH into P2 user accounts seemed to be the way to do this.
>>
>>Could SOCKS/dynamic forwarding be another solution here?
>
> Sure - and it's generally more efficient too, since you're sending http
> rather than the more voluminous X11 protocol through the ssh tunnel.
Sounds interesting.
>> man ssh (-D port section)
>> Only root can forward privileged ports.
>>
>>Could be a problem.
>
> No, there is no need to forward privileged ports in this case, the
> standard SOCKS port is 1080 and it's generally configurable in the
> browser anyway. The drawback is that if the clients do not have *any*
> Internet connectivity, both browser and ssh must do SOCKS v5, which can
> do DNS lookups via SOCKS (or at least avoid doing them outside SOCKS) -
> and the browser has to use this functionality. OpenSSH has had SOCKSv5
> for quite a while, and my semi-old Firefox has a selection button for it
> - but I wouldn't bet that it actually uses the DNS functionality. You'll
> find out soon enough if you try it...
I'm guessing here that the ssh_client_machine would be running it's
own browser and simply accessing the internet via SOCKS through the
P2 ssh_server_machine? Unlike the ssh option where the
ssh_client_machine actually runs the ssh_server_machine's browser on
the ssh_server_machine rather than the ssh_client_machine?
>> I install apps in user's dirs to prevent them
>>having root access as much as possible.
>
> Hm, that's clearly at odds with standard Unix practice and generally
> *reduces* security - if apps are installed as root-owned, in root-owned
> directory trees (/usr/bin etc), it's impossible for both evil users and
> malware running as those users to tamper with them. Being able to
> execute root-owned programs doesn't imply "having root access".
I just knew I'd missed something! Damn!
My problem was in using non-GNU stuff like Firefox. I don't like
trusting something with an option to let it automatically install
things from the internet to run as root, therefore I dropped it into
my user dirs to limit any damage it might cause.
The maybe some kind of "applications" group for apps like this? Users
can use it, but access is restricted as if the apps were root owned.
Always something to do huh? ;)
Per Hedeland
<N...@Arizona.Bay> writes:
>Responding to Per Hedeland...
>>
>> "client" here.:-) Protecting against a compromised (or just generally
>> untrustworthy) *ssh server* is what 'ForwardX11Trusted no' is for.
>
>Its those pesky words again! So basically, a function of
>ForwardX11Trusted is to protect an "ssh_client_machine" from an
>"ssh_server_machine".
I prefer my formulation, which left out the "what is protected" part.
E.g. you could have X11 clients, running on hosts that are neither your
"ssh_client_machine" nor your "ssh_server_machine", displaying on the
X11 server on your "ssh_client_machine", and those hosts could also be
attacked.
>I'm guessing here that the ssh_client_machine would be running it's
>own browser and simply accessing the internet via SOCKS through the
>P2 ssh_server_machine? Unlike the ssh option where the
>ssh_client_machine actually runs the ssh_server_machine's browser on
>the ssh_server_machine rather than the ssh_client_machine?
Yes. Of course you could instead run a "normal" SOCKS server on P2,
doing away with the ssh tunneling altogether.
>My problem was in using non-GNU stuff like Firefox. I don't like
>trusting something with an option to let it automatically install
>things from the internet to run as root, therefore I dropped it into
>my user dirs to limit any damage it might cause.
I'm not sure where you're coming from, AFAIK even in the Windows world
the owner of an executable file has no relevance for the privileges of
the running program. In Unix you can make it so by setting the set-uid
bit, but of course that would be a crazy thing to do with a browser (or
any other program that isn't intented to be run that way). It would be a
bit of a problem if /bin/cat or /bin/sh ran with root privileges just
because root owned the executables. But this subject is quite off-topic
here, I suggest you take it to comp.unix.questions or somesuch.
--Per Hedeland
p...@hedeland.org
Mike
> In article <1S2Oi.275621$xp6....@fe3.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>Responding to Per Hedeland...
>>>
>>> No - I guess I confused things again with the unqualified used of
>>> "client" here.:-) Protecting against a compromised (or just generally
>>> untrustworthy) *ssh server* is what 'ForwardX11Trusted no' is for.
>>
>>Its those pesky words again! So basically, a function of
>>ForwardX11Trusted is to protect an "ssh_client_machine" from an
>>"ssh_server_machine".
>
> I prefer my formulation, which left out the "what is protected" part.
> E.g. you could have X11 clients, running on hosts that are neither your
> "ssh_client_machine" nor your "ssh_server_machine", displaying on the
> X11 server on your "ssh_client_machine", and those hosts could also be
> attacked.
Er, ok. So the ForwardX11Trusted is off by default to protect
everything from everything, both up and down the SSH line?
>>I'm guessing here that the ssh_client_machine would be running it's
>>own browser and simply accessing the internet via SOCKS through the
>>P2 ssh_server_machine? Unlike the ssh option where the
>>ssh_client_machine actually runs the ssh_server_machine's browser on
>>the ssh_server_machine rather than the ssh_client_machine?
>
> Yes. Of course you could instead run a "normal" SOCKS server on P2,
> doing away with the ssh tunneling altogether.
Oops. thats not what I meant. I was thinking that if SOCKS was used
via SSH, then the client machine would have to use it's own installed
browser instead of one installed on the server machine? (No ssh
means no secured connection, right?)
>>My problem was in using non-GNU stuff like Firefox. I don't like
>>trusting something with an option to let it automatically install
>>things from the internet to run as root, therefore I dropped it into
>>my user dirs to limit any damage it might cause.
>
> I'm not sure where you're coming from,
Firefox has an option to let it accept remote instructions to install
stuff. While this is only (I think) Mozilla certified extras, its
still a tad to automatic for my liking for a root owned process.
(Seamonkey is even worse with the option to "Allow websites to
install extensions and updates") Not the kind of thing I'm
comfortable having run as root really.
> AFAIK even in the Windows world
> the owner of an executable file has no relevance for the privileges of
> the running program. In Unix you can make it so by setting the set-uid
> bit, but of course that would be a crazy thing to do with a browser (or
> any other program that isn't intented to be run that way). It would be a
> bit of a problem if /bin/cat or /bin/sh ran with root privileges just
> because root owned the executables. But this subject is quite off-topic
> here, I suggest you take it to comp.unix.questions or somesuch.
Yeah, we do seem to have wandered a bit, so when I've read up a bit
more on these matters, I may just do that.
Thanks for the hints tips and clues. :)
Per Hedeland
<N...@Arizona.Bay> writes:
>Responding to Per Hedeland...
>>
>> E.g. you could have X11 clients, running on hosts that are neither your
>> "ssh_client_machine" nor your "ssh_server_machine", displaying on the
>> X11 server on your "ssh_client_machine", and those hosts could also be
>> attacked.
>
>Er, ok. So the ForwardX11Trusted is off by default to protect
>everything from everything, both up and down the SSH line?
Hm, I'm not sure this discussion is all that productive anymore - I
suggest that you sit back and read not just what I've already written,
but also try to read up on the relevant technical issues in general.
>> Yes. Of course you could instead run a "normal" SOCKS server on P2,
>> doing away with the ssh tunneling altogether.
>
>Oops. thats not what I meant. I was thinking that if SOCKS was used
>via SSH, then the client machine would have to use it's own installed
>browser instead of one installed on the server machine?
I already answered that with the "Yes."
> (No ssh means no secured connection, right?)
There's probably not much advantage for you in having an encrypted
connection within your private LAN.
>Firefox has an option to let it accept remote instructions to install
>stuff. While this is only (I think) Mozilla certified extras, its
>still a tad to automatic for my liking for a root owned process.
Again, the fact that root owns the executable in no way implies that
the process will run as root.
--Per Hedeland
p...@hedeland.org
Mike
> In article <I5cOi.114014$BW4....@fe1.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>Responding to Per Hedeland...
>>>
>>> I prefer my formulation, which left out the "what is protected" part.
>>> E.g. you could have X11 clients, running on hosts that are neither your
>>> "ssh_client_machine" nor your "ssh_server_machine", displaying on the
>>> X11 server on your "ssh_client_machine", and those hosts could also be
>>> attacked.
>>
>>Er, ok. So the ForwardX11Trusted is off by default to protect
>>everything from everything, both up and down the SSH line?
>
> Hm, I'm not sure this discussion is all that productive anymore - I
> suggest that you sit back and read not just what I've already written,
> but also try to read up on the relevant technical issues in general.
Good idea. I'm finding getting the idea of just how SSH does what it
does, and what that is and is not, a tad confusing. I suppose its
down to when the basic idea sinks in.
>>> Yes. Of course you could instead run a "normal" SOCKS server on P2,
>>> doing away with the ssh tunneling altogether.
>>
>>Oops. thats not what I meant. I was thinking that if SOCKS was used
>>via SSH, then the client machine would have to use it's own installed
>>browser instead of one installed on the server machine?
>
> I already answered that with the "Yes."
There is that confusion again.
>> (No ssh means no secured connection, right?)
>
> There's probably not much advantage for you in having an encrypted
> connection within your private LAN.
Apart from the restrictions SSH places, providing some security
should the server machine be compromised? A direct connection would
not have that kind of protection process would it? Plus, its a damn
good way to ensure nothing gets logged in without having been
specifically set up first.
>>Firefox has an option to let it accept remote instructions to install
>>stuff. While this is only (I think) Mozilla certified extras, its
>>still a tad to automatic for my liking for a root owned process.
>
> Again, the fact that root owns the executable in no way implies that
> the process will run as root.
Thats the theory, but I'm not convinced when it comes to stuff
produced by large corporations like Time/Warner/AOL. Yes, I know its
supposed to be the Mozilla team working independantly, but a browser
that is set up to install things "seamlessly" rings bells in my mind.
A nice pot of tea and a spot of reading up time is in order I think.
Per Hedeland
<N...@Arizona.Bay> writes:
>Responding to Per Hedeland...
>>
>> connection within your private LAN.
>
>Apart from the restrictions SSH places, providing some security
>should the server machine be compromised? A direct connection would
>not have that kind of protection process would it? Plus, its a damn
>good way to ensure nothing gets logged in without having been
>specifically set up first.
I really don't know what you mean by any of that, and I'm not sure you
do either. If I were to guess at interpretation, I don't see anything
that you wouldn't achieve with telnet - not that I recommend using
telnet for remote login - but then your described usage didn't really
call for remote login either.
>> Again, the fact that root owns the executable in no way implies that
>> the process will run as root.
>
>Thats the theory, but I'm not convinced when it comes to stuff
>produced by large corporations like Time/Warner/AOL.
No, it's not theory, it's the practice of how Unix works, regardless of
what paranoid conspiracy theories you may have. Of course if you run an
*installation procedure* provided by a third party as root, it could
conceivably install something setuid-root - but that can fairly easily
be detected with a 'find' command. And while installation procedures are
frequently provided by a third party and run as root, I'll bet that in
your case that third party is not the producer of the software you're
installing, but the producer of your OS and its package manager (where
different).
--Per Hedeland
p...@hedeland.org
Mike
> In article <ZqwOi.114888$BW4....@fe1.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>Responding to Per Hedeland...
>>>
>>> There's probably not much advantage for you in having an encrypted
>>> connection within your private LAN.
>>
>>Apart from the restrictions SSH places, providing some security
>>should the server machine be compromised? A direct connection would
>>not have that kind of protection process would it? Plus, its a damn
>>good way to ensure nothing gets logged in without having been
>>specifically set up first.
>
> I really don't know what you mean by any of that, and I'm not sure you
> do either. If I were to guess at interpretation, I don't see anything
> that you wouldn't achieve with telnet - not that I recommend using
> telnet for remote login - but then your described usage didn't really
> call for remote login either.
If a key-based SSH login is the only thing the server machine will
accept, then anything else plugged into the network is effectively
isolated by default. Maybe overkill, but at least thats one set of
possible problems cut out of the list of who did what and when. Thats
the logic I've been working on, plus, by the time I finally get the
idea, I might one day need to allow an ssh login from another
location, say dial-in from a holiday location for instance, and will
be competant to set that up effectively.
>>> Again, the fact that root owns the executable in no way implies that
>>> the process will run as root.
>>
>>Thats the theory, but I'm not convinced when it comes to stuff
>>produced by large corporations like Time/Warner/AOL.
>
> No, it's not theory, it's the practice of how Unix works, regardless of
> what paranoid conspiracy theories you may have.
Paranoid conspiracy theories are the stuff of security. Otherwise
security is only re-active, and not pro-active. ;)
> Of course if you run an
> *installation procedure* provided by a third party as root, it could
> conceivably install something setuid-root - but that can fairly easily
> be detected with a 'find' command.
Assuming this will be the only problem of course?
> And while installation procedures are frequently provided by a
> third party and run as root, I'll bet that in your case that third
> party is not the producer of the software you're installing, but
> the producer of your OS and its package manager (where different).
Firefox just expands ready to use. The only thing doing this as a
user misses out on is the placing of basic config files under /etc.
Or at least thats what the install readme says.
As I have no idea just what Firefox is designed to do, nor how it
does those things, and it comes with a user option to allow the
browser to install things automatically, that is enough for me to be
at least unsure if I should trust it with root access to my system.
So, maybe I AM a tad overcautious, but the other option would simply
be to trust everything until something does the inevitable.
But I think we're drifting away from SSH related topics.
Per Hedeland
<N...@Arizona.Bay> writes:
>
>> Of course if you run an
>> *installation procedure* provided by a third party as root, it could
>> conceivably install something setuid-root - but that can fairly easily
>> be detected with a 'find' command.
>
>Assuming this will be the only problem of course?
There is no assuming about it, it is the *only* way the process could
run as root if invoked by a non-root user.
>As I have no idea just what Firefox is designed to do, nor how it
>does those things, and it comes with a user option to allow the
>browser to install things automatically, that is enough for me to be
>at least unsure if I should trust it with root access to my system.
OK, I promise that I won't repeat it any more, but: You are *not*
"trusting it with root access to your system" by installing the files
with root ownership - as long as there are no executable files with the
set-uid (or set-gid) bit set, installing them with root ownership can
only *increase* security.
--Per Hedeland
p...@hedeland.org
Mike
> In article <gp1Pi.122559$BW4....@fe1.news.blueyonder.co.uk> Mike
><N...@Arizona.Bay> writes:
>>
>>> Of course if you run an
>>> *installation procedure* provided by a third party as root, it could
>>> conceivably install something setuid-root - but that can fairly easily
>>> be detected with a 'find' command.
>>
>>Assuming this will be the only problem of course?
>
> There is no assuming about it, it is the *only* way the process could
> run as root if invoked by a non-root user.
Not what I meant. I meant that there could be problems other
than installing something setuid-root. This would depend on the
intent and/or design of the installed application of course.
>>As I have no idea just what Firefox is designed to do, nor how it
>>does those things, and it comes with a user option to allow the
>>browser to install things automatically, that is enough for me to be
>>at least unsure if I should trust it with root access to my system.
>
> OK, I promise that I won't repeat it any more, but: You are *not*
> "trusting it with root access to your system" by installing the files
> with root ownership - as long as there are no executable files with the
> set-uid (or set-gid) bit set, installing them with root ownership can
> only *increase* security.
While I can grasp the idea that a root owned config file, or other
non-executable file, is way safer owned by root when user processes
are connected to an untrusted network like the internet, the idea of
executables I don't trust having root privileges still bothers me.
Maybe some kind of intermediate permission/owner environment? Users
can use it, but its not root either. Just thinking out loud here.
P.S.
As we appear to have drifted way off the original SSH related
subject matter, should we be taking this somewhere else about now?
Per Hedeland
<N...@Arizona.Bay> writes:
>As we appear to have drifted way off the original SSH related
>subject matter, should we be taking this somewhere else about now?
I suggest you take it to some introductory textbook on Unix, since you
clearly do not understand basic principles of the execution model no
matter how many times I try to explain them to you. Please do not
followup here on this subject again - we're way off-topic, but I have a
problem with leaving the last article in a thread that is Google-
archived for all future full of factually incorrect statements. If you
feel you need to say something more to me, the 'From:' address on all my
posts is fully functional - but please do some reading first.
--Per Hedeland
p...@hedeland.org
Mike
Point taken, though I do feel moved to add this.
Several times over, I'd not realised exactly what you were trying to
explain, and don't think I got across what my questions were actually
about very well either. Therefore, we may have wandered past the
point we actually were discussing precisely the same thing on more
than one "curve". I've learned things that will doubtless prove
useful anyhow, so thanks for your time and effort here.
If nothing else, at least I'm now better equipped to seek out and
absorb the information I need to get my head around the stuff I've
been messing around with, so, despite any frustrations that might
have arisen, and my lack of clarity, something productive has
resulted.
Thanks once again for your help.
Darren Tucker
[...]
> No, there is no need to forward privileged ports in this case, the
> standard SOCKS port is 1080 and it's generally configurable in the
> browser anyway. The drawback is that if the clients do not have *any*
> Internet connectivity, both browser and ssh must do SOCKS v5, which can
> do DNS lookups via SOCKS (or at least avoid doing them outside SOCKS) -
> and the browser has to use this functionality. OpenSSH has had SOCKSv5
> for quite a while, and my semi-old Firefox has a selection button for it
> - but I wouldn't bet that it actually uses the DNS functionality. You'll
> find out soon enough if you try it...
Firefox has a button for the remote DNS lookups but it's off by default.
Go to the about:config page and look for "network.proxy.socks_remote_dns".
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.