Connection issue in OpenBMC image
Jayashree D
jayashree-d at hcl.com
Wed Sep 16 21:35:28 AEST 2020
Classification: HCL Internal
Hi,
In UART console, I have tried the below command, but there is no response and also reboot command is not working.
root at tiogapass:~# systemctl -a | grep -i dropbear
Failed to list units: Connection timed out
root at tiogapass:~# journalctl | grep dropbear
Jan 01 00:00:21 tiogapass systemd[1]: Listening on dropbear.socket.
In working image, I got the below logs.
root at tiogapass:~# systemctl -a | grep -i dropbear
* dropbear.service not-found inactive dead dropbear.service
dropbear at 2-10.0.128.108:22-10.0.0.1:50456.service loaded active running SSH Per-Connection Server (10.0.0.1:50456)
dropbearkey.service loaded active exited SSH Key Generation
system-dropbear.slice loaded active active system-dropbear.slice
dropbear.socket loaded active listening dropbear.socket
root at tiogapass:~# journalctl | grep drop
Jan 01 00:00:37 tiogapass systemd[1]: Listening on dropbear.socket.
Jan 01 00:01:00 tiogapass avahi-daemon[294]: Successfully dropped root privileges.
Jan 01 00:01:01 tiogapass avahi-daemon[294]: Successfully dropped remaining capabilities.
Jan 01 00:15:26 tiogapass systemd[1]: Created slice system-dropbear.slice.
Jan 01 00:15:26 tiogapass dropbear[2670]: Child connection from ::ffff:10.0.0.1:51810
Jan 01 00:15:28 tiogapass dropbear[2670]: Exit before auth (user 'root', 0 fails): Exited normally
Jan 01 00:15:28 tiogapass systemd[1]: dropbear at 0-10.0.128.108:22-10.0.0.1:51810.service: Succeeded.
Jan 01 00:15:44 tiogapass dropbear[2753]: Child connection from ::ffff:10.0.0.1:51944
Jan 01 00:15:50 tiogapass dropbear[2753]: PAM password auth succeeded for 'root' from ::ffff:10.0.0.1:51944
When “top” command is run, there is no keygen running.
Regards,
Jayashree
From: Konstantin Klubnichkin <kitsok at yandex-team.ru>
Sent: Tuesday, September 15, 2020 8:19 PM
To: Jayashree D <jayashree-d at hcl.com>; openbmc at lists.ozlabs.org
Subject: Re: Connection issue in OpenBMC image
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
Hello!
If I understand correctly, TCP connection is established, but SSH handshake is not performed, right?
I've also observed this issue.
The connection is established to dropbear.socket (actually systemd) but dropbear service is not started as it's dependencies are not met.
The most obvious reason is dropbearkey.service not finished yet or failed.
If you can connect to target BMC using UART console, check status of all services containing "dropbear" in their names:
systemctl -a | grep -i dropbear
Also run "top" and see if keygen is there and running.
In my system after full flash upgrade (i.e. keys need to be re-generated) it takes several minutes.
Hope this will help.
15.09.2020, 16:12, "Jayashree D" <jayashree-d at hcl.com<mailto:jayashree-d at hcl.com>>:
Classification: HCL Internal
Thanks Konstantin Klubnichkin for your response.
I have tried this changes in my build, but it is not working.
I have tried “-v” and the below logs are shown but it is not going to password prompt and also not throwing any error.
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 10.0.128.108 [10.0.128.108] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
Regards,
Jayashree
From: Konstantin Klubnichkin <kitsok at yandex-team.ru<mailto:kitsok at yandex-team.ru>>
Sent: Monday, September 14, 2020 4:18 PM
To: Jayashree D <jayashree-d at hcl.com<mailto:jayashree-d at hcl.com>>; openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>
Subject: Re: Connection issue in OpenBMC image
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
Hello Jayashree!
I've faced issue in dropbear and public key authentication.
To investigate further I've added "-v" to ssh client. The connection is closed and a message about Non-matching signing type appears in OpenBMC log, I can't find it now.
I've found solution somewhere in Github issues, can't find the page, but here is my patch to dropbear:
===================================================================
diff --git a/signkey.c b/signkey.c
index 92fe6a2..206a886 100644
--- a/signkey.c
+++ b/signkey.c
@@ -657,8 +657,11 @@ int buf_verify(buffer * buf, sign_key *key, enum signature_type expect_sigtype,
sigtype = signature_type_from_name(type_name, type_name_len);
m_free(type_name);
- if (expect_sigtype != sigtype) {
- dropbear_exit("Non-matching signing type");
+ if (sigtype == DROPBEAR_SIGNATURE_NONE) {
+ dropbear_exit("No signature type");
+ }
+ if ((expect_sigtype != DROPBEAR_SIGNATURE_RSA_SHA256) && (expect_sigtype != sigtype)) {
+ dropbear_exit("Non-matching signing type");
}
keytype = signkey_type_from_signature(sigtype);
--
2.7.4
===================================================================
Hope this may help.
14.09.2020, 12:34, "Jayashree D" <jayashree-d at hcl.com<mailto:jayashree-d at hcl.com>>:
Classification: HCL Internal
Hi Team,
In the latest openbmc build, after flashing the image in the target, we are not able to connect the tiogapass and yosemitev2 through SSH. Is this due to any latest changes in the commit ?
Regards,
Jayashree
From: Jayashree D
Sent: Friday, September 11, 2020 4:49 PM
To: openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>
Subject: Connection issue in OpenBMC image
Classification: HCL Internal
Hi Team,
In openbmc build, after flashing the latest image (September first week) we are not able to connect tiogapass and yosemitev2 through SSH.
We tried flashing old image (August last week) in tiogapass & yosemitev2 and we are able to connect both.
After flashing latest image, in uart-console, we get the below logs as “CLOSE_WAIT” for netstat.
root at tiogapass<mailto:root at tiogapass>:~# netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 22 0 ::ffff:10.0.128.108:ssh controller.fava.net:60516 CLOSE_WAIT
tcp 22 0 ::ffff:10.0.128.108:ssh controller.fava.net:34652 CLOSE_WAIT
tcp 22 0 ::ffff:10.0.128.108:ssh controller.fava.net:58700 CLOSE_WAIT
Could anyone please provide comments on this?
Thanks,
Jayashree
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________
--
Best regards,
Konstantin Klubnichkin,
lead firmware engineer,
server hardware R&D group,
Yandex Moscow office.
tel: +7-903-510-33-33
--
Best regards,
Konstantin Klubnichkin,
lead firmware engineer,
server hardware R&D group,
Yandex Moscow office.
tel: +7-903-510-33-33
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200916/06104043/attachment-0001.htm>
More information about the openbmc
mailing list