There is currently an issue with the way we do our ssh connections where if authentication fails, it falls back on any keys located in the .ssh directory of the current user. This is really bad behavior, but not likely to cause a problem since we are running in docker containers. It's not likely there would be anything in that directory anyway - the containers start without a .ssh directory, so the only way there would be keys in it would be if someone exec'ed into the container via kubectl exec, and then created keys etc. So, probably a low priority, but still something worth cleaning up.
Here is a proposed fix for it:
#22
I've manually tested this, and there are lots of ssh tests in files, so I believe it works, but perhaps we need more tests or something like that.
There is currently an issue with the way we do our ssh connections where if authentication fails, it falls back on any keys located in the .ssh directory of the current user. This is really bad behavior, but not likely to cause a problem since we are running in docker containers. It's not likely there would be anything in that directory anyway - the containers start without a .ssh directory, so the only way there would be keys in it would be if someone exec'ed into the container via kubectl exec, and then created keys etc. So, probably a low priority, but still something worth cleaning up.
Here is a proposed fix for it:
#22
I've manually tested this, and there are lots of ssh tests in files, so I believe it works, but perhaps we need more tests or something like that.