Quote:
Originally Posted by ezdiy
It might either not like the symlink, or the silly permissions on the fat partition. To figure out what dropbear doesn't like, just launch another instance via /mnt/secure/bin/dropbear -F -p 33 -m -B -Y somepassword -H /mnt/secure in foreground, and it should jabber about what it does not like.
|
[1018] Dec 06 01:13:13 /mnt/secure/.ssh must be owned by user or root, and not writable by others
^C[1011] Dec 06 01:13:27 Early exit: Terminated by signal
/mnt/secure # ls -ald /mnt/secure/.ssh /mnt/ext1/.ssh
drwxrwxrwx 2 root root 4096 Dec 1 13:07 /mnt/ext1/.ssh
lrwxrwxrwx 1 root root 14 Dec 5 23:09 /mnt/secure/.ssh -> /mnt/ext1/.ssh
So yeah, it doesn't like the mode. And chmod has no effect, because of its mount mode:
Quote:
|
/dev/user_int on /mnt/ext1 type vfat (rw,dirsync,nosuid,nodev,noatime,fmask=0000,dmask= 0000,allow_utime=0022,codepage=437,iocharset=utf8, shortname=mixed,errors=remount-ro)
|
Could you neuter
that dropbear check (return success)?
Quote:
Originally Posted by ezdiy
Quote:
Originally Posted by Marco77
- Generally in PBTerm /mnt/secure/su command works, any idea why /bin/sh doesn't return control?
|
Not sure what you mean. |
/mnt/secure/su /bin/sh
does not give a root shell. Maybe because of not having a pty for non-root, not too sure.
Quote:
Originally Posted by ezdiy
|
Yup, now it works! Thanks!
