Re: Login attempt for nonexistent user

[Laurent Bourdel]

Hi Matt,

Yes you are right, with strace i see missing files :
03   open("/usr/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
103   stat64("/usr/lib", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
103   open("/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
103   open("/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)

I build glibc-2.22 and install lib in my UDOO's rootfs

After that, dropbear is working nice :
118   open("/usr/lib/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 7
118   read(7, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0x\r\0\0004\0\0\0T\257\1\0\2\4\0\0054\0"...,
 512) = 512
118   fstat64(7, {st_mode=S_IFREG|0755, st_size=111940, ...}) = 0
118   mmap2(NULL, 86620, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 7, 0) 
= 0x76d6
118   mprotect(0x76d64000, 65536, PROT_NONE) = 0
118   mmap2(0x76d74000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 7, 0x4000) = 0x76d74000
118   close(7)                          = 0
Thanks a lot Matt

I just have one question about dropbear_dss_host_key & dropbear_rsa_host_key
I don't why we need to generate these keys ?

We normally only need public key from client in authorized_key file ?

Have a nice week
Laurent




Le mercredi 31 octobre 2018 à 14:35:44 UTC+1, Matt Johnston  a 
écrit : 





Hi Laurent,

My best guess is that it was built on lubuntu which uses glibc, but the Udoo 
board doesn't have the required /lib/somewhere/libnss*.so libraries - those get 
chosen at runtime based on /etc/nsswitch.conf. Building using a uclibc cross 
compiler would avoid that - how did you build it? Also which distribution does 
Udoo use?

If you can install strace on the Udoo board you can see what files are being 
tried with
strace -f -F -o logfile -s 300 dropbear -vFE

Cheers,
Matt


> On Tue 30/10/2018, at 5:28 pm, Laurent Bourdel  wrote:
> 
> 
> 
> 
> with correct subject :
> 
> Hi,I fail to login with ssh client to dropboxI use Udoo ARM board with 
> busybox to install ssh serverI cross compiled dropbear under VirtualBox 
> lubuntu and install binary to board ( /bin & /sbin)I generate RSA key 
> (ssh-keygen -t rsa ) under lubuntu and copied  content to 
> /home/root/.ssh/authorized_keys on Udoo boardI run on Udoo board : dropbear 
> -vFEOn VM lubuntu : ssh  -vvv root@192.168.0.2I add trace on dropbear sources 
> and found problem come with function getpwnam to read /etc/password with 
> errno=0;pw = getpwnam(username);dropbear_log(LOG_WARNING,"LBR %s %d 
> %s",__FILE__ ,__LINE__, strerror(errno));if (!pw) {return;}[157] Jan 01 
> 01:06:50 LBR common-session.c 595 No such file or directory

Re: Login attempt for nonexistent user

[Matt Johnston]

Hi Laurent,

My best guess is that it was built on lubuntu which uses glibc, but the Udoo 
board doesn't have the required /lib/somewhere/libnss*.so libraries - those get 
chosen at runtime based on /etc/nsswitch.conf. Building using a uclibc cross 
compiler would avoid that - how did you build it? Also which distribution does 
Udoo use?

If you can install strace on the Udoo board you can see what files are being 
tried with
strace -f -F -o logfile -s 300 dropbear -vFE

Cheers,
Matt


> On Tue 30/10/2018, at 5:28 pm, Laurent Bourdel  wrote:
> 
> 
> with correct subject :
> 
> Hi,
> 
> I fail to login with ssh client to dropbox
> 
> I use Udoo ARM board with busybox to install ssh server
> 
> I cross compiled dropbear under VirtualBox lubuntu and install binary to 
> board ( /bin & /sbin)
> 
> I generate RSA key (ssh-keygen -t rsa ) under lubuntu and copied  content to 
> /home/root/.ssh/authorized_keys on Udoo board
> 
> I run on Udoo board : dropbear -vFE
> 
> On VM lubuntu : ssh  -vvv root@192.168.0.2
> 
> I add trace on dropbear sources and found problem come with function getpwnam 
> to read /etc/password with 
> 
> errno=0;
> pw = getpwnam(username);
> 
> dropbear_log(LOG_WARNING,"LBR %s %d %s",__FILE__ ,__LINE__, strerror(errno));
> if (!pw) {
> return;
> }
> 
> [157] Jan 01 01:06:50 LBR common-session.c 595 No such file or directory

Login attempt for nonexistent user

[Laurent Bourdel]

 
with correct subject :
Hi,

I fail to login with ssh client to dropbox

I use Udoo ARM board with busybox to install ssh server

I cross compiled dropbear under VirtualBox lubuntu and install binary to board 
( /bin & /sbin)

I generate RSA key (ssh-keygen -t rsa ) under lubuntu and copied  content to 
/home/root/.ssh/authorized_keys on Udoo board

I run on Udoo board : dropbear -vFE

On VM lubuntu : ssh  -vvv root@192.168.0.2

I add trace on dropbear sources and found problem come with function getpwnam 
to read /etc/password with 

errno=0;
pw = getpwnam(username);

dropbear_log(LOG_WARNING,"LBR %s %d %s",__FILE__ ,__LINE__, strerror(errno));
if (!pw) {
return;
}


[157] Jan 01 01:06:50 LBR common-session.c 595 No such file or directory

So it seems, there is problem to read /etc/password ?

It well located in correct folder :

~ # ls -l /etc
total 28
drwx--    3 root     user          4096 Oct 29  2018 dropbear
-rwxrwxrwx    1 root     user           192 Oct 28  2018 fstab
-rw-r--r--    1 root     user            23 Oct 29  2018 group
-rw-r--r--    1 root     user            10 Oct 29  2018 group-
drwxrwxrwx    2 root     user          4096 Oct 28  2018 init.d
-rwxrwxrwx    1 root     user           313 Oct 16  2018 inittab
-rw-r--r--    1 root     user            34 Oct 29  2018 passwd


~ # cat /etc/passwd 
root::0:0:root:/home/root:/bin/sh


Below are logs for client & server

If you can help, thx in advance

Laurent
Le mardi 30 octobre 2018 à 10:21:33 UTC+1, Laurent Bourdel 
 a écrit :  
 
 


Hi,

I fail to login with ssh client to dropbox

I use Udoo ARM board with busybox to install ssh server

I cross compiled dropbear under VirtualBox lubuntu and install binary to board 
( /bin & /sbin)

I generate RSA key (ssh-keygen -t rsa ) under lubuntu and copied  content to 
/home/root/.ssh/authorized_keys on Udoo board

I run on Udoo board : dropbear -vFE

On VM lubuntu : ssh  -vvv root@192.168.0.2

I add trace on dropbear sources and found problem come with function getpwnam 
to read /etc/password with 

 errno=0;
 pw = getpwnam(username);
 
 dropbear_log(LOG_WARNING,"LBR %s %d %s",__FILE__ ,__LINE__, strerror(errno));
 if (!pw) {
 return;
 }


[157] Jan 01 01:06:50 LBR common-session.c 595 No such file or directory

So it seems, there is problem to read /etc/password ?

It well located in correct folder :

~ # ls -l /etc
total 28
drwx--    3 root     user          4096 Oct 29  2018 dropbear
-rwxrwxrwx    1 root     user           192 Oct 28  2018 fstab
-rw-r--r--    1 root     user            23 Oct 29  2018 group
-rw-r--r--    1 root     user            10 Oct 29  2018 group-
drwxrwxrwx    2 root     user          4096 Oct 28  2018 init.d
-rwxrwxrwx    1 root     user           313 Oct 16  2018 inittab
-rw-r--r--    1 root     user            34 Oct 29  2018 passwd


~ # cat /etc/passwd 
root::0:0:root:/home/root:/bin/sh


Below are logs for client & server

If you can jelp, thx in advance

Laurent  

Re: Login attempt for nonexistent user on Alpine Linux

[Szabolcs Nagy]

* Hugo Genesse  [2017-12-01 18:57:02 +]:
> 
> -vvv on dropbear doesn't seem to be a valid option:
> 
> 67b4c38f79c6:/usr/lib# /root/dropbear -R -E -vvv
> Invalid option -v
> 
> Is my command correct?
> 

ah -v is only supported if dropbear is built with CFLAGS=-DDEBUG_TRACE

Re: Login attempt for nonexistent user on Alpine Linux

[Hugo Genesse]

-vvv on dropbear doesn't seem to be a valid option:

67b4c38f79c6:/usr/lib# /root/dropbear -R -E -vvv
Invalid option -v

Is my command correct?

Szabolcs Nagy <n...@port70.net> a écrit :


* Hugo Genesse <hugo.gene...@polymtl.ca> [2017-12-01 17:07:25 +]:


First, thanks for your replies. I created another account:

admin:x:100:65533:Linux User,,,:/home/admin:/bin/ash

Here is the output of with -vvv:



you added -vvv on the client side instead of the server where the  
problem is...



debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
admin@127.0.0.1's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
admin@127.0.0.1's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
admin@127.0.0.1's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
admin@127.0.0.1: Permission denied (publickey,password).

and in the dropbear logs I still get:

[67] Dec 01 17:03:47 Child connection from :40878
[67] Dec 01 17:03:47 Login attempt for nonexistent user from
[...]



make it more verbose, you will see what part of the user
lookup fails.


I saw that I could create a configuration file in /etc/dropbear to allow
root logins by it seems to be enabled by default and I would prefer just
drop a binary on the device to enable ssh without changes to the system.
Here is the openwrt page I'm referring:
https://wiki.openwrt.org/doc/uci/dropbear

Thanks!

"Daniel." <danielhi...@gmail.com> a écrit :

> Can you log in with another user? The root login may be disabled by
> security reasons.
>
> 2017-12-01 13:01 GMT-02:00 Szabolcs Nagy <n...@port70.net>:
>
> > * Hugo Genesse <hugo.gene...@polymtl.ca> [2017-12-01 04:51:08 +]:
> > > I've been trying to use dropbear (compiled myself statically with
> > > ./configure; make STATIC=1) on a Alpine Linux Docker container (Linux
> > > 4.13.12-1-ARCH) with the latest Alpine Docker image (3.6 if I'm not
> > > mistaken). I run dropbear like this: "./dropbear -R" and  
can't login with

> > > proper credentials. With the "-E" switch I get the following:
> > >
> > >  /root/dropbear -R -E
> > > [59] Dec 01 04:31:32 Running in background
> > > [60] Dec 01 04:31:36 Child connection from 
> > > [60] Dec 01 04:31:36 Login attempt for nonexistent user from 
> > >
> >
> > i think you can use -vvv to see more detailed debug messages
> >
>
>
>
> --
> “If you're going to try, go all the way. Otherwise, don't even start. ..."
>   Charles Bukowski

Re: Login attempt for nonexistent user on Alpine Linux

[Szabolcs Nagy]

* Matt Johnston  [2017-12-01 16:53:33 +]:
> Statically linking glibc isn't sufficient to make

it's not glibc if it's on alpine linux

Re: Login attempt for nonexistent user on Alpine Linux

[Szabolcs Nagy]

* Hugo Genesse <hugo.gene...@polymtl.ca> [2017-12-01 17:07:25 +]:
> 
> First, thanks for your replies. I created another account:
> 
> admin:x:100:65533:Linux User,,,:/home/admin:/bin/ash
> 
> Here is the output of with -vvv:
> 

you added -vvv on the client side instead of the server where the problem is...

> debug3: authmethod_lookup password
> debug3: remaining preferred: ,password
> debug3: authmethod_is_enabled password
> debug1: Next authentication method: password
> admin@127.0.0.1's password:
> debug3: send packet: type 50
> debug2: we sent a password packet, wait for reply
> debug3: receive packet: type 51
> debug1: Authentications that can continue: publickey,password
> Permission denied, please try again.
> admin@127.0.0.1's password:
> debug3: send packet: type 50
> debug2: we sent a password packet, wait for reply
> debug3: receive packet: type 51
> debug1: Authentications that can continue: publickey,password
> Permission denied, please try again.
> admin@127.0.0.1's password:
> debug3: send packet: type 50
> debug2: we sent a password packet, wait for reply
> debug3: receive packet: type 51
> debug1: Authentications that can continue: publickey,password
> debug2: we did not send a packet, disable method
> debug1: No more authentication methods to try.
> admin@127.0.0.1: Permission denied (publickey,password).
> 
> and in the dropbear logs I still get:
> 
> [67] Dec 01 17:03:47 Child connection from :40878
> [67] Dec 01 17:03:47 Login attempt for nonexistent user from
> [...]
> 

make it more verbose, you will see what part of the user
lookup fails.

> I saw that I could create a configuration file in /etc/dropbear to allow
> root logins by it seems to be enabled by default and I would prefer just
> drop a binary on the device to enable ssh without changes to the system.
> Here is the openwrt page I'm referring:
> https://wiki.openwrt.org/doc/uci/dropbear
> 
> Thanks!
> 
> "Daniel." <danielhi...@gmail.com> a écrit :
> 
> > Can you log in with another user? The root login may be disabled by
> > security reasons.
> > 
> > 2017-12-01 13:01 GMT-02:00 Szabolcs Nagy <n...@port70.net>:
> > 
> > > * Hugo Genesse <hugo.gene...@polymtl.ca> [2017-12-01 04:51:08 +]:
> > > > I've been trying to use dropbear (compiled myself statically with
> > > > ./configure; make STATIC=1) on a Alpine Linux Docker container (Linux
> > > > 4.13.12-1-ARCH) with the latest Alpine Docker image (3.6 if I'm not
> > > > mistaken). I run dropbear like this: "./dropbear -R" and can't login 
> > > > with
> > > > proper credentials. With the "-E" switch I get the following:
> > > >
> > > >  /root/dropbear -R -E
> > > > [59] Dec 01 04:31:32 Running in background
> > > > [60] Dec 01 04:31:36 Child connection from 
> > > > [60] Dec 01 04:31:36 Login attempt for nonexistent user from 
> > > >
> > > 
> > > i think you can use -vvv to see more detailed debug messages
> > > 
> > 
> > 
> > 
> > --
> > “If you're going to try, go all the way. Otherwise, don't even start. ..."
> >   Charles Bukowski
> 
> 

Re: Login attempt for nonexistent user on Alpine Linux

[Hugo Genesse]

Hi!

First, thanks for your replies. I created another account:

admin:x:100:65533:Linux User,,,:/home/admin:/bin/ash

Here is the output of with -vvv:

debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
admin@127.0.0.1's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
admin@127.0.0.1's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
admin@127.0.0.1's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
admin@127.0.0.1: Permission denied (publickey,password).

and in the dropbear logs I still get:

[67] Dec 01 17:03:47 Child connection from :40878
[67] Dec 01 17:03:47 Login attempt for nonexistent user from
[...]

I saw that I could create a configuration file in /etc/dropbear to  
allow root logins by it seems to be enabled by default and I would  
prefer just drop a binary on the device to enable ssh without changes  
to the system. Here is the openwrt page I'm referring:  
https://wiki.openwrt.org/doc/uci/dropbear


Thanks!

"Daniel." <danielhi...@gmail.com> a écrit :


Can you log in with another user? The root login may be disabled by
security reasons.

2017-12-01 13:01 GMT-02:00 Szabolcs Nagy <n...@port70.net>:


* Hugo Genesse <hugo.gene...@polymtl.ca> [2017-12-01 04:51:08 +]:
> I've been trying to use dropbear (compiled myself statically with
> ./configure; make STATIC=1) on a Alpine Linux Docker container (Linux
> 4.13.12-1-ARCH) with the latest Alpine Docker image (3.6 if I'm not
> mistaken). I run dropbear like this: "./dropbear -R" and can't login with
> proper credentials. With the "-E" switch I get the following:
>
>  /root/dropbear -R -E
> [59] Dec 01 04:31:32 Running in background
> [60] Dec 01 04:31:36 Child connection from 
> [60] Dec 01 04:31:36 Login attempt for nonexistent user from 
>

i think you can use -vvv to see more detailed debug messages





--
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski

Re: Login attempt for nonexistent user on Alpine Linux

[Daniel.]

Can you log in with another user? The root login may be disabled by
security reasons.

2017-12-01 13:01 GMT-02:00 Szabolcs Nagy <n...@port70.net>:

> * Hugo Genesse <hugo.gene...@polymtl.ca> [2017-12-01 04:51:08 +]:
> > I've been trying to use dropbear (compiled myself statically with
> > ./configure; make STATIC=1) on a Alpine Linux Docker container (Linux
> > 4.13.12-1-ARCH) with the latest Alpine Docker image (3.6 if I'm not
> > mistaken). I run dropbear like this: "./dropbear -R" and can't login with
> > proper credentials. With the "-E" switch I get the following:
> >
> >  /root/dropbear -R -E
> > [59] Dec 01 04:31:32 Running in background
> > [60] Dec 01 04:31:36 Child connection from 
> > [60] Dec 01 04:31:36 Login attempt for nonexistent user from 
> >
>
> i think you can use -vvv to see more detailed debug messages
>



-- 
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski

Re: Login attempt for nonexistent user on Alpine Linux

[Szabolcs Nagy]

* Hugo Genesse <hugo.gene...@polymtl.ca> [2017-12-01 04:51:08 +]:
> I've been trying to use dropbear (compiled myself statically with
> ./configure; make STATIC=1) on a Alpine Linux Docker container (Linux
> 4.13.12-1-ARCH) with the latest Alpine Docker image (3.6 if I'm not
> mistaken). I run dropbear like this: "./dropbear -R" and can't login with
> proper credentials. With the "-E" switch I get the following:
> 
>  /root/dropbear -R -E
> [59] Dec 01 04:31:32 Running in background
> [60] Dec 01 04:31:36 Child connection from 
> [60] Dec 01 04:31:36 Login attempt for nonexistent user from 
> 

i think you can use -vvv to see more detailed debug messages

Login attempt for nonexistent user on Alpine Linux

[Hugo Genesse]

Hi!

I've been trying to use dropbear (compiled myself statically with  
./configure; make STATIC=1) on a Alpine Linux Docker container (Linux  
4.13.12-1-ARCH) with the latest Alpine Docker image (3.6 if I'm not  
mistaken). I run dropbear like this: "./dropbear -R" and can't login  
with proper credentials. With the "-E" switch I get the following:


 /root/dropbear -R -E
