Page MenuHomePhabricator

Hide "Warning: Permanently added ... to the list of known hosts." in Harbormaster
ClosedPublic

Authored by hach-que on Aug 27 2014, 1:59 AM.
Tags
None
Referenced Files
F14052103: D10362.diff
Fri, Nov 15, 6:35 AM
F14048400: D10362.id.diff
Thu, Nov 14, 7:41 AM
F14042080: D10362.id24967.diff
Tue, Nov 12, 12:12 AM
F14032927: D10362.diff
Sat, Nov 9, 4:12 PM
F14029826: D10362.id.diff
Fri, Nov 8, 9:40 PM
F13975918: D10362.id24967.diff
Oct 18 2024, 12:12 PM
F13975617: D10362.id24967.diff
Oct 18 2024, 10:58 AM
F13964898: D10362.id.diff
Oct 15 2024, 10:34 PM
Subscribers

Details

Summary

Ref T1049. This messages is always printed to standard error now that the known hosts file is set to /dev/null. This hides the warning so that we'll be able to parse stderr for Windows hosts (where Powershell decides to output XML...)

Test Plan

Tested locally and verified the warning no longer appears.

Diff Detail

Repository
rP Phabricator
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

hach-que retitled this revision from to Hide "Warning: Permanently added ... to the list of known hosts." in Harbormaster.
hach-que updated this object.
hach-que edited the test plan for this revision. (Show Details)
hach-que added a reviewer: epriestley.
epriestley edited edge metadata.

I don't like that this may hide other errors, but don't have a cleaner approach. At some point down the line maybe we can add host pinning, build a real known hosts file, and use that if the user configures it.

This revision is now accepted and ready to land.Aug 27 2014, 7:13 PM

The problem with using real host pinning is EC2, especially when you have multiple blueprints that allocate different platform types (where the SSH key might be different and thus make SSH fail the host check).

Actually a better idea is probably to use TempFile to write out a known_hosts and then use that to connect, so we validate that we're connecting to the right machine (especially since we have the credential and can get the public key).

I think we would store the fingerprint on the resource, so the allocator would just be responsible for handling it. That should be fine across platforms/AMIs/etc.

Right, that's what I'm imagining.

I'll land this for now and do the TempFile stuff later (since that needs TempFiles created on resources and whatnot).

hach-que updated this revision to Diff 24967.

Closed by commit rPb163883d88c6 (authored by @hach-que).

Yeah, the file thing (particularly if we're pre-seeding it with the right fingerprint) feels like a 2020 feature.