[Buildroot] OpenSSH login problem

[Buildroot] OpenSSH login problem

[Michael Fischer]

Dear all,

I have a problem with the OpenSSH login on my raspberry. 
I can't login via ssh, after entering the username, the sever closed the connection.

I have checked it with the commit 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version works with the same configuration.
The actual commit doesn't work but  both commits have the same OpenSSH version.

OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020

My SSHD logofile:

debug2: parse_server_config_depth: config reprocess config len 236
debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days left -18488
debug3: account expiration disabled
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 9
debug2: monitor_read: 8 used once, disabling now
debug2: input_userauth_request: setting up authctxt for root [preauth]
debug3: mm_inform_authserv entering [preauth]
debug3: mm_request_send entering: type 4 [preauth]
debug2: input_userauth_request: try method none [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 4 used once, disabling now
debug3: user_specific_delay: user specific delay 0.000ms [preauth]
debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying 10.089ms (requested 5.154ms) [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive entering
debug1: do_cleanup
debug1: Killing privsep child 390

I don't know what is going wrong.
Console login works and ftp also.

Any help is welcome, I have no more idea where to look.


thanks,
  Michael.

[Buildroot] OpenSSH login problem

[Michael Nosthoff]

Hi Michael,

On Thursday, August 13, 2020 15:35 CEST, Michael Fischer <mf@go-sys.de> wrote: 
 
> Dear all,
> 
> I have a problem with the OpenSSH login on my raspberry. 
> I can't login via ssh, after entering the username, the sever closed the connection.
> 
> I have checked it with the commit 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version works with the same configuration.
> The actual commit doesn't work but  both commits have the same OpenSSH version.
> 
> OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> 
> My SSHD logofile:
> 
> debug2: parse_server_config_depth: config reprocess config len 236
> debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days left -18488
> debug3: account expiration disabled
> debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
> debug3: mm_request_send entering: type 9
> debug2: monitor_read: 8 used once, disabling now
> debug2: input_userauth_request: setting up authctxt for root [preauth]
> debug3: mm_inform_authserv entering [preauth]
> debug3: mm_request_send entering: type 4 [preauth]
> debug2: input_userauth_request: try method none [preauth]
> debug3: mm_request_receive entering
> debug3: monitor_read: checking request 4
> debug3: mm_answer_authserv: service=ssh-connection, style=
> debug2: monitor_read: 4 used once, disabling now
> debug3: user_specific_delay: user specific delay 0.000ms [preauth]
> debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying 10.089ms (requested 5.154ms) [preauth]
> debug1: monitor_read_log: child log fd closed
> debug3: mm_request_receive entering
> debug1: do_cleanup
> debug1: Killing privsep child 390
> 
> I don't know what is going wrong.
> Console login works and ftp also.
> 
> Any help is welcome, I have no more idea where to look.
> 

Could you run the Client with the -v flag? So you could see if actually the client or the server is closing the connection.
A pretty common problem is often a mismatch in available authentication mechanisms (commonly "publickey,password").

Also what sometimes is an issue is the permissions of the users .ssh folder on the server side. 
If it is globally readable sshd in many configurations refuses to authenticate against it.

Regards,
Michael

> 
> thanks,
>   Michael.
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] OpenSSH login problem

[Michael Fischer]

Hi Michael,
 here is the log, the connection is closed from the server.

PS: All settings between the commits are the same. 
The difference between this is only a git pull.


OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to 192.168.1.194 [192.168.1.194] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.3
debug1: match: OpenSSH_8.3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.194:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:RCq6wRn5ZZrwZ7wY84zaMFMdG1mhIorheFPFhbwBz+0
debug1: Host '[192.168.1.194]:22' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa 
debug1: Will attempt key: /root/.ssh/id_dsa 
debug1: Will attempt key: /root/.ssh/id_ecdsa 
debug1: Will attempt key: /root/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /root/.ssh/id_ed25519 
debug1: Will attempt key: /root/.ssh/id_ed25519_sk 
debug1: Will attempt key: /root/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519 at openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
Connection closed by 192.168.1.194 port 22

Regards,
  Michael.


> On Thursday, August 13, 2020 16:35 CEST, Michael Nosthoff <buildroot@heine.tech>
> wrote:
> 
> Hi Michael,
> 
> On Thursday, August 13, 2020 15:35 CEST, Michael Fischer <mf@go-sys.de>
> wrote:
> 
> > Dear all,
> >
> > I have a problem with the OpenSSH login on my raspberry.
> > I can't login via ssh, after entering the username, the sever closed the
> connection.
> >
> > I have checked it with the commit
> 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version works with
> the same configuration.
> > The actual commit doesn't work but  both commits have the same OpenSSH
> version.
> >
> > OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> >
> > My SSHD logofile:
> >
> > debug2: parse_server_config_depth: config reprocess config len 236
> > debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days left -
> 18488
> > debug3: account expiration disabled
> > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
> > debug3: mm_request_send entering: type 9
> > debug2: monitor_read: 8 used once, disabling now
> > debug2: input_userauth_request: setting up authctxt for root [preauth]
> > debug3: mm_inform_authserv entering [preauth]
> > debug3: mm_request_send entering: type 4 [preauth]
> > debug2: input_userauth_request: try method none [preauth]
> > debug3: mm_request_receive entering
> > debug3: monitor_read: checking request 4
> > debug3: mm_answer_authserv: service=ssh-connection, style=
> > debug2: monitor_read: 4 used once, disabling now
> > debug3: user_specific_delay: user specific delay 0.000ms [preauth]
> > debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying
> 10.089ms (requested 5.154ms) [preauth]
> > debug1: monitor_read_log: child log fd closed
> > debug3: mm_request_receive entering
> > debug1: do_cleanup
> > debug1: Killing privsep child 390
> >
> > I don't know what is going wrong.
> > Console login works and ftp also.
> >
> > Any help is welcome, I have no more idea where to look.
> >
> 
> Could you run the Client with the -v flag? So you could see if actually the client
> or the server is closing the connection.
> A pretty common problem is often a mismatch in available authentication
> mechanisms (commonly "publickey,password").
> 
> Also what sometimes is an issue is the permissions of the users .ssh folder on
> the server side.
> If it is globally readable sshd in many configurations refuses to authenticate
> against it.
> 
> Regards,
> Michael
> 
> >
> > thanks,
> >   Michael.
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 
> 

[Buildroot] OpenSSH login problem

[Michael Nosthoff]

Hi,

I try to rephrase what you did to see if I understood it correctly:

You built a Raspberry Pi BR Image based on commit 01632805ab4be2bea4010ba1e46ab71f52d175a9
from the Buildroot git. OpenSSH works.
Then you did a git pull, did a "make clean && make" and with the resulting image you can't login via ssh.

Is this correct?

This assumed I tried the following:

git log --oneline  01632805ab4be2bea4010ba1e46ab71f52d175a9..origin/master
(origin/master is currently at d1d89d37c02e3d8224fb6f812e87fef5612a771a)

From the result I can tell that the OpenSSH package hasn't changed. So it has to be some lib
or something in the Filesystem.

One commit that looks like it could be the troublemaker is: 

060599fc23 package/rpi-userland: bump version to 188d3bf

But else this might be a good idea to try to debug using git bisect and move through the tree to see
when it breaks.

I don't really have a Pi at hand right now. But to reproduce someone would need a minimal BR configuration
which shows the issue. Can you provide that?

Regards,
Michael

 
On Thursday, August 13, 2020 16:51 CEST, Michael Fischer <mf@go-sys.de> wrote: 
 
> Hi Michael,
>  here is the log, the connection is closed from the server.
> 
> PS: All settings between the commits are the same. 
> The difference between this is only a git pull.
> 
> 
> OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 20: Applying options for *
> debug1: Connecting to 192.168.1.194 [192.168.1.194] port 22.
> debug1: Connection established.
> debug1: identity file /root/.ssh/id_rsa type -1
> debug1: identity file /root/.ssh/id_rsa-cert type -1
> debug1: identity file /root/.ssh/id_dsa type -1
> debug1: identity file /root/.ssh/id_dsa-cert type -1
> debug1: identity file /root/.ssh/id_ecdsa type -1
> debug1: identity file /root/.ssh/id_ecdsa-cert type -1
> debug1: identity file /root/.ssh/id_ecdsa_sk type -1
> debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
> debug1: identity file /root/.ssh/id_ed25519 type -1
> debug1: identity file /root/.ssh/id_ed25519-cert type -1
> debug1: identity file /root/.ssh/id_ed25519_sk type -1
> debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
> debug1: identity file /root/.ssh/id_xmss type -1
> debug1: identity file /root/.ssh/id_xmss-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_8.3
> debug1: Remote protocol version 2.0, remote software version OpenSSH_8.3
> debug1: match: OpenSSH_8.3 pat OpenSSH* compat 0x04000000
> debug1: Authenticating to 192.168.1.194:22 as 'root'
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha256
> debug1: kex: host key algorithm: ecdsa-sha2-nistp256
> debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
> debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
> debug1: kex: curve25519-sha256 need=64 dh_need=64
> debug1: kex: curve25519-sha256 need=64 dh_need=64
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ecdsa-sha2-nistp256 SHA256:RCq6wRn5ZZrwZ7wY84zaMFMdG1mhIorheFPFhbwBz+0
> debug1: Host '[192.168.1.194]:22' is known and matches the ECDSA host key.
> debug1: Found key in /root/.ssh/known_hosts:1
> debug1: rekey out after 134217728 blocks
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: rekey in after 134217728 blocks
> debug1: Will attempt key: /root/.ssh/id_rsa 
> debug1: Will attempt key: /root/.ssh/id_dsa 
> debug1: Will attempt key: /root/.ssh/id_ecdsa 
> debug1: Will attempt key: /root/.ssh/id_ecdsa_sk 
> debug1: Will attempt key: /root/.ssh/id_ed25519 
> debug1: Will attempt key: /root/.ssh/id_ed25519_sk 
> debug1: Will attempt key: /root/.ssh/id_xmss 
> debug1: SSH2_MSG_EXT_INFO received
> debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519 at openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> Connection closed by 192.168.1.194 port 22
> 
> Regards,
>   Michael.
> 
> 
> > On Thursday, August 13, 2020 16:35 CEST, Michael Nosthoff <buildroot@heine.tech>
> > wrote:
> > 
> > Hi Michael,
> > 
> > On Thursday, August 13, 2020 15:35 CEST, Michael Fischer <mf@go-sys.de>
> > wrote:
> > 
> > > Dear all,
> > >
> > > I have a problem with the OpenSSH login on my raspberry.
> > > I can't login via ssh, after entering the username, the sever closed the
> > connection.
> > >
> > > I have checked it with the commit
> > 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version works with
> > the same configuration.
> > > The actual commit doesn't work but  both commits have the same OpenSSH
> > version.
> > >
> > > OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > >
> > > My SSHD logofile:
> > >
> > > debug2: parse_server_config_depth: config reprocess config len 236
> > > debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days left -
> > 18488
> > > debug3: account expiration disabled
> > > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
> > > debug3: mm_request_send entering: type 9
> > > debug2: monitor_read: 8 used once, disabling now
> > > debug2: input_userauth_request: setting up authctxt for root [preauth]
> > > debug3: mm_inform_authserv entering [preauth]
> > > debug3: mm_request_send entering: type 4 [preauth]
> > > debug2: input_userauth_request: try method none [preauth]
> > > debug3: mm_request_receive entering
> > > debug3: monitor_read: checking request 4
> > > debug3: mm_answer_authserv: service=ssh-connection, style=
> > > debug2: monitor_read: 4 used once, disabling now
> > > debug3: user_specific_delay: user specific delay 0.000ms [preauth]
> > > debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying
> > 10.089ms (requested 5.154ms) [preauth]
> > > debug1: monitor_read_log: child log fd closed
> > > debug3: mm_request_receive entering
> > > debug1: do_cleanup
> > > debug1: Killing privsep child 390
> > >
> > > I don't know what is going wrong.
> > > Console login works and ftp also.
> > >
> > > Any help is welcome, I have no more idea where to look.
> > >
> > 
> > Could you run the Client with the -v flag? So you could see if actually the client
> > or the server is closing the connection.
> > A pretty common problem is often a mismatch in available authentication
> > mechanisms (commonly "publickey,password").
> > 
> > Also what sometimes is an issue is the permissions of the users .ssh folder on
> > the server side.
> > If it is globally readable sshd in many configurations refuses to authenticate
> > against it.
> > 
> > Regards,
> > Michael
> > 
> > >
> > > thanks,
> > >   Michael.
> > >
> > > _______________________________________________
> > > buildroot mailing list
> > > buildroot at busybox.net
> > > http://lists.busybox.net/mailman/listinfo/buildroot
> > 
> > 
> > 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] OpenSSH login problem

