Red Hat Bugzilla – Bug 840159
kdumpctl takes over .ssh/config file unnecessarily
Last modified: 2013-06-07 23:24:37 EDT
Description of problem:
"kdumpctl propigate" needs to stop being so greedy with its ssh configuation. I realize that it needs to get kdump to ssh out using ~/.ssh/kdump_id_rsa ... but why must it make the root user on the machine *always* use the kdump_id_rsa identity?
It creates a ~/.ssh/config file with these contents:
Why? Couldn't kdump, when scp'ing out post-crash, simply use the scp command-line options thus:
scp -i ~/.ssh/kdump_id_rsa
Surely this would better than taking over all ssh/scp activity with the kdump key identity! It should also be simpler to configure: mkdumpctl need not modify or create ssh config files at all.
Version-Release number of selected component (if applicable):
Please consider this for F18
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Hi, joshua, I don't see this happens. kdump never creates .ssh/config.
Do you still have this problem?
Yes... it still happens. "kdumpctl propagate" *always* creates /root/.ssh/config
I tried "kdumpctl propagate" in f19, and didn't find /root/.ssh/config either.
Hi Joshua, which version are you using?
This is mentioned in the opening details of the case
you can check /sbin/kdumpctl, function propagate_ssh_key used to generate/deliver key to ssh server. seems no "/root/.ssh/config" is created, unless ssh utilities did this.
It seems we can't really reproduce this issue. So it'd better if you could at least set -x in /usr/bin/kdumpctl and show us how it goes there.
It seems like kexec-tools-2.0.3-64.fc18.2 doesn't capture the /root/.ssh/config file anymore. Looking through the package changelog I don't see any mention of this change.
Test was taken on f19, still can't reproduce it.
Anyway, I will close this bug, it can be reopened if it happens later.