rhtyd opened a new pull request #3333: server: save SSH keypair exactly as generated by ssh-keygen URL: https://github.com/apache/cloudstack/pull/3333 On first startup, the management server creates and saves a random ssh keypair using `ssh-keygen` in the database. The previous code used to call `trim()` on the string and imposed a restriction of 4k length on the bytes read from the file. On latest CentOS7 release (CentOS Linux release 7.6.1810 (Core)) I hit a bug where router_proxy (ssh) failed due to public key issue and kept prompting for a passphrase (the default is blank/empty). By adding a newline to the id_rsa.cloud private key it did not prompt the same and ssh worked. By performing a visual diff on bytes of the file I found that the DB version of the keypair and the version that gets put on the KVM host had a missing `line feed (0xA0)` character. This patch fixes the issue by ensuring we save the ssh keypair in the database exactly as it is generated by ssh-keygen. Furthermore, I found that sometimes the VR startup could fail if the VR took more time to patch, so I increased the number of retries it previously used to do. Screenshot showing the binary difference between ssh private key files (as on management server vs on the kvm host): ![Screenshot from 2019-05-17 13-43-46](https://user-images.githubusercontent.com/95203/57915498-8c992480-78ae-11e9-9b7b-feb45cec284f.png) After the fix the checksums match on both the kvm host and on the management server: ![Screenshot from 2019-05-17 13-59-30](https://user-images.githubusercontent.com/95203/57915527-9f135e00-78ae-11e9-8059-067034c2edb6.png) ![Screenshot from 2019-05-17 13-59-41](https://user-images.githubusercontent.com/95203/57915552-ac304d00-78ae-11e9-86cd-981bd17dd1b0.png) SSH packages details on my CentOS7 env: libssh2.x86_64 1.4.3-12.el7_6.2 @updates openssh.x86_64 7.4p1-16.el7 @anaconda openssh-askpass.x86_64 7.4p1-16.el7 @base openssh-clients.x86_64 7.4p1-16.el7 @anaconda openssh-server.x86_64 7.4p1-16.el7 @anaconda ## Types of changes <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services