| Summary: | no known_host authentication message displayed for systemtap | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Eclipse Plugin | Reporter: | Codrin Pruteanu <codrin.c.pruteanu> |
| Component: | eclipse-plugin | Assignee: | Jessica <jessica.zhang> |
| Status: | VERIFIED FIXED | QA Contact: | Andra Necula <andrax.g.necula> |
| Severity: | normal | ||
| Priority: | Medium | CC: | alexandru.c.georgescu, andrax.g.necula, ioanax.grigoropol, jessica.zhang, yp.ep.watcher, yp.watcher |
| Version: | 1.5 | ||
| Target Milestone: | 1.5 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
I have sent a patch to the list that fixes this issue on Fedora. On CentOs, the issue is still present. My guess is that this is related to the Open_SSH version, which is 5.3p1 on CentOs and 5.9p1 on Fedora and Ubuntu. The difficulty of this issue is that in the plugin, we are running ssh using LogLevel=DEBUG3 in order to get the information we need to see if there are any entries for the target in the known_hosts file. After this, we filter the output looking for an entry such as: debug3: load_hostkeys: loaded x keys This information is never logged on CentOS and thus the blocking of the interface is still present. I will look into it further and try to find a solution that is more portable. I have found a solution for this issue, using expect package. Using this package we can parse the output and find if there is a need to ask the user to add the target key to the configuration file. Jessica, is this and acceptable solution (the user will need to have expect package installed)? Just an update, other remote tools, such as latencytop and perf, inherit from TerminalHandler which already handles the SSH issues related to host keys, and passwords using SshConnectorService. The implementation is similar to the patch I have send. This could be an option for systemtap too, but the ssh connection is done in this case from the crosstap script. Ioana, Since we're using the systemtap script for ssh connection, I'd rather us to handle the exception instead of using TerminalHandler as other tools. Thanks, Jessica (In reply to comment #1) > I have sent a patch to the list that fixes this issue on Fedora. > On CentOs, the issue is still present. > My guess is that this is related to the Open_SSH version, which is 5.3p1 on > CentOs and 5.9p1 on Fedora and Ubuntu. > The difficulty of this issue is that in the plugin, we are running ssh using > LogLevel=DEBUG3 in order to get the information we need to see if there are > any entries for the target in the known_hosts file. > After this, we filter the output looking for an entry such as: > > debug3: load_hostkeys: loaded x keys > > This information is never logged on CentOS and thus the blocking of the > interface is still present. > > I will look into it further and try to find a solution that is more portable. Regarding what Ioana mentioned above for CentOS, it is also reproducible on Fedora 18 64bit. When running ssh -o LogLevel=DEBUG3 i have the following output: penssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 129/256 debug2: bits set: 490/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 46:1f:5d:b6:eb:8a:f4:7b:d7:7b:8d:2b:69:8e:f2:c8 The authenticity of host '192.168.7.2 (192.168.7.2)' can't be established. RSA key fingerprint is 46:1f:5d:b6:eb:8a:f4:7b:d7:7b:8d:2b:69:8e:f2:c8. Are you sure you want to continue connecting (yes/no)? SSH VERSION: [yocto@localhost ~]$ ssh -v OpenSSH_6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013 Verified with eclipse-poky-juno: 26bfc407781aa185f244a47ba63120343cee4a37 poky: 52b788c6df9201764130ab744bf67b770b24b896 Fedora 20, x86_64 Cheers! Andra N. |
It reproduces on: Fedora 17, CentOS 6.4 eclispe-poky: master:038cb28066b0df885f1853d75e14481c4dc56b05 OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 1. Configure eclipse-plugin environment. 2. Create a core-image-sato with tools-profile or core-image-sato-sdk on poky/master 3. Run a simple test script with systemtap tool: probe syscall.open { printf ("%s(%d) open (%s)\n", execname(), pid(), argstr) } probe timer.ms(4000) # after 4 seconds { exit () } EXPECTED RESULTS - A progress bar will be shown for the operation. - If the host does not have an entry in known_hosts a popup will show asking the user to add the entry - It it does and it matches the script is run and the progress window closes - If there is an entry but is different from the target's key, then an error is displayed to the user. ACTUAL RESULTS - The progress bar is shown, but everything is blocked and the dialogs are never shown. There is no error in the metadata log.