I have it running as a separate daemon on a few systems as a non root user
without problems..
I changed the config.h to disable all the features which might require more
rights than the user has or uses OS functions....  for instance
 DISABLE_PAM, DISABLE_LASTLOG,  DISABLE_SYSLOG
I only use the user daemon with ssh keys...

Also I changed the locations of all the needed files to a local locaition
for instance in the options.h file  where the hostkeys are located
 (removed the /etc path from it)

That should make it work I believe


Hans


On Fri, Jun 10, 2016 at 10:43 AM, Nixon, Kent W <k...@pitt.edu> wrote:

> Hi all,
>
> I'm currently testing my (default) compile settings of dropbear 2016.73 on
> an x86_64 Ubuntu 14.04 machine. I'm running the dropbear server from the
> terminal of a standard user account and attempting to connect using
> dbclient as that same user from the same machine just to test/learn how to
> use dropbear before I attempt to cross-compile it and run it on an Android
> system.
>
> I currently run the following command to start the server:
>
> dropbear -F -p 6666 -E -R -m
>
> And attempt to connect (using the same machine) as the same user that is
> running dropbear using:
>
> dbcleint -p 6666 -y <username>@127.0.0.1
>
> Everything seems to work well, except that after I enter the appropriate
> password, the client is rejected by the server which posts the message:
>
> User account '<username>' is locked
>
> However, following the same steps as above, but running the dropbear
> server with root permissions, everything works as expected (i.e. I am able
> to open a remote shell without any problems).
>
> What changes when dropbear is run with standard user permissions that is
> causing the account to be 'locked'? Do I need to locate the rsa/dss/ecdsa
> keys somewhere else other than /etc/dropbear/?
>
> Thanks in advance for your time and consideration!
>
> ~ Kent
>

Reply via email to