[Michael Fischer]

Hi Michael,

yes this is correct.

Regards,
  Michael.

> 
> Hi,
> 
> I try to rephrase what you did to see if I understood it correctly:
> 
> You built a Raspberry Pi BR Image based on commit
> 01632805ab4be2bea4010ba1e46ab71f52d175a9
> from the Buildroot git. OpenSSH works.
> Then you did a git pull, did a "make clean && make" and with the resulting
> image you can't login via ssh.
> 
> Is this correct?
> 
> This assumed I tried the following:
> 
> git log --oneline
> 01632805ab4be2bea4010ba1e46ab71f52d175a9..origin/master
> (origin/master is currently at
> d1d89d37c02e3d8224fb6f812e87fef5612a771a)
> 
> From the result I can tell that the OpenSSH package hasn't changed. So it has
> to be some lib or something in the Filesystem.
> 
> One commit that looks like it could be the troublemaker is:
> 
> 060599fc23 package/rpi-userland: bump version to 188d3bf
> 
> But else this might be a good idea to try to debug using git bisect and move
> through the tree to see when it breaks.
> 
> I don't really have a Pi at hand right now. But to reproduce someone would
> need a minimal BR configuration which shows the issue. Can you provide that?
> 
> Regards,
> Michael
> 
> 
> On Thursday, August 13, 2020 16:51 CEST, Michael Fischer <mf@go-sys.de>
> wrote:
> 
> > Hi Michael,
> >  here is the log, the connection is closed from the server.
> >
> > PS: All settings between the commits are the same.
> > The difference between this is only a git pull.
> >
> >
> > OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: /etc/ssh/ssh_config line 20: Applying options for *
> > debug1: Connecting to 192.168.1.194 [192.168.1.194] port 22.
> > debug1: Connection established.
> > debug1: identity file /root/.ssh/id_rsa type -1
> > debug1: identity file /root/.ssh/id_rsa-cert type -1
> > debug1: identity file /root/.ssh/id_dsa type -1
> > debug1: identity file /root/.ssh/id_dsa-cert type -1
> > debug1: identity file /root/.ssh/id_ecdsa type -1
> > debug1: identity file /root/.ssh/id_ecdsa-cert type -1
> > debug1: identity file /root/.ssh/id_ecdsa_sk type -1
> > debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
> > debug1: identity file /root/.ssh/id_ed25519 type -1
> > debug1: identity file /root/.ssh/id_ed25519-cert type -1
> > debug1: identity file /root/.ssh/id_ed25519_sk type -1
> > debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
> > debug1: identity file /root/.ssh/id_xmss type -1
> > debug1: identity file /root/.ssh/id_xmss-cert type -1
> > debug1: Local version string SSH-2.0-OpenSSH_8.3
> > debug1: Remote protocol version 2.0, remote software version
> > OpenSSH_8.3
> > debug1: match: OpenSSH_8.3 pat OpenSSH* compat 0x04000000
> > debug1: Authenticating to 192.168.1.194:22 as 'root'
> > debug1: SSH2_MSG_KEXINIT sent
> > debug1: SSH2_MSG_KEXINIT received
> > debug1: kex: algorithm: curve25519-sha256
> > debug1: kex: host key algorithm: ecdsa-sha2-nistp256
> > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com
> MAC:
> > <implicit> compression: none
> > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com
> MAC:
> > <implicit> compression: none
> > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> > debug1: Server host key: ecdsa-sha2-nistp256
> > SHA256:RCq6wRn5ZZrwZ7wY84zaMFMdG1mhIorheFPFhbwBz+0
> > debug1: Host '[192.168.1.194]:22' is known and matches the ECDSA host
> key.
> > debug1: Found key in /root/.ssh/known_hosts:1
> > debug1: rekey out after 134217728 blocks
> > debug1: SSH2_MSG_NEWKEYS sent
> > debug1: expecting SSH2_MSG_NEWKEYS
> > debug1: SSH2_MSG_NEWKEYS received
> > debug1: rekey in after 134217728 blocks
> > debug1: Will attempt key: /root/.ssh/id_rsa
> > debug1: Will attempt key: /root/.ssh/id_dsa
> > debug1: Will attempt key: /root/.ssh/id_ecdsa
> > debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
> > debug1: Will attempt key: /root/.ssh/id_ed25519
> > debug1: Will attempt key: /root/.ssh/id_ed25519_sk
> > debug1: Will attempt key: /root/.ssh/id_xmss
> > debug1: SSH2_MSG_EXT_INFO received
> > debug1: kex_input_ext_info:
> > server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sh
> > a2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ec
> > dsa-sha2-nistp521,sk-ecdsa-sha2-nistp256 at openssh.com>
> > debug1: SSH2_MSG_SERVICE_ACCEPT received Connection closed by
> > 192.168.1.194 port 22
> >
> > Regards,
> >   Michael.
> >
> >
> > > On Thursday, August 13, 2020 16:35 CEST, Michael Nosthoff
> > > <buildroot@heine.tech>
> > > wrote:
> > >
> > > Hi Michael,
> > >
> > > On Thursday, August 13, 2020 15:35 CEST, Michael Fischer
> > > <mf@go-sys.de>
> > > wrote:
> > >
> > > > Dear all,
> > > >
> > > > I have a problem with the OpenSSH login on my raspberry.
> > > > I can't login via ssh, after entering the username, the sever
> > > > closed the
> > > connection.
> > > >
> > > > I have checked it with the commit
> > > 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version works
> with
> > > the same configuration.
> > > > The actual commit doesn't work but  both commits have the same
> > > > OpenSSH
> > > version.
> > > >
> > > > OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > > >
> > > > My SSHD logofile:
> > > >
> > > > debug2: parse_server_config_depth: config reprocess config len 236
> > > > debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days
> > > > left -
> > > 18488
> > > > debug3: account expiration disabled
> > > > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
> > > > debug3: mm_request_send entering: type 9
> > > > debug2: monitor_read: 8 used once, disabling now
> > > > debug2: input_userauth_request: setting up authctxt for root
> > > > [preauth]
> > > > debug3: mm_inform_authserv entering [preauth]
> > > > debug3: mm_request_send entering: type 4 [preauth]
> > > > debug2: input_userauth_request: try method none [preauth]
> > > > debug3: mm_request_receive entering
> > > > debug3: monitor_read: checking request 4
> > > > debug3: mm_answer_authserv: service=ssh-connection, style=
> > > > debug2: monitor_read: 4 used once, disabling now
> > > > debug3: user_specific_delay: user specific delay 0.000ms [preauth]
> > > > debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying
> > > 10.089ms (requested 5.154ms) [preauth]
> > > > debug1: monitor_read_log: child log fd closed
> > > > debug3: mm_request_receive entering
> > > > debug1: do_cleanup
> > > > debug1: Killing privsep child 390
> > > >
> > > > I don't know what is going wrong.
> > > > Console login works and ftp also.
> > > >
> > > > Any help is welcome, I have no more idea where to look.
> > > >
> > >
> > > Could you run the Client with the -v flag? So you could see if
> > > actually the client or the server is closing the connection.
> > > A pretty common problem is often a mismatch in available
> > > authentication mechanisms (commonly "publickey,password").
> > >
> > > Also what sometimes is an issue is the permissions of the users .ssh
> > > folder on the server side.
> > > If it is globally readable sshd in many configurations refuses to
> > > authenticate against it.
> > >
> > > Regards,
> > > Michael
> > >
> > > >
> > > > thanks,
> > > >   Michael.
> > > >
> > > > _______________________________________________
> > > > buildroot mailing list
> > > > buildroot at busybox.net
> > > > http://lists.busybox.net/mailman/listinfo/buildroot
> > >
> > >
> > >
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 
> 

[Buildroot] OpenSSH login problem

[Michael Fischer]

Hi 
  Michael

it seems to be a glibc bug.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965932

https://salsa.debian.org/glibc-team/glibc/-/commit/b1488bfda31968a724afa3ba212001a807603efd


Regards,
  Michael

