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
[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@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@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@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