2

For some reason, a running dropbear sshd i've got going in a Docker container is telling me Bad password attempt , even though i've doublechecked multiple times that both username and password is 100% correct.

Dropbear is being started by supervisord with the following command:

/usr/local/sbin/dropbear -F -E -p 2222

by a user and group 'mysticbbs'. No errors are coming up when dropbear runs..

However, when i try to ssh into the container from the host computer, with:

ssh -o UserKnownHostsFile=/dev/null localhost -l mysticbbs -p 2222

('-o UserKnownHostsFile=/dev/null' , to prevent storing lots of different keys generated during testing/building of the dockerfile)

..ssh, like expected, gives me:

ECDSA key fingerprint is SHA256:0WadKddpa*[..blabla.]* Are you sure you want to continue connecting (yes/no)?

I'm then asked for the password. But whether or not i type it in, or paste it in, 100% correctly..I still get Permission denied, please try again. and dropbear logs the attempt with Bad password attempt for 'mysticbbs' from 172.17.0.1:35152 ..

  • I've tried setting a different/more complex password
  • Trying to ssh with dbclient from inside the container, with same user dropbear is running under, and running dropbear without using supervisord, makes no difference. (Bad password attempt for 'mysticbbs' from 127.0.0.1:48110) ..
  • The /etc/dropbear folder (and the keys) is chowned to 'mysticbbs:mysticbbs' and chmod to 700
  • The same problem occurs whether or not i use the dropbear from alpine's apk repo (v2018.76-r2), or build it from dropbear.nl source (both v2018.76 and v2017.75 tested)..
  • Deleting the keys and manually running dropbear with -R argument makes no difference.
  • Found a notation at https://github.com/mkj/dropbear , but i can't see how that could apply since user attempted to ssh in is the same as the one running dropbear:

>

If the server is run as non-root, you most likely won't be able to allocate a pty, and you cannot login as any user other than that running the daemon (obviously). Shadow passwords will also be unusable as non-root.

  • Shadow passwords just might the culprit..

Keys are generated during the docker build with the following:

   export RSA_KEYFILE=/etc/dropbear/dropbear_rsa_host_key
   export DSS_KEYFILE=/etc/dropbear/dropbear_dss_host_key
   export ECDSA_KEYFILE=/etc/dropbear/dropbear_ecdsa_host_key
   dropbearkey -t dss -f $DSS_KEYFILE
   dropbearkey -t rsa -f $RSA_KEYFILE
   dropbearkey -t ecdsa -f $ECDSA_KEYFILE
   chown -R mysticbbs:mysticbbs /etc/dropbear
   chmod -R 700 /etc/dropbear

password for mysticbbs user is set during docker build with:

   passwd mysticbbs -d '<password>' -u

What am i missing?..

DhP
  • 41
  • 2
  • 6

1 Answers1

0

As pointed to by @michael-hampton in comment, and the note at https://github.com/mkj/dropbear:

If the server is run as non-root, you most likely won't be able to allocate a pty, and you cannot login as any user other than that running the daemon (obviously). Shadow passwords will also be unusable as non-root.

My problems seems indeed to arise at shadow passwords when running dropbear as non-root user.

In my specific case, under alpine:3.9/BusyBox, it seems a more valid solution and workaround for me to add root to my 'mysticbbs' group, and drop root privileges as needed, rather than make /etc/shadow accessible to a user other than root (by e.g adding the 'mysticbbs', or a dedicated system user, to 'shadow' group(?)..I'm not even going to test that. Though i guess that could also be a potential workaround.).

EDIT: Adding the user that dropbear is being run under to shadow group just seems easier..And after all /etc/shadow is still chmod 640 (writable to root user only, though readable to shadow group)

ls -la /etc/shadow

-rw-r----- 1 root shadow 503 Feb 6 16:33 /etc/shadow

(Note: Probably not recommended in where high security is top priority though)

DhP
  • 41
  • 2
  • 6