> 
> Hi,
> 
> I try to rephrase what you did to see if I understood it correctly:
> 
> You built a Raspberry Pi BR Image based on commit
> 01632805ab4be2bea4010ba1e46ab71f52d175a9
> from the Buildroot git. OpenSSH works.
> Then you did a git pull, did a "make clean && make" and with the resulting
> image you can't login via ssh.
> 
> Is this correct?
> 
> This assumed I tried the following:
> 
> git log --oneline
> 01632805ab4be2bea4010ba1e46ab71f52d175a9..origin/master
> (origin/master is currently at
> d1d89d37c02e3d8224fb6f812e87fef5612a771a)
> 
> From the result I can tell that the OpenSSH package hasn't changed. So it has
> to be some lib or something in the Filesystem.
> 
> One commit that looks like it could be the troublemaker is:
> 
> 060599fc23 package/rpi-userland: bump version to 188d3bf
> 
> But else this might be a good idea to try to debug using git bisect and move
> through the tree to see when it breaks.
> 
> I don't really have a Pi at hand right now. But to reproduce someone would
> need a minimal BR configuration which shows the issue. Can you provide that?
> 
> Regards,
> Michael
> 
> 
> On Thursday, August 13, 2020 16:51 CEST, Michael Fischer <mf@go-sys.de>
> wrote:
> 
> > Hi Michael,
> >  here is the log, the connection is closed from the server.
> >
> > PS: All settings between the commits are the same.
> > The difference between this is only a git pull.
> >
> >
> > OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: /etc/ssh/ssh_config line 20: Applying options for *
> > debug1: Connecting to 192.168.1.194 [192.168.1.194] port 22.
> > debug1: Connection established.
> > debug1: identity file /root/.ssh/id_rsa type -1
> > debug1: identity file /root/.ssh/id_rsa-cert type -1
> > debug1: identity file /root/.ssh/id_dsa type -1
> > debug1: identity file /root/.ssh/id_dsa-cert type -1
> > debug1: identity file /root/.ssh/id_ecdsa type -1
> > debug1: identity file /root/.ssh/id_ecdsa-cert type -1
> > debug1: identity file /root/.ssh/id_ecdsa_sk type -1
> > debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
> > debug1: identity file /root/.ssh/id_ed25519 type -1
> > debug1: identity file /root/.ssh/id_ed25519-cert type -1
> > debug1: identity file /root/.ssh/id_ed25519_sk type -1
> > debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
> > debug1: identity file /root/.ssh/id_xmss type -1
> > debug1: identity file /root/.ssh/id_xmss-cert type -1
> > debug1: Local version string SSH-2.0-OpenSSH_8.3
> > debug1: Remote protocol version 2.0, remote software version
> > OpenSSH_8.3
> > debug1: match: OpenSSH_8.3 pat OpenSSH* compat 0x04000000
> > debug1: Authenticating to 192.168.1.194:22 as 'root'
> > debug1: SSH2_MSG_KEXINIT sent
> > debug1: SSH2_MSG_KEXINIT received
> > debug1: kex: algorithm: curve25519-sha256
> > debug1: kex: host key algorithm: ecdsa-sha2-nistp256
> > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com
> MAC:
> > <implicit> compression: none
> > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com
> MAC:
> > <implicit> compression: none
> > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> > debug1: Server host key: ecdsa-sha2-nistp256
> > SHA256:RCq6wRn5ZZrwZ7wY84zaMFMdG1mhIorheFPFhbwBz+0
> > debug1: Host '[192.168.1.194]:22' is known and matches the ECDSA host
> key.
> > debug1: Found key in /root/.ssh/known_hosts:1
> > debug1: rekey out after 134217728 blocks
> > debug1: SSH2_MSG_NEWKEYS sent
> > debug1: expecting SSH2_MSG_NEWKEYS
> > debug1: SSH2_MSG_NEWKEYS received
> > debug1: rekey in after 134217728 blocks
> > debug1: Will attempt key: /root/.ssh/id_rsa
> > debug1: Will attempt key: /root/.ssh/id_dsa
> > debug1: Will attempt key: /root/.ssh/id_ecdsa
> > debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
> > debug1: Will attempt key: /root/.ssh/id_ed25519
> > debug1: Will attempt key: /root/.ssh/id_ed25519_sk
> > debug1: Will attempt key: /root/.ssh/id_xmss
> > debug1: SSH2_MSG_EXT_INFO received
> > debug1: kex_input_ext_info:
> > server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sh
> > a2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ec
> > dsa-sha2-nistp521,sk-ecdsa-sha2-nistp256 at openssh.com>
> > debug1: SSH2_MSG_SERVICE_ACCEPT received Connection closed by
> > 192.168.1.194 port 22
> >
> > Regards,
> >   Michael.
> >
> >
> > > On Thursday, August 13, 2020 16:35 CEST, Michael Nosthoff
> > > <buildroot@heine.tech>
> > > wrote:
> > >
> > > Hi Michael,
> > >
> > > On Thursday, August 13, 2020 15:35 CEST, Michael Fischer
> > > <mf@go-sys.de>
> > > wrote:
> > >
> > > > Dear all,
> > > >
> > > > I have a problem with the OpenSSH login on my raspberry.
> > > > I can't login via ssh, after entering the username, the sever
> > > > closed the
> > > connection.
> > > >
> > > > I have checked it with the commit
> > > 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version works
> with
> > > the same configuration.
> > > > The actual commit doesn't work but  both commits have the same
> > > > OpenSSH
> > > version.
> > > >
> > > > OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > > >
> > > > My SSHD logofile:
> > > >
> > > > debug2: parse_server_config_depth: config reprocess config len 236
> > > > debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days
> > > > left -
> > > 18488
> > > > debug3: account expiration disabled
> > > > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
> > > > debug3: mm_request_send entering: type 9
> > > > debug2: monitor_read: 8 used once, disabling now
> > > > debug2: input_userauth_request: setting up authctxt for root
> > > > [preauth]
> > > > debug3: mm_inform_authserv entering [preauth]
> > > > debug3: mm_request_send entering: type 4 [preauth]
> > > > debug2: input_userauth_request: try method none [preauth]
> > > > debug3: mm_request_receive entering
> > > > debug3: monitor_read: checking request 4
> > > > debug3: mm_answer_authserv: service=ssh-connection, style=
> > > > debug2: monitor_read: 4 used once, disabling now
> > > > debug3: user_specific_delay: user specific delay 0.000ms [preauth]
> > > > debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying
> > > 10.089ms (requested 5.154ms) [preauth]
> > > > debug1: monitor_read_log: child log fd closed
> > > > debug3: mm_request_receive entering
> > > > debug1: do_cleanup
> > > > debug1: Killing privsep child 390
> > > >
> > > > I don't know what is going wrong.
> > > > Console login works and ftp also.
> > > >
> > > > Any help is welcome, I have no more idea where to look.
> > > >
> > >
> > > Could you run the Client with the -v flag? So you could see if
> > > actually the client or the server is closing the connection.
> > > A pretty common problem is often a mismatch in available
> > > authentication mechanisms (commonly "publickey,password").
> > >
> > > Also what sometimes is an issue is the permissions of the users .ssh
> > > folder on the server side.
> > > If it is globally readable sshd in many configurations refuses to
> > > authenticate against it.
> > >
> > > Regards,
> > > Michael
> > >
> > > >
> > > > thanks,
> > > >   Michael.
> > > >
> > > > _______________________________________________
> > > > buildroot mailing list
> > > > buildroot at busybox.net
> > > > http://lists.busybox.net/mailman/listinfo/buildroot
> > >
> > >
> > >
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 
> 

[Buildroot] OpenSSH login problem

[Michael Nosthoff]

Hi,


On 14.08.20 15:22, Michael Fischer wrote:
> Hi
>    Michael
>
> it seems to be a glibc bug.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965932


So it seems this was triggered by

9f6d4c3a87ccb package/{glibc, localedef}: bump to version 2.31


This commit is already referencing issues with openssh. But those should 
be fixed by commit

bad75bca315d package/openssh: bump to version 8.2p1


this commit also contains links to archlinux and gentoo which describe 
similar problems as

the debian issue.

>
> https://salsa.debian.org/glibc-team/glibc/-/commit/b1488bfda31968a724afa3ba212001a807603efd


Since the OpenSSH Version was already bumped again to 8.3p1 this is 
pretty weird.


Did you do a clean build?


Regards,

Michael

>
> Regards,
>    Michael
>
>

[Buildroot] OpenSSH login problem

[Christian Stewart]

Hi all,

On Fri, Aug 14, 2020 at 6:23 AM Michael Fischer <mf@go-sys.de> wrote:
>
> Hi
>   Michael
>
> it seems to be a glibc bug.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965932
>
> https://salsa.debian.org/glibc-team/glibc/-/commit/b1488bfda31968a724afa3ba212001a807603efd

FWIW I actually had the same, was trying to test an odroid XU4 and the
SSH server was immediately closing the connection. I double-checked
that openssh was at the latest version & I was on the latest buildroot
master as well, and assumed at the time it must have had something to
do with the kernel bump I was testing.

Now I'm thinking maybe this was causing it. Will test again later today.

Best,
Christian

[Buildroot] OpenSSH login problem

[Thomas Petazzoni]

On Sun, 16 Aug 2020 12:59:02 -0700
Christian Stewart <christian@paral.in> wrote:

> FWIW I actually had the same, was trying to test an odroid XU4 and the
> SSH server was immediately closing the connection. I double-checked
> that openssh was at the latest version & I was on the latest buildroot
> master as well, and assumed at the time it must have had something to
> do with the kernel bump I was testing.
> 
> Now I'm thinking maybe this was causing it. Will test again later today.

Could you try applying:

 https://github.com/openssh/openssh-portable/commit/beee0ef61866cb567b9abc23bd850f922e59e3f0
 https://github.com/openssh/openssh-portable/commit/69298ebfc2c066acee5d187eac8ce9f38c796630

and see if it helps ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] OpenSSH login problem

[Peter Seiderer]

Hello Michael (Fischer),

On Thu, 13 Aug 2020 17:54:31 +0200, Michael Nosthoff via buildroot <buildroot@busybox.net> wrote:

> Hi,
>
> I try to rephrase what you did to see if I understood it correctly:
>
> You built a Raspberry Pi BR Image based on commit 01632805ab4be2bea4010ba1e46ab71f52d175a9
> from the Buildroot git. OpenSSH works.
> Then you did a git pull, did a "make clean && make" and with the resulting image you can't login via ssh.
>
> Is this correct?
>
> This assumed I tried the following:
>
> git log --oneline  01632805ab4be2bea4010ba1e46ab71f52d175a9..origin/master
> (origin/master is currently at d1d89d37c02e3d8224fb6f812e87fef5612a771a)
>
> From the result I can tell that the OpenSSH package hasn't changed. So it has to be some lib
> or something in the Filesystem.
>
> One commit that looks like it could be the troublemaker is:
>
> 060599fc23 package/rpi-userland: bump version to 188d3bf
>
> But else this might be a good idea to try to debug using git bisect and move through the tree to see
> when it breaks.
>
> I don't really have a Pi at hand right now. But to reproduce someone would need a minimal BR configuration
> which shows the issue. Can you provide that?