[59] Dec 01 04:31:32 Running in background
[60] Dec 01 04:31:36 Child connection from 
[60] Dec 01 04:31:36 Login attempt for nonexistent user from 

My credentials are right and the command to connect is: "ssh  
root@127.0.0.1" (the port is properly forwarded to the container).  
With the ssh client verbose option I get:


debug1: Next authentication method: password
root@127.0.0.1's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
root@127.0.0.1's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
root@127.0.0.1's password:
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
root@127.0.0.1: Permission denied (publickey,password).

and the root account exists as you can see here:

cat /etc/passwd
root:x:0:0:root:/root:/bin/ash
[...]

I've seen issues that seem similar on the web:  
https://lists.debian.org/debian-arm/2012/06/msg00056.html
The ones I found were fixed by copying libnss to another location but  
shouldn't a statically dropbear already solve this problem?


I also have telnet activated and I can login with root (don't worry  
this won't be put into production, it is for demonstration purposes  
only).


Is there any other things I should check or modify to be able to login  
with dropbear?


Thanks!

RE: Login attempt for nonexistent user

[Warlich, Christof]

 Dropbear starts up fine with dropbear -E. But when I try to log in, dropbear 
 complains:

 Login attempt for nonexistent user from 192.168.211.1:3186
Ok, I found the solution myself. Basically, libnsl is needed as well, in 
addition to libnss.

Just in case anyone else stumbles over the same issue, here is the minimal set 
of
libraries that are needed:


ld-linux.so.2  libc.so.6  libcrypt.so.1  libm.so.6  libnsl.so.1  
libnss_compat.so.2  libutil.so.1  libz.so.1
Cheers,

Chris