.ssh/environment equivalent in dropbear

Christoph Kurrat c.kurrat at googlemail.com
Mon Aug 27 19:16:10 WST 2007

2007/8/27, Rob Landley <rob at landley.net>:
> On Sunday 26 August 2007 8:29:26 am Christoph Kurrat wrote:
> > The busybox uses ash, but an .ash* file does not exist.
> > If I create the .ashrc and export ENV=/var/tmp/.ashrc it works, but to
> > export ENV, I again need the /etc/profile.
> Um...  What?  I _think_ you just said "If I put it in ~/.ashrc it works".  In
> which case: happy to hear it.  In which case where does the need
> for /etc/profile come in?

If I put it into ~/.ashrc end export ENV=/var/tmp/.ashrc it works, if
this export is inside /etc/profile.
I need /etc/profile, because an export inside the
dropbear-start-script does not influence the environment in an SSH

> > This works, but only with ssh, not with scp, due to the missing login.
> >
> > I found this sentence at
> > http://www.busybox.net/lists/busybox/2005-February/013688.html
> >
> > "Environment variables set in a shell script will not have any effect to
> > any parent process."
> Except it's child processes you're worrying about here, not parent processes.

I thought, the SSH sessions would fork from a parent process of the

> That limitation has nothing to do with shells, it has to do with the way unix
> processes work.  When you exec a process you pass in a new environment to it
> along with the command line arguments.  A parent can pass its existing
> environment variables to a child (it's not _obligated_ to, but generally
> does), but the parent can't modify the child's environment _after_ exec, and
> the child can't modify the parent's environment either.  They're separate
> processes, they can't reach in and fiddle with each other's internals.
> So if the shell sources a chunk of shell script before running a child
> process, it can pass exported variables on to that child process.

Thanks for that explanation, these details were new to me.

> > I think this is my problem, because the $PATH in an ssh session seems to be
> > a different one than the $PATH I get executing echo $PATH without logging
> > in.
> If $PATH is blank I believe ash sets it to _PATH_STDPATH out
> of /usr/include/paths.h which is "/usr/bin:/bin:/usr/sbin:/sbin".

OK, so before login, the PATH was blank.
Is that a regular behavior?

Anyway, with the PATH set inside of dropbear, it works.


More information about the Dropbear mailing list