Could not reproduce the problem on RPi3 Model B+ with the following defconfig
(with buildroot-master up to commit d1c3f077e24a41f004945f94aceb6f059c58e423):

BR2_arm=y
BR2_cortex_a53=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_SYSTEM_DHCP="eth0"
BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi3/post-build.sh"
BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi3/post-image.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="--add-miniuart-bt-overlay"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,1c64f4bc22811d2d371b271daa3fb27895a8abdd)/linux-1c64f4bc22811d2d371b271daa3fb27895a8abdd.tar.gz"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2710-rpi-3-b bcm2710-rpi-3-b-plus bcm2710-rpi-cm3"
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_RPI_FIRMWARE=y
BR2_PACKAGE_OPENSSH=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
# BR2_TARGET_ROOTFS_TAR is not set
BR2_PACKAGE_HOST_DOSFSTOOLS=y
BR2_PACKAGE_HOST_GENIMAGE=y
BR2_PACKAGE_HOST_MTOOLS=y


Mind to share your .config/defconfig file? Which (exact) hardware do you use?

Regards,
Peter


>
> Regards,
> Michael
>
>
> On Thursday, August 13, 2020 16:51 CEST, Michael Fischer <mf@go-sys.de> wrote:
>
> > Hi Michael,
> >  here is the log, the connection is closed from the server.
> >
> > PS: All settings between the commits are the same.
> > The difference between this is only a git pull.
> >
> >
> > OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: /etc/ssh/ssh_config line 20: Applying options for *
> > debug1: Connecting to 192.168.1.194 [192.168.1.194] port 22.
> > debug1: Connection established.
> > debug1: identity file /root/.ssh/id_rsa type -1
> > debug1: identity file /root/.ssh/id_rsa-cert type -1
> > debug1: identity file /root/.ssh/id_dsa type -1
> > debug1: identity file /root/.ssh/id_dsa-cert type -1
> > debug1: identity file /root/.ssh/id_ecdsa type -1
> > debug1: identity file /root/.ssh/id_ecdsa-cert type -1
> > debug1: identity file /root/.ssh/id_ecdsa_sk type -1
> > debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
> > debug1: identity file /root/.ssh/id_ed25519 type -1
> > debug1: identity file /root/.ssh/id_ed25519-cert type -1
> > debug1: identity file /root/.ssh/id_ed25519_sk type -1
> > debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
> > debug1: identity file /root/.ssh/id_xmss type -1
> > debug1: identity file /root/.ssh/id_xmss-cert type -1
> > debug1: Local version string SSH-2.0-OpenSSH_8.3
> > debug1: Remote protocol version 2.0, remote software version OpenSSH_8.3
> > debug1: match: OpenSSH_8.3 pat OpenSSH* compat 0x04000000
> > debug1: Authenticating to 192.168.1.194:22 as 'root'
> > debug1: SSH2_MSG_KEXINIT sent
> > debug1: SSH2_MSG_KEXINIT received
> > debug1: kex: algorithm: curve25519-sha256
> > debug1: kex: host key algorithm: ecdsa-sha2-nistp256
> > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
> > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
> > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> > debug1: Server host key: ecdsa-sha2-nistp256 SHA256:RCq6wRn5ZZrwZ7wY84zaMFMdG1mhIorheFPFhbwBz+0
> > debug1: Host '[192.168.1.194]:22' is known and matches the ECDSA host key.
> > debug1: Found key in /root/.ssh/known_hosts:1
> > debug1: rekey out after 134217728 blocks
> > debug1: SSH2_MSG_NEWKEYS sent
> > debug1: expecting SSH2_MSG_NEWKEYS
> > debug1: SSH2_MSG_NEWKEYS received
> > debug1: rekey in after 134217728 blocks
> > debug1: Will attempt key: /root/.ssh/id_rsa
> > debug1: Will attempt key: /root/.ssh/id_dsa
> > debug1: Will attempt key: /root/.ssh/id_ecdsa
> > debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
> > debug1: Will attempt key: /root/.ssh/id_ed25519
> > debug1: Will attempt key: /root/.ssh/id_ed25519_sk
> > debug1: Will attempt key: /root/.ssh/id_xmss
> > debug1: SSH2_MSG_EXT_INFO received
> > debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519 at openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
> > debug1: SSH2_MSG_SERVICE_ACCEPT received
> > Connection closed by 192.168.1.194 port 22
> >
> > Regards,
> >   Michael.
> >
> >
> > > On Thursday, August 13, 2020 16:35 CEST, Michael Nosthoff <buildroot@heine.tech>
> > > wrote:
> > >
> > > Hi Michael,
> > >
> > > On Thursday, August 13, 2020 15:35 CEST, Michael Fischer <mf@go-sys.de>
> > > wrote:
> > >
> > > > Dear all,
> > > >
> > > > I have a problem with the OpenSSH login on my raspberry.
> > > > I can't login via ssh, after entering the username, the sever closed the
> > > connection.
> > > >
> > > > I have checked it with the commit
> > > 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version works with
> > > the same configuration.
> > > > The actual commit doesn't work but  both commits have the same OpenSSH
> > > version.
> > > >
> > > > OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > > >
> > > > My SSHD logofile:
> > > >
> > > > debug2: parse_server_config_depth: config reprocess config len 236
> > > > debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days left -
> > > 18488
> > > > debug3: account expiration disabled
> > > > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
> > > > debug3: mm_request_send entering: type 9
> > > > debug2: monitor_read: 8 used once, disabling now
> > > > debug2: input_userauth_request: setting up authctxt for root [preauth]
> > > > debug3: mm_inform_authserv entering [preauth]
> > > > debug3: mm_request_send entering: type 4 [preauth]
> > > > debug2: input_userauth_request: try method none [preauth]
> > > > debug3: mm_request_receive entering
> > > > debug3: monitor_read: checking request 4
> > > > debug3: mm_answer_authserv: service=ssh-connection, style=
> > > > debug2: monitor_read: 4 used once, disabling now
> > > > debug3: user_specific_delay: user specific delay 0.000ms [preauth]
> > > > debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying
> > > 10.089ms (requested 5.154ms) [preauth]
> > > > debug1: monitor_read_log: child log fd closed
> > > > debug3: mm_request_receive entering
> > > > debug1: do_cleanup
> > > > debug1: Killing privsep child 390
> > > >
> > > > I don't know what is going wrong.
> > > > Console login works and ftp also.
> > > >
> > > > Any help is welcome, I have no more idea where to look.
> > > >
> > >
> > > Could you run the Client with the -v flag? So you could see if actually the client
> > > or the server is closing the connection.
> > > A pretty common problem is often a mismatch in available authentication
> > > mechanisms (commonly "publickey,password").
> > >
> > > Also what sometimes is an issue is the permissions of the users .ssh folder on
> > > the server side.
> > > If it is globally readable sshd in many configurations refuses to authenticate
> > > against it.
> > >
> > > Regards,
> > > Michael
> > >
> > > >
> > > > thanks,
> > > >   Michael.
> > > >
> > > > _______________________________________________
> > > > buildroot mailing list
> > > > buildroot at busybox.net
> > > > http://lists.busybox.net/mailman/listinfo/buildroot
> > >
> > >
> > >
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] OpenSSH login problem

[Christian Stewart]

Hi Thomas, all,

On Sun, Aug 16, 2020 at 1:06 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> On Sun, 16 Aug 2020 12:59:02 -0700
> Christian Stewart <christian@paral.in> wrote:
>
> > FWIW I actually had the same, was trying to test an odroid XU4 and the
> > SSH server was immediately closing the connection. I double-checked
> > that openssh was at the latest version & I was on the latest buildroot
> > master as well, and assumed at the time it must have had something to
> > do with the kernel bump I was testing.
> >
> > Now I'm thinking maybe this was causing it. Will test again later today.
>
> Could you try applying:
>
>  https://github.com/openssh/openssh-portable/commit/beee0ef61866cb567b9abc23bd850f922e59e3f0
>  https://github.com/openssh/openssh-portable/commit/69298ebfc2c066acee5d187eac8ce9f38c796630
>
> and see if it helps ?

Tests run against buildroot master - at commit hash:

1396b06a1ee9a86055488de593be93ae2585ceb1

== Test 1: pi3 w/ gcc 10 glibc binutils 2.34

PASS - defconfig:

BR2_arm=y
BR2_cortex_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y
BR2_BINUTILS_VERSION_2_34_X=y
BR2_GCC_VERSION_10_X=y

openssh works as expected.

== Test 2: odroid xu4 with gcc 9, binutils 2.33.1

have not had a chance to test yet but this was the one that didn't work before.

BR2_arm=y
BR2_cortex_a15_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y


best regards,
Christian

[Buildroot] OpenSSH login problem

[Romain Naour]

Hello All,

Le 17/08/2020 ? 23:36, Christian Stewart a ?crit?:
> Hi Thomas, all,
> 
> On Sun, Aug 16, 2020 at 1:06 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>> On Sun, 16 Aug 2020 12:59:02 -0700
>> Christian Stewart <christian@paral.in> wrote:
>>
>>> FWIW I actually had the same, was trying to test an odroid XU4 and the
>>> SSH server was immediately closing the connection. I double-checked
>>> that openssh was at the latest version & I was on the latest buildroot
>>> master as well, and assumed at the time it must have had something to
>>> do with the kernel bump I was testing.
>>>
>>> Now I'm thinking maybe this was causing it. Will test again later today.
>>
>> Could you try applying:
>>
>>  https://github.com/openssh/openssh-portable/commit/beee0ef61866cb567b9abc23bd850f922e59e3f0
>>  https://github.com/openssh/openssh-portable/commit/69298ebfc2c066acee5d187eac8ce9f38c796630
>>
>> and see if it helps ?
> 
> Tests run against buildroot master - at commit hash:
> 
> 1396b06a1ee9a86055488de593be93ae2585ceb1
> 
> == Test 1: pi3 w/ gcc 10 glibc binutils 2.34
> 
> PASS - defconfig:
> 
> BR2_arm=y
> BR2_cortex_a7=y
> BR2_ARM_FPU_NEON_VFPV4=y
> BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y
> BR2_BINUTILS_VERSION_2_34_X=y
> BR2_GCC_VERSION_10_X=y
> 
> openssh works as expected.
> 
> == Test 2: odroid xu4 with gcc 9, binutils 2.33.1
> 
> have not had a chance to test yet but this was the one that didn't work before.
> 
> BR2_arm=y
> BR2_cortex_a15_a7=y
> BR2_ARM_FPU_NEON_VFPV4=y
> BR2_TOOLCHAIN_BUILDROOT_GLIBC=y

