Partial SNAFUs - X11Forwarding etc. - SSH

This is a discussion on Partial SNAFUs - X11Forwarding etc. - SSH ; 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 username@192.168.1.? PermitRootLogin no HostKey /etc/ssh/ssh_host_dsa_key PubkeyAuthentication ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Partial SNAFUs - X11Forwarding etc.

  1. Partial SNAFUs - X11Forwarding etc.


    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 username@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

  2. Re: Partial SNAFUs - X11Forwarding etc.

    In article Mike
    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
    per@hedeland.org

  3. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article Mike
    > 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!

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  4. Re: Partial SNAFUs - X11Forwarding etc.

    Responding (again) to Per Hedeland...
    > In article Mike
    > 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: { url='file:///home/username/HomePage/index.html' '>}
    Dpi: [Dpi_process_io] IOClose
    Type check: [Srv: text/html Det: text/plain]
    Dpi_parse_token: { url='file:///home/username/HomePage/icon.gif' '>}
    Dpi_parse_token: { 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: { url='file:///home/username/HomePage/index.html' '>}
    Dpi: [Dpi_process_io] IOClose
    Type check: [Srv: text/html Det: text/plain]
    Dpi_parse_token: { url='file:///home/username/HomePage/icon.gif' '>}
    Dpi_parse_token: { 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.

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  5. Re: Partial SNAFUs - X11Forwarding etc.

    In article Mike
    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
    per@hedeland.org

  6. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article Mike
    > 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?

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  7. Re: Partial SNAFUs - X11Forwarding etc.

    In article Mike
    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
    per@hedeland.org

  8. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article Mike
    > 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?

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  9. Re: Partial SNAFUs - X11Forwarding etc.

    In article Mike
    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
    per@hedeland.org

  10. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article Mike
    > 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?

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  11. Re: Partial SNAFUs - X11Forwarding etc.

    In article <1S2Oi.275621$xp6.59983@fe3.news.blueyonder.co.uk> Mike
    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.

    >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
    per@hedeland.org

  12. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article <1S2Oi.275621$xp6.59983@fe3.news.blueyonder.co.uk> Mike
    > 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.

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  13. Re: Partial SNAFUs - X11Forwarding etc.

    In article Mike
    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.

    >> 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
    per@hedeland.org

  14. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article Mike
    > 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.

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  15. Re: Partial SNAFUs - X11Forwarding etc.

    In article Mike
    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.

    >> 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
    per@hedeland.org

  16. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article Mike
    > 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.

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  17. Re: Partial SNAFUs - X11Forwarding etc.

    In article Mike
    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
    per@hedeland.org

  18. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article Mike
    > 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?

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

  19. Re: Partial SNAFUs - X11Forwarding etc.

    In article <5tcPi.313083$xp6.158309@fe3.news.blueyonder.co.uk> Mike
    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
    per@hedeland.org

  20. Re: Partial SNAFUs - X11Forwarding etc.

    Responding to Per Hedeland...
    > In article <5tcPi.313083$xp6.158309@fe3.news.blueyonder.co.uk> Mike
    > 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.
    >


    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.

    --
    Yellow Submarine?
    Nah. Its a TeaPot!
    www.tinyurl.com/382gmp

+ Reply to Thread
Page 1 of 2 1 2 LastLast