Loading ...
Sorry, an error occurred while loading the content.

Re: Only root can SFTP?

Expand Messages
  • Simon J. Melhuish
    I am getting this too, with my unslung CS-406 Cube Station. Any help would be much appreciated. Simon
    Message 1 of 5 , Jul 5, 2007
    • 0 Attachment
      I am getting this too, with my unslung CS-406 Cube Station. Any help
      would be much appreciated.

      Simon
    • Brian Zhou
      AdamBaker in #nslu2-linux investigated some more on this problem. And looks like bash 3.2-3 is the culprit. Root does not have this problem simply because root
      Message 2 of 5 , Jul 16, 2007
      • 0 Attachment
        AdamBaker in #nslu2-linux investigated some more on this problem. And
        looks like bash 3.2-3 is the culprit.

        Root does not have this problem simply because root is not using bash.

        I can confirm that reverting to bash_3.2-2 makes everything working again.

        -Brian Zhou

        --- In nslu2-general@yahoogroups.com, "Michael" <jm@...> wrote:
        >
        > Hi, I recently did an "ipkg upgrade" and for whatever reason normal
        > users can no longer use SFTP or SCP. A normal user can SSH just fine,
        > but SFTP results in a connection closed message.
        >
        > Anyone have any idea what could be causing this? I've tested
        > /opt/libexec/sftp-server and it seems to have the right permissions
        > and is runnable by normal users.
        >
        > /var/log/messages says the following for the login attempt:
        > <35>Jun 27 14:18:52 sshd[525]: error: Could not get shadow information
        > for root
        > <38>Jun 27 14:18:53 sshd[525]: Accepted password for root from
        > 128.171.157.174 port 2550 ssh2
        > <38>Jun 27 14:18:53 sshd[525]: subsystem request for sftp
        >
        > However these messages are identical to a successful login.
        >
        > Any help would be appreciated.
        >
        > Cheers,
        > --Mike
        >
      • Brian Zhou
        in #nslu2-linux 16:01 Progress I think - I ve tried to recreate the scenario of how bash gets started by openssh and the result is bash
        Message 3 of 5 , Jul 16, 2007
        • 0 Attachment
          in #nslu2-linux

          16:01 < AdamBaker> Progress I think - I've tried to recreate the
          scenario of how bash gets started by openssh and the result is bash
          segfaulting. Unfortunately the stack is corrupted in the core dump.
          16:12 < AdamBaker> It seems that when used with the -c option the
          latest bash must be started with a valid $PWD in the environment. I
          can verify that (after sleeping) by adding it to the environment in my
          wrapper.

          The good news is that I found the problem starts with bash 3.2 patch
          level 11, and it has a lot to do with getcwd. It turns out one of the
          configuration detection was not performed because of cross
          compilation, and the default value has bad interaction with the patch
          level 11 getcwd related change.

          The latest bash_3.2.17-1 solved the problem. I also changed the bash
          version number like `bash --version`.

          Cheers,


          -Brian


          --- In nslu2-general@yahoogroups.com, "Brian Zhou" <b88zhou@...> wrote:
          >
          > AdamBaker in #nslu2-linux investigated some more on this problem. And
          > looks like bash 3.2-3 is the culprit.
          >
          > Root does not have this problem simply because root is not using bash.
          >
          > I can confirm that reverting to bash_3.2-2 makes everything working
          again.
          >
          > -Brian Zhou
          >
          > --- In nslu2-general@yahoogroups.com, "Michael" <jm@> wrote:
          > >
          > > Hi, I recently did an "ipkg upgrade" and for whatever reason normal
          > > users can no longer use SFTP or SCP. A normal user can SSH just fine,
          > > but SFTP results in a connection closed message.
          > >
          > > Anyone have any idea what could be causing this? I've tested
          > > /opt/libexec/sftp-server and it seems to have the right permissions
          > > and is runnable by normal users.
          > >
          > > /var/log/messages says the following for the login attempt:
          > > <35>Jun 27 14:18:52 sshd[525]: error: Could not get shadow information
          > > for root
          > > <38>Jun 27 14:18:53 sshd[525]: Accepted password for root from
          > > 128.171.157.174 port 2550 ssh2
          > > <38>Jun 27 14:18:53 sshd[525]: subsystem request for sftp
          > >
          > > However these messages are identical to a successful login.
          > >
          > > Any help would be appreciated.
          > >
          > > Cheers,
          > > --Mike
          > >
          >
        • Simon Melhuish
          Thank you Brian - I m running again now with sftp to my slug, and no doubt would be to the Cube Station had it not had a hardware failure! Cheers, Simon
          Message 4 of 5 , Jul 28, 2007
          • 0 Attachment
            Thank you Brian - I'm running again now with sftp to my slug, and no
            doubt would be to the Cube Station had it not had a hardware failure!

            Cheers,

            Simon

            Brian Zhou wrote:
            > in #nslu2-linux
            >
            > 16:01 < AdamBaker> Progress I think - I've tried to recreate the
            > scenario of how bash gets started by openssh and the result is bash
            > segfaulting. Unfortunately the stack is corrupted in the core dump.
            > 16:12 < AdamBaker> It seems that when used with the -c option the
            > latest bash must be started with a valid $PWD in the environment. I
            > can verify that (after sleeping) by adding it to the environment in my
            > wrapper.
            >
            > The good news is that I found the problem starts with bash 3.2 patch
            > level 11, and it has a lot to do with getcwd. It turns out one of the
            > configuration detection was not performed because of cross
            > compilation, and the default value has bad interaction with the patch
            > level 11 getcwd related change.
            >
            > The latest bash_3.2.17-1 solved the problem. I also changed the bash
            > version number like `bash --version`.
            >
            > Cheers,
            >
            >
            > -Brian
          Your message has been successfully submitted and would be delivered to recipients shortly.