I did a new test [1] in the Buildroot testsuite for openssh with a glibc
internal toolchain to check if the issue with gcc 10 and openssh 8.1 is fixed [2].

Can you test again ?

[1]
http://patchwork.ozlabs.org/project/buildroot/patch/20200817215545.8271-1-romain.naour at gmail.com/
[2] https://bugs.archlinux.org/task/65386

Best regards,
Romain

> 
> 
> best regards,
> Christian
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] OpenSSH login problem

[Michael Fischer]

Hello Peter,
this is my defconfig, now I will test it with the raspberrypi3 defconfig, maybe that will help me.


BR2_HOST_GCC_AT_LEAST_9=y
BR2_ARCH_HAS_MMU_OPTIONAL=y
BR2_arm=y
BR2_ARCH_HAS_TOOLCHAIN_BUILDROOT=y
BR2_ARCH="arm"
BR2_ENDIAN="LITTLE"
BR2_GCC_TARGET_ABI="aapcs-linux"
BR2_GCC_TARGET_CPU="cortex-a53"
BR2_GCC_TARGET_FPU="fp-armv8"
BR2_GCC_TARGET_FLOAT_ABI="hard"
BR2_GCC_TARGET_MODE="arm"
BR2_BINFMT_SUPPORTS_SHARED=y
BR2_READELF_ARCH_NAME="ARM"
BR2_BINFMT_ELF=y
BR2_ARM_CPU_HAS_NEON=y
BR2_ARM_CPU_HAS_FPU=y
BR2_ARM_CPU_HAS_VFPV2=y
BR2_ARM_CPU_HAS_VFPV3=y
BR2_ARM_CPU_HAS_VFPV4=y
BR2_ARM_CPU_HAS_FP_ARMV8=y
BR2_ARM_CPU_HAS_ARM=y
BR2_ARM_CPU_HAS_THUMB2=y
BR2_ARM_CPU_ARMV8A=y
BR2_cortex_a53=y
BR2_ARM_EABIHF=y
BR2_ARM_FPU_FP_ARMV8=y
BR2_ARM_INSTRUCTIONS_ARM=y
BR2_DEFCONFIG="/home/michael/buildroot/configs/raspberrypi3_defconfig"
BR2_OPTIMIZE_S=y
BR2_SHARED_LIBS=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_LIBC="glibc"
BR2_KERNEL_HEADERS_AS_KERNEL=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y
BR2_PACKAGE_LINUX_HEADERS=y
BR2_PACKAGE_GLIBC=y
BR2_PACKAGE_GLIBC_UTILS=y
BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI=y
BR2_BINUTILS_VERSION_2_34_X=y
BR2_BINUTILS_VERSION="2.34"
BR2_BINUTILS_ENABLE_LTO=y
BR2_BINUTILS_EXTRA_CONFIG_OPTIONS=""
BR2_GCC_VERSION_10_X=y
BR2_GCC_SUPPORTS_DLANG=y
BR2_GCC_VERSION="10.2.0"
BR2_EXTRA_GCC_CONFIG_OPTIONS=""
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_GCC_ENABLE_LTO=y
BR2_GCC_ENABLE_OPENMP=y
BR2_PACKAGE_HOST_GDB_ARCH_SUPPORTS=y
BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS=y
BR2_TOOLCHAIN_SUPPORTS_VARIADIC_MI_THUNK=y
BR2_TOOLCHAIN_HAS_NATIVE_RPC=y
BR2_USE_WCHAR=y
BR2_ENABLE_LOCALE=y
BR2_INSTALL_LIBSTDCPP=y
BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_19=y
BR2_TOOLCHAIN_HEADERS_AT_LEAST="4.19"
BR2_TOOLCHAIN_GCC_AT_LEAST_10=y
BR2_TOOLCHAIN_GCC_AT_LEAST="10"
BR2_TARGET_GENERIC_PASSWD_SHA256=y
BR2_TARGET_GENERIC_PASSWD_METHOD="sha-256"
BR2_TARGET_ENABLE_ROOT_LOGIN=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,676fd5a6f2a9b365da0e0371ef11acbb74cb69d5)/linux-676fd5a6f2a9b365da0e0371ef11acbb74cb69d5.tar.gz"
BR2_LINUX_KERNEL_VERSION="custom"
BR2_LINUX_KERNEL_PATCH=""
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="/home/michael/workspace/buildroot/kernel.config"
BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES=""
BR2_LINUX_KERNEL_CUSTOM_LOGO_PATH="/home/michael/workspace/buildroot/overlay/BlueBox/Config/Icons/boot.png"
BR2_PACKAGE_BUSYBOX=y
BR2_PACKAGE_BUSYBOX_CONFIG="/home/michael/workspace/buildroot/busybox.config"

Regards,
  Michael


> To: Michael Nosthoff via buildroot <buildroot@busybox.net>
> Cc: Michael Nosthoff <buildroot@heine.tech>; Michael Fischer <mf@go-
> sys.de>
>  Re: [Buildroot] OpenSSH login problem
> 
> Hello Michael (Fischer),
> 
> On Thu, 13 Aug 2020 17:54:31 +0200, Michael Nosthoff via buildroot
> <buildroot@busybox.net> wrote:
> 
> > Hi,
> >
> > I try to rephrase what you did to see if I understood it correctly:
> >
> > You built a Raspberry Pi BR Image based on commit
> > 01632805ab4be2bea4010ba1e46ab71f52d175a9
> > from the Buildroot git. OpenSSH works.
> > Then you did a git pull, did a "make clean && make" and with the resulting
> image you can't login via ssh.
> >
> > Is this correct?
> >
> > This assumed I tried the following:
> >
> > git log --oneline
> > 01632805ab4be2bea4010ba1e46ab71f52d175a9..origin/master
> > (origin/master is currently at
> > d1d89d37c02e3d8224fb6f812e87fef5612a771a)
> >
> > From the result I can tell that the OpenSSH package hasn't changed. So
> > it has to be some lib or something in the Filesystem.
> >
> > One commit that looks like it could be the troublemaker is:
> >
> > 060599fc23 package/rpi-userland: bump version to 188d3bf
> >
> > But else this might be a good idea to try to debug using git bisect
> > and move through the tree to see when it breaks.
> >
> > I don't really have a Pi at hand right now. But to reproduce someone
> > would need a minimal BR configuration which shows the issue. Can you
> provide that?
> 
> Could not reproduce the problem on RPi3 Model B+ with the following
> defconfig (with buildroot-master up to commit
> d1c3f077e24a41f004945f94aceb6f059c58e423):
> 
> BR2_arm=y
> BR2_cortex_a53=y
> BR2_ARM_FPU_NEON_VFPV4=y
> BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_SYSTEM_DHCP="eth0"
> BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi3/post-build.sh"
> BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi3/post-image.sh"
> BR2_ROOTFS_POST_SCRIPT_ARGS="--add-miniuart-bt-overlay"
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
> BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call
> github,raspberrypi,linux,1c64f4bc22811d2d371b271daa3fb27895a8abdd)/li
> nux-1c64f4bc22811d2d371b271daa3fb27895a8abdd.tar.gz"
> BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
> BR2_LINUX_KERNEL_DTS_SUPPORT=y
> BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2710-rpi-3-b bcm2710-rpi-3-b-
> plus bcm2710-rpi-cm3"
> BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
> BR2_PACKAGE_STRACE=y
> BR2_PACKAGE_RPI_FIRMWARE=y
> BR2_PACKAGE_OPENSSH=y
> BR2_TARGET_ROOTFS_EXT2=y
> BR2_TARGET_ROOTFS_EXT2_4=y
> BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
> # BR2_TARGET_ROOTFS_TAR is not set
> BR2_PACKAGE_HOST_DOSFSTOOLS=y
> BR2_PACKAGE_HOST_GENIMAGE=y
> BR2_PACKAGE_HOST_MTOOLS=y
> 
> 
> Mind to share your .config/defconfig file? Which (exact) hardware do you use?
> 
> Regards,
> Peter
> 
> 
> >
> > Regards,
> > Michael
> >
> >
> > On Thursday, August 13, 2020 16:51 CEST, Michael Fischer <mf@go-sys.de>
> wrote:
> >
> > > Hi Michael,
> > >  here is the log, the connection is closed from the server.
> > >
> > > PS: All settings between the commits are the same.
> > > The difference between this is only a git pull.
> > >
> > >
> > > OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > > debug1: Reading configuration data /etc/ssh/ssh_config
> > > debug1: /etc/ssh/ssh_config line 20: Applying options for *
> > > debug1: Connecting to 192.168.1.194 [192.168.1.194] port 22.
> > > debug1: Connection established.
> > > debug1: identity file /root/.ssh/id_rsa type -1
> > > debug1: identity file /root/.ssh/id_rsa-cert type -1
> > > debug1: identity file /root/.ssh/id_dsa type -1
> > > debug1: identity file /root/.ssh/id_dsa-cert type -1
> > > debug1: identity file /root/.ssh/id_ecdsa type -1
> > > debug1: identity file /root/.ssh/id_ecdsa-cert type -1
> > > debug1: identity file /root/.ssh/id_ecdsa_sk type -1
> > > debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
> > > debug1: identity file /root/.ssh/id_ed25519 type -1
> > > debug1: identity file /root/.ssh/id_ed25519-cert type -1
> > > debug1: identity file /root/.ssh/id_ed25519_sk type -1
> > > debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
> > > debug1: identity file /root/.ssh/id_xmss type -1
> > > debug1: identity file /root/.ssh/id_xmss-cert type -1
> > > debug1: Local version string SSH-2.0-OpenSSH_8.3
> > > debug1: Remote protocol version 2.0, remote software version
> > > OpenSSH_8.3
> > > debug1: match: OpenSSH_8.3 pat OpenSSH* compat 0x04000000
> > > debug1: Authenticating to 192.168.1.194:22 as 'root'
> > > debug1: SSH2_MSG_KEXINIT sent
> > > debug1: SSH2_MSG_KEXINIT received
> > > debug1: kex: algorithm: curve25519-sha256
> > > debug1: kex: host key algorithm: ecdsa-sha2-nistp256
> > > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com
> > > MAC: <implicit> compression: none
> > > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com
> > > MAC: <implicit> compression: none
> > > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> > > debug1: Server host key: ecdsa-sha2-nistp256
> > > SHA256:RCq6wRn5ZZrwZ7wY84zaMFMdG1mhIorheFPFhbwBz+0
> > > debug1: Host '[192.168.1.194]:22' is known and matches the ECDSA host
> key.
> > > debug1: Found key in /root/.ssh/known_hosts:1
> > > debug1: rekey out after 134217728 blocks
> > > debug1: SSH2_MSG_NEWKEYS sent
> > > debug1: expecting SSH2_MSG_NEWKEYS
> > > debug1: SSH2_MSG_NEWKEYS received
> > > debug1: rekey in after 134217728 blocks
> > > debug1: Will attempt key: /root/.ssh/id_rsa
> > > debug1: Will attempt key: /root/.ssh/id_dsa
> > > debug1: Will attempt key: /root/.ssh/id_ecdsa
> > > debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
> > > debug1: Will attempt key: /root/.ssh/id_ed25519
> > > debug1: Will attempt key: /root/.ssh/id_ed25519_sk
> > > debug1: Will attempt key: /root/.ssh/id_xmss
> > > debug1: SSH2_MSG_EXT_INFO received
> > > debug1: kex_input_ext_info:
> > > server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-
> > > sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp38
> > > 4,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256 at openssh.com>
> > > debug1: SSH2_MSG_SERVICE_ACCEPT received Connection closed by
> > > 192.168.1.194 port 22
> > >
> > > Regards,
> > >   Michael.
> > >
> > >
> > > > On Thursday, August 13, 2020 16:35 CEST, Michael Nosthoff
> > > > <buildroot@heine.tech>
> > > > wrote:
> > > >
> > > > Hi Michael,
> > > >
> > > > On Thursday, August 13, 2020 15:35 CEST, Michael Fischer
> > > > <mf@go-sys.de>
> > > > wrote:
> > > >
> > > > > Dear all,
> > > > >
> > > > > I have a problem with the OpenSSH login on my raspberry.
> > > > > I can't login via ssh, after entering the username, the sever
> > > > > closed the
> > > > connection.
> > > > >
> > > > > I have checked it with the commit
> > > > 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version
> works
> > > > with the same configuration.
> > > > > The actual commit doesn't work but  both commits have the same
> > > > > OpenSSH
> > > > version.
> > > > >
> > > > > OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > > > >
> > > > > My SSHD logofile:
> > > > >
> > > > > debug2: parse_server_config_depth: config reprocess config len
> > > > > 236
> > > > > debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days
> > > > > left -
> > > > 18488
> > > > > debug3: account expiration disabled
> > > > > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM:
> 1
> > > > > debug3: mm_request_send entering: type 9
> > > > > debug2: monitor_read: 8 used once, disabling now
> > > > > debug2: input_userauth_request: setting up authctxt for root
> > > > > [preauth]
> > > > > debug3: mm_inform_authserv entering [preauth]
> > > > > debug3: mm_request_send entering: type 4 [preauth]
> > > > > debug2: input_userauth_request: try method none [preauth]
> > > > > debug3: mm_request_receive entering
> > > > > debug3: monitor_read: checking request 4
> > > > > debug3: mm_answer_authserv: service=ssh-connection, style=
> > > > > debug2: monitor_read: 4 used once, disabling now
> > > > > debug3: user_specific_delay: user specific delay 0.000ms
> > > > > [preauth]
> > > > > debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying
> > > > 10.089ms (requested 5.154ms) [preauth]
> > > > > debug1: monitor_read_log: child log fd closed
> > > > > debug3: mm_request_receive entering
> > > > > debug1: do_cleanup
> > > > > debug1: Killing privsep child 390
> > > > >
> > > > > I don't know what is going wrong.
> > > > > Console login works and ftp also.
> > > > >
> > > > > Any help is welcome, I have no more idea where to look.
> > > > >
> > > >
> > > > Could you run the Client with the -v flag? So you could see if
> > > > actually the client or the server is closing the connection.
> > > > A pretty common problem is often a mismatch in available
> > > > authentication mechanisms (commonly "publickey,password").
> > > >
> > > > Also what sometimes is an issue is the permissions of the users
> > > > .ssh folder on the server side.
> > > > If it is globally readable sshd in many configurations refuses to
> > > > authenticate against it.
> > > >
> > > > Regards,
> > > > Michael
> > > >
> > > > >
> > > > > thanks,
> > > > >   Michael.
> > > > >
> > > > > _______________________________________________
> > > > > buildroot mailing list
> > > > > buildroot at busybox.net
> > > > > http://lists.busybox.net/mailman/listinfo/buildroot
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > buildroot mailing list
> > > buildroot at busybox.net
> > > http://lists.busybox.net/mailman/listinfo/buildroot
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 
> 

[Buildroot] OpenSSH login problem

[Michael Fischer]

Hello Peter,

now I have checked the build with a new defconfig with my packages and it works.
The main difference to my old settings are the 5.4  Kernel and I set the "Fortify Source" check to 1.

I will check it with Fortify Source = 2.


Regards
  Michael.



> -----Urspr?ngliche Nachricht-----
> Von: Peter Seiderer [mailto:ps.report at gmx.net]
> Gesendet: Montag, 17. August 2020 23:33
> An: Michael Nosthoff via buildroot <buildroot@busybox.net>
> Cc: Michael Nosthoff <buildroot@heine.tech>; Michael Fischer <mf@go-
> sys.de>
> Betreff: Re: [Buildroot] OpenSSH login problem
> 
> Hello Michael (Fischer),
> 
> On Thu, 13 Aug 2020 17:54:31 +0200, Michael Nosthoff via buildroot
> <buildroot@busybox.net> wrote:
> 
> > Hi,
> >
> > I try to rephrase what you did to see if I understood it correctly:
> >
> > You built a Raspberry Pi BR Image based on commit
> > 01632805ab4be2bea4010ba1e46ab71f52d175a9
> > from the Buildroot git. OpenSSH works.
> > Then you did a git pull, did a "make clean && make" and with the resulting
> image you can't login via ssh.
> >
> > Is this correct?
> >
> > This assumed I tried the following:
> >
> > git log --oneline
> > 01632805ab4be2bea4010ba1e46ab71f52d175a9..origin/master
> > (origin/master is currently at
> > d1d89d37c02e3d8224fb6f812e87fef5612a771a)
> >
> > From the result I can tell that the OpenSSH package hasn't changed. So
> > it has to be some lib or something in the Filesystem.
> >
> > One commit that looks like it could be the troublemaker is:
> >
> > 060599fc23 package/rpi-userland: bump version to 188d3bf
> >
> > But else this might be a good idea to try to debug using git bisect
> > and move through the tree to see when it breaks.
> >
> > I don't really have a Pi at hand right now. But to reproduce someone
> > would need a minimal BR configuration which shows the issue. Can you
> provide that?
> 
> Could not reproduce the problem on RPi3 Model B+ with the following
> defconfig (with buildroot-master up to commit
> d1c3f077e24a41f004945f94aceb6f059c58e423):
> 
> BR2_arm=y
> BR2_cortex_a53=y
> BR2_ARM_FPU_NEON_VFPV4=y
> BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_SYSTEM_DHCP="eth0"
> BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi3/post-build.sh"
> BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi3/post-image.sh"
> BR2_ROOTFS_POST_SCRIPT_ARGS="--add-miniuart-bt-overlay"
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
> BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call
> github,raspberrypi,linux,1c64f4bc22811d2d371b271daa3fb27895a8abdd)/li
> nux-1c64f4bc22811d2d371b271daa3fb27895a8abdd.tar.gz"
> BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
> BR2_LINUX_KERNEL_DTS_SUPPORT=y
> BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2710-rpi-3-b bcm2710-rpi-3-b-
> plus bcm2710-rpi-cm3"
> BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
> BR2_PACKAGE_STRACE=y
> BR2_PACKAGE_RPI_FIRMWARE=y
> BR2_PACKAGE_OPENSSH=y
> BR2_TARGET_ROOTFS_EXT2=y
> BR2_TARGET_ROOTFS_EXT2_4=y
> BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
> # BR2_TARGET_ROOTFS_TAR is not set
> BR2_PACKAGE_HOST_DOSFSTOOLS=y
> BR2_PACKAGE_HOST_GENIMAGE=y
> BR2_PACKAGE_HOST_MTOOLS=y
> 
> 
> Mind to share your .config/defconfig file? Which (exact) hardware do you use?
> 
> Regards,
> Peter
> 
> 
> >
> > Regards,
> > Michael
> >
> >
> > On Thursday, August 13, 2020 16:51 CEST, Michael Fischer <mf@go-sys.de>
> wrote:
> >
> > > Hi Michael,
> > >  here is the log, the connection is closed from the server.
> > >
> > > PS: All settings between the commits are the same.
> > > The difference between this is only a git pull.
> > >
> > >
> > > OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > > debug1: Reading configuration data /etc/ssh/ssh_config
> > > debug1: /etc/ssh/ssh_config line 20: Applying options for *
> > > debug1: Connecting to 192.168.1.194 [192.168.1.194] port 22.
> > > debug1: Connection established.
> > > debug1: identity file /root/.ssh/id_rsa type -1
> > > debug1: identity file /root/.ssh/id_rsa-cert type -1
> > > debug1: identity file /root/.ssh/id_dsa type -1
> > > debug1: identity file /root/.ssh/id_dsa-cert type -1
> > > debug1: identity file /root/.ssh/id_ecdsa type -1
> > > debug1: identity file /root/.ssh/id_ecdsa-cert type -1
> > > debug1: identity file /root/.ssh/id_ecdsa_sk type -1
> > > debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
> > > debug1: identity file /root/.ssh/id_ed25519 type -1
> > > debug1: identity file /root/.ssh/id_ed25519-cert type -1
> > > debug1: identity file /root/.ssh/id_ed25519_sk type -1
> > > debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
> > > debug1: identity file /root/.ssh/id_xmss type -1
> > > debug1: identity file /root/.ssh/id_xmss-cert type -1
> > > debug1: Local version string SSH-2.0-OpenSSH_8.3
> > > debug1: Remote protocol version 2.0, remote software version
> > > OpenSSH_8.3
> > > debug1: match: OpenSSH_8.3 pat OpenSSH* compat 0x04000000
> > > debug1: Authenticating to 192.168.1.194:22 as 'root'
> > > debug1: SSH2_MSG_KEXINIT sent
> > > debug1: SSH2_MSG_KEXINIT received
> > > debug1: kex: algorithm: curve25519-sha256
> > > debug1: kex: host key algorithm: ecdsa-sha2-nistp256
> > > debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com
> > > MAC: <implicit> compression: none
> > > debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com
> > > MAC: <implicit> compression: none
> > > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > > debug1: kex: curve25519-sha256 need=64 dh_need=64
> > > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> > > debug1: Server host key: ecdsa-sha2-nistp256
> > > SHA256:RCq6wRn5ZZrwZ7wY84zaMFMdG1mhIorheFPFhbwBz+0
> > > debug1: Host '[192.168.1.194]:22' is known and matches the ECDSA host
> key.
> > > debug1: Found key in /root/.ssh/known_hosts:1
> > > debug1: rekey out after 134217728 blocks
> > > debug1: SSH2_MSG_NEWKEYS sent
> > > debug1: expecting SSH2_MSG_NEWKEYS
> > > debug1: SSH2_MSG_NEWKEYS received
> > > debug1: rekey in after 134217728 blocks
> > > debug1: Will attempt key: /root/.ssh/id_rsa
> > > debug1: Will attempt key: /root/.ssh/id_dsa
> > > debug1: Will attempt key: /root/.ssh/id_ecdsa
> > > debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
> > > debug1: Will attempt key: /root/.ssh/id_ed25519
> > > debug1: Will attempt key: /root/.ssh/id_ed25519_sk
> > > debug1: Will attempt key: /root/.ssh/id_xmss
> > > debug1: SSH2_MSG_EXT_INFO received
> > > debug1: kex_input_ext_info:
> > > server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-
> > > sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp38
> > > 4,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256 at openssh.com>
> > > debug1: SSH2_MSG_SERVICE_ACCEPT received Connection closed by
> > > 192.168.1.194 port 22
> > >
> > > Regards,
> > >   Michael.
> > >
> > >
> > > > On Thursday, August 13, 2020 16:35 CEST, Michael Nosthoff
> > > > <buildroot@heine.tech>
> > > > wrote:
> > > >
> > > > Hi Michael,
> > > >
> > > > On Thursday, August 13, 2020 15:35 CEST, Michael Fischer
> > > > <mf@go-sys.de>
> > > > wrote:
> > > >
> > > > > Dear all,
> > > > >
> > > > > I have a problem with the OpenSSH login on my raspberry.
> > > > > I can't login via ssh, after entering the username, the sever
> > > > > closed the
> > > > connection.
> > > > >
> > > > > I have checked it with the commit
> > > > 01632805ab4be2bea4010ba1e46ab71f52d175a9 and this version
> works
> > > > with the same configuration.
> > > > > The actual commit doesn't work but  both commits have the same
> > > > > OpenSSH
> > > > version.
> > > > >
> > > > > OpenSSH Version is:  OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
> > > > >
> > > > > My SSHD logofile:
> > > > >
> > > > > debug2: parse_server_config_depth: config reprocess config len
> > > > > 236
> > > > > debug3: auth_shadow_acctexpired: today 18487 sp_expire -1 days
> > > > > left -
> > > > 18488
> > > > > debug3: account expiration disabled
> > > > > debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM:
> 1
> > > > > debug3: mm_request_send entering: type 9
> > > > > debug2: monitor_read: 8 used once, disabling now
> > > > > debug2: input_userauth_request: setting up authctxt for root
> > > > > [preauth]
> > > > > debug3: mm_inform_authserv entering [preauth]
> > > > > debug3: mm_request_send entering: type 4 [preauth]
> > > > > debug2: input_userauth_request: try method none [preauth]
> > > > > debug3: mm_request_receive entering
> > > > > debug3: monitor_read: checking request 4
> > > > > debug3: mm_answer_authserv: service=ssh-connection, style=
> > > > > debug2: monitor_read: 4 used once, disabling now
> > > > > debug3: user_specific_delay: user specific delay 0.000ms
> > > > > [preauth]
> > > > > debug3: ensure_minimum_time_since: elapsed 10.528ms, delaying
> > > > 10.089ms (requested 5.154ms) [preauth]
> > > > > debug1: monitor_read_log: child log fd closed
> > > > > debug3: mm_request_receive entering
> > > > > debug1: do_cleanup
> > > > > debug1: Killing privsep child 390
> > > > >
> > > > > I don't know what is going wrong.
> > > > > Console login works and ftp also.
> > > > >
> > > > > Any help is welcome, I have no more idea where to look.
> > > > >
> > > >
> > > > Could you run the Client with the -v flag? So you could see if
> > > > actually the client or the server is closing the connection.
> > > > A pretty common problem is often a mismatch in available
> > > > authentication mechanisms (commonly "publickey,password").
> > > >
> > > > Also what sometimes is an issue is the permissions of the users
> > > > .ssh folder on the server side.
> > > > If it is globally readable sshd in many configurations refuses to
> > > > authenticate against it.
> > > >
> > > > Regards,
> > > > Michael
> > > >
> > > > >
> > > > > thanks,
> > > > >   Michael.
> > > > >
> > > > > _______________________________________________
> > > > > buildroot mailing list
> > > > > buildroot at busybox.net
> > > > > http://lists.busybox.net/mailman/listinfo/buildroot
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > buildroot mailing list
> > > buildroot at busybox.net
> > > http://lists.busybox.net/mailman/listinfo/buildroot
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 
> 

[Buildroot] OpenSSH login problem

[Christian Stewart]

Hi all,

Finally got around to running this test.

I previously tested an Odroid XU4 with GCC 10 and latest binutils, and
it worked.

Now with a test against GCC 9 on a Odroid HC2, it's not working (ssh
exits immediately after successful auth).

Testing against OpenSSH 8.3p1 now and figuring out exactly why this is
happening, if it's the GCC version or what.

On Mon, Aug 17, 2020 at 2:36 PM Christian Stewart <christian@paral.in> wrote:
> On Sun, Aug 16, 2020 at 1:06 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> > On Sun, 16 Aug 2020 12:59:02 -0700
> > Christian Stewart <christian@paral.in> wrote:
> >
> > > FWIW I actually had the same, was trying to test an odroid XU4 and the
> > > SSH server was immediately closing the connection. I double-checked
> > > that openssh was at the latest version & I was on the latest buildroot
> > > master as well, and assumed at the time it must have had something to
> > > do with the kernel bump I was testing.
> > >
> > > Now I'm thinking maybe this was causing it. Will test again later today.
> >
> > Could you try applying:
> >
> >  https://github.com/openssh/openssh-portable/commit/beee0ef61866cb567b9abc23bd850f922e59e3f0
> >  https://github.com/openssh/openssh-portable/commit/69298ebfc2c066acee5d187eac8ce9f38c796630
> >
> > and see if it helps ?

Have not tried these yet but I think they are included in 8.3 anyway.

> == Test 1: pi3 w/ gcc 10 glibc binutils 2.34
>
> PASS

Strangely this one worked.

Best regards,
Christian

[Buildroot] OpenSSH login problem

[Peter Seiderer]

Hello Christian, *,

On Sat, 5 Sep 2020 19:33:23 -0700, Christian Stewart <christian@paral.in> wrote:

> Hi all,
>
> Finally got around to running this test.
>
> I previously tested an Odroid XU4 with GCC 10 and latest binutils, and
> it worked.
>
> Now with a test against GCC 9 on a Odroid HC2, it's not working (ssh
> exits immediately after successful auth).
>
> Testing against OpenSSH 8.3p1 now and figuring out exactly why this is
> happening, if it's the GCC version or what.

Tested on RPi3, the following defconfig works (buildroot-git-d1c3f077e24a41f004945f94aceb6f059c58e423,
linux-5.4.51):

BR2_arm=y
BR2_cortex_a53=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_SYSTEM_DHCP="eth0"
BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi3/post-build.sh"
BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi3/post-image.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="--add-miniuart-bt-overlay"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,1c64f4bc22811d2d371b271daa3fb27895a8abdd)/linux-1c64f4bc22811d2d371b271daa3fb27895a8abdd.tar.gz"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2710-rpi-3-b bcm2710-rpi-3-b-plus bcm2710-rpi-cm3"
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_RPI_FIRMWARE=y
BR2_PACKAGE_OPENSSH=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
# BR2_TARGET_ROOTFS_TAR is not set
BR2_PACKAGE_HOST_DOSFSTOOLS=y
BR2_PACKAGE_HOST_GENIMAGE=y
BR2_PACKAGE_HOST_MTOOLS=y


And the following defconfig fails (linux-4.19.126):

BR2_arm=y
BR2_cortex_a53=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_SYSTEM_DHCP="eth0"
BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi3/post-build.sh"
BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi3/post-image.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="--add-miniuart-bt-overlay"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,676fd5a6f2a9b365da0e0371ef11acbb74cb69d5)/linux-676fd5a6f2a9b365da0e0371ef11acbb74cb69d5.tar.gz"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2710-rpi-3-b bcm2710-rpi-3-b-plus bcm2710-rpi-cm3"
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_RPI_FIRMWARE=y
BR2_PACKAGE_OPENSSH=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
# BR2_TARGET_ROOTFS_TAR is not set
BR2_PACKAGE_HOST_DOSFSTOOLS=y
BR2_PACKAGE_HOST_GENIMAGE=y
BR2_PACKAGE_HOST_MTOOLS=y


The differences are:

-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y

and

-BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,1c64f4bc22811d2d371b271daa3fb27895a8abdd)/linux-1c64f4bc22811d2d371b271daa3fb27895a8abdd.tar.gz"
+BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,676fd5a6f2a9b365da0e0371ef11acbb74cb69d5)/linux-676fd5a6f2a9b365da0e0371ef11acbb74cb69d5.tar.gz"


The last lines of sshd failure strace are:

468   write(2, "Accepted none for root from 192."..., 59 <unfinished ...>
490   clock_gettime(CLOCK_BOOTTIME, {tv_sec=306, tv_nsec=379381706}) = 0
490   clock_nanosleep_time64(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=24656548290918313},  <unfinished ...>) = ?
490   +++ killed by SIGSYS +++
468   <... write resumed>)              = 59
468   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=490, si_uid=1000, si_status=SIGSYS, si_utime=7, si_stime=2} ---
468   write(2, "debug1: monitor_child_preauth: r"..., 82) = 82
468   read(5, "", 4)                    = 0
468   write(2, "debug1: do_cleanup\r\n", 20) = 20
468   write(2, "debug1: Killing privsep child 49"..., 35) = 35
468   kill(490, SIGKILL)                = 0
468   exit_group(255)                   = ?
468   +++ exited with 255 +++


In the failing case __NR_clock_nanosleep_time64 is not defined, so
SC_ALLOW(__NR_clock_nanosleep_time64) in openssh-8.3p1/sandbox-seccomp-filter.c
is not set...., but the strace output shows clock_nanosleep_time64() is called
(and aborted with SIGSYS)...

Regards,
Peter

>
> On Mon, Aug 17, 2020 at 2:36 PM Christian Stewart <christian@paral.in> wrote:
> > On Sun, Aug 16, 2020 at 1:06 PM Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> > > On Sun, 16 Aug 2020 12:59:02 -0700
> > > Christian Stewart <christian@paral.in> wrote:
> > >
> > > > FWIW I actually had the same, was trying to test an odroid XU4 and the
> > > > SSH server was immediately closing the connection. I double-checked
> > > > that openssh was at the latest version & I was on the latest buildroot
> > > > master as well, and assumed at the time it must have had something to
> > > > do with the kernel bump I was testing.
> > > >
> > > > Now I'm thinking maybe this was causing it. Will test again later today.
> > >
> > > Could you try applying:
> > >
> > >  https://github.com/openssh/openssh-portable/commit/beee0ef61866cb567b9abc23bd850f922e59e3f0
> > >  https://github.com/openssh/openssh-portable/commit/69298ebfc2c066acee5d187eac8ce9f38c796630
> > >
> > > and see if it helps ?
>
> Have not tried these yet but I think they are included in 8.3 anyway.
>
> > == Test 1: pi3 w/ gcc 10 glibc binutils 2.34
> >
> > PASS
>
> Strangely this one worked.
>
> Best regards,
> Christian
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] OpenSSH login problem

[Christian Stewart]

Hi all,

Unfortunately I'm still seeing this with GCC 9 and OpenSSH 8.3p1
against a Odroid HC2 with kernel 5.8 + kernel-headers 5.8, using glibc
2.31.

On Sun, Sep 6, 2020 at 10:40 AM Peter Seiderer <ps.report@gmx.net> wrote:
>
> Hello Christian, *,
>
> On Sat, 5 Sep 2020 19:33:23 -0700, Christian Stewart <christian@paral.in> wrote:
>
> > Hi all,
> >
> > Finally got around to running this test.
> >
> > I previously tested an Odroid XU4 with GCC 10 and latest binutils, and
> > it worked.
> >
> > Now with a test against GCC 9 on a Odroid HC2, it's not working (ssh
> > exits immediately after successful auth).
> >
> > Testing against OpenSSH 8.3p1 now and figuring out exactly why this is
> > happening, if it's the GCC version or what.
>
> Tested on RPi3, the following defconfig works (buildroot-git-d1c3f077e24a41f004945f94aceb6f059c58e423,
> linux-5.4.51):

[snip]

> And the following defconfig fails (linux-4.19.126):

[snip]

> The last lines of sshd failure strace are:
>
> 468   write(2, "Accepted none for root from 192."..., 59 <unfinished ...>
> 490   clock_gettime(CLOCK_BOOTTIME, {tv_sec=306, tv_nsec=379381706}) = 0
> 490   clock_nanosleep_time64(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=24656548290918313},  <unfinished ...>) = ?
> 490   +++ killed by SIGSYS +++
> 468   <... write resumed>)              = 59
> 468   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=490, si_uid=1000, si_status=SIGSYS, si_utime=7, si_stime=2} ---
> 468   write(2, "debug1: monitor_child_preauth: r"..., 82) = 82
> 468   read(5, "", 4)                    = 0
> 468   write(2, "debug1: do_cleanup\r\n", 20) = 20
> 468   write(2, "debug1: Killing privsep child 49"..., 35) = 35
> 468   kill(490, SIGKILL)                = 0
> 468   exit_group(255)                   = ?
> 468   +++ exited with 255 +++
>
>
> In the failing case __NR_clock_nanosleep_time64 is not defined, so
> SC_ALLOW(__NR_clock_nanosleep_time64) in openssh-8.3p1/sandbox-seccomp-filter.c
> is not set...., but the strace output shows clock_nanosleep_time64() is called
> (and aborted with SIGSYS)...

Thanks for checking on this. Is there any known fix anywhere yet? I'll
do some searching.

Thanks,
Christian

[Buildroot] OpenSSH login problem

[Peter Seiderer]

Hello Christian,

On Tue, 8 Sep 2020 18:39:47 -0700, Christian Stewart <christian@paral.in> wrote:

> Hi all,
>
> Unfortunately I'm still seeing this with GCC 9 and OpenSSH 8.3p1
> against a Odroid HC2 with kernel 5.8 + kernel-headers 5.8, using glibc
> 2.31.
>
> On Sun, Sep 6, 2020 at 10:40 AM Peter Seiderer <ps.report@gmx.net> wrote:
> >
> > Hello Christian, *,
> >
> > On Sat, 5 Sep 2020 19:33:23 -0700, Christian Stewart <christian@paral.in> wrote:
> >
> > > Hi all,
> > >
> > > Finally got around to running this test.
> > >
> > > I previously tested an Odroid XU4 with GCC 10 and latest binutils, and
> > > it worked.
> > >
> > > Now with a test against GCC 9 on a Odroid HC2, it's not working (ssh
> > > exits immediately after successful auth).
> > >
> > > Testing against OpenSSH 8.3p1 now and figuring out exactly why this is
> > > happening, if it's the GCC version or what.
> >
> > Tested on RPi3, the following defconfig works (buildroot-git-d1c3f077e24a41f004945f94aceb6f059c58e423,
> > linux-5.4.51):
>
> [snip]
>
> > And the following defconfig fails (linux-4.19.126):
>
> [snip]
>
> > The last lines of sshd failure strace are:
> >
> > 468   write(2, "Accepted none for root from 192."..., 59 <unfinished ...>
> > 490   clock_gettime(CLOCK_BOOTTIME, {tv_sec=306, tv_nsec=379381706}) = 0
> > 490   clock_nanosleep_time64(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=24656548290918313},  <unfinished ...>) = ?
> > 490   +++ killed by SIGSYS +++
> > 468   <... write resumed>)              = 59
> > 468   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=490, si_uid=1000, si_status=SIGSYS, si_utime=7, si_stime=2} ---
> > 468   write(2, "debug1: monitor_child_preauth: r"..., 82) = 82
> > 468   read(5, "", 4)                    = 0
> > 468   write(2, "debug1: do_cleanup\r\n", 20) = 20
> > 468   write(2, "debug1: Killing privsep child 49"..., 35) = 35
> > 468   kill(490, SIGKILL)                = 0
> > 468   exit_group(255)                   = ?
> > 468   +++ exited with 255 +++
> >
> >
> > In the failing case __NR_clock_nanosleep_time64 is not defined, so
> > SC_ALLOW(__NR_clock_nanosleep_time64) in openssh-8.3p1/sandbox-seccomp-filter.c
> > is not set...., but the strace output shows clock_nanosleep_time64() is called
> > (and aborted with SIGSYS)...
>
> Thanks for checking on this. Is there any known fix anywhere yet? I'll
> do some searching.

For the working case 'grep -R clock_nanosleep_time64 ./host' gives:

./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/asm-generic/unistd.h:#define __NR_clock_nanosleep_time64 407
./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_clock_nanosleep_time64, sys_clock_nanosleep)
./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/asm/unistd-common.h:#define __NR_clock_nanosleep_time64 (__NR_SYSCALL_BASE + 407)
./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/bits/syscall.h:#ifdef __NR_clock_nanosleep_time64
./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/bits/syscall.h:# define SYS_clock_nanosleep_time64 __NR_clock_nanosleep_time64
grep: ./host/arm-buildroot-linux-gnueabihf/sysroot/dev/fd: No such file or directory
grep: ./host/arm-buildroot-linux-gnueabihf/sysroot/dev/stderr: No such file or directory
grep: ./host/arm-buildroot-linux-gnueabihf/sysroot/dev/stdin: No such file or directory
grep: ./host/arm-buildroot-linux-gnueabihf/sysroot/dev/stdout: No such file or directory
grep: ./host/arm-buildroot-linux-gnueabihf/sysroot/etc/mtab: No such file or directory
grep: ./host/arm-buildroot-linux-gnueabihf/sysroot/etc/resolv.conf: No such file or directory
Binary file ./host/arm-buildroot-linux-gnueabihf/sysroot/sbin/ldconfig matches
Binary file ./host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc-2.31.so matches
Binary file ./host/arm-buildroot-linux-gnueabihf/sysroot/lib/libc.so.6 matches
Binary file ./host/arm-buildroot-linux-gnueabihf/sysroot/lib32/libc-2.31.so matches
Binary file ./host/arm-buildroot-linux-gnueabihf/sysroot/lib32/libc.so.6 matches


Could you do the same for your failing 'Odroid HC2 with kernel 5.8
+ kernel-headers 5.8' case (and send my your defconfig)?

Regards,
Peter

>
> Thanks,
> Christian
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] OpenSSH login problem

[Christian Stewart]

Hi Peter,


On Wed, Sep 9, 2020 at 10:55 AM Peter Seiderer <ps.report@gmx.net> wrote:
> > Thanks for checking on this. Is there any known fix anywhere yet? I'll
> > do some searching.

> Could you do the same for your failing 'Odroid HC2 with kernel 5.8
> + kernel-headers 5.8' case (and send my your defconfig)?

I'm not sure what changed to fix the problem (unfortunately) but with
kernel 5.8.6, headers 5.8.6, OpenSSH 8.3p1, OpenSSL 1.1.1g, glibc
2.30-73, binutils 2.32 (perhaps the binutils change did it) - it
works.

This is against an odroid hc2, armv7l.

Working case, as requested:

./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/asm-generic/unistd.h:#define
__NR_clock_nanosleep_time64 407
./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_clock_nanosleep_time64,
sys_clock_nanosleep)
./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/bits/syscall.h:#ifdef
__NR_clock_nanosleep_time64
./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/bits/syscall.h:#
define SYS_clock_nanosleep_time64 __NR_clock_nanosleep_time64
./host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/asm/unistd-common.h:#define
__NR_clock_nanosleep_time64 (__NR_SYSCALL_BASE + 407)


Best,
Christian