Skip to main content

Community

Auto-trust for SSH Fingerprints

Not planned

Please sign in to leave a comment.

Comments

7 comments

  • Official comment

    Hi David, thanks for submitting this request! We don't have this planned, but it would be helpful to have a little more context so we can potentially consider this type of enhancement in the future. How often are you having to re-trust the SSH fingerprint because of this today?

    I'm here after a search landed me here. It is frustrating that I need to manually reconcile SSH fingerprints whenever this happens. Since setting up our pipelines a couple of months ago, this has happened three times I believe. Is that a lot of time? Maybe not in the grand scheme of things, but I have a million things competing for my attention, and spending 30 minutes a month to make sure only the connection to our database for our data ETL is working is frustrating. 

    For our TWO FiveTran connectors it takes about 30 minutes minimum to manually click around the FiveTran UI in order to remove old fingerprints, re-test the connection, manually sync the connectors, and then wait around to make sure it works. The bigger problem is the context switch and lack of time I could be doing something else. 

    Our infrastructure is set up such that we have AWS EC2 Instances in an AutoScaling Group and an AWS Elastic IP attached to each EC2 Instance. This means the public IP is the same, but the SSH Fingerprint will periodically change if AWS decides it needs to do maintenance on underlying infrastructure or we need to rotate the instance for security updates or something, or in David's case, EC2 Spot Instance bidding. All of these together end up causing more downtime and frustration for us managing the pipelines.

    Amy Peterson For us it is highly dependent on security updates which require reboots and AWS rotating their underlying infrastructure. For David's case, I'm sure it happens much more as AWS EC2 Spot instances come and go based on real-time price bidding.

    Hi Alex Hokanson, thanks so much for the detailed information about why this would be helpful for you. We're going to look into how we might simplify this process. Once we have some ideas, would you be open to us reaching out to share and get your feedback? Thanks again!

    One other note, we did add the ability to manage certificates via the API: https://fivetran.com/docs/rest-api/certificates#certificatemanagement. Is this something your teams might be able to leverage in the interim Alex Hokanson David Kincaid?

    Amy Peterson Yup, we would love to bounce ideas and provide feedback where possible.

    The connection management API looks like it could work as long as we don't need to do anything else for FiveTran to accept the new fingerprint. Of course, it does add complexity to managing a secret and figuring out the hash piece of the API, so I'm not sure if I will find time to automate this in the near future. I think part of the problem is that FiveTran is such a small piece of our infrastructure and our daily job that spending more time on it because of a limitation of the product is frustrating. 

    I manage approximately 25 connectors via SSH. Imagine the pain I go through when needing to approve a new SSH Fingerprint. It is extremely redundant to me to approve the certificate for all connectors one by one. It should be approved on an instance level where the fingerprint gets approved for all connectors if it is the same.

    I really need someone to look into this functionality. Even the API would not help much as it still needs to be done for all those 25 connectors one by one. Definitely a bit faster but not at all ideal.

    If I accept the fingerprint, then allow me the flexibility to accept it for the connector in question or all connectors using that SSH Host in one go. 

    Similar to other users, we encountered this recently in which we had to manually reapprove the fingerprint for all of our FiveTran connectors (+15), which resulted in data outage within our Production environment. While it's "easy" to resolve, I imagine there must be a better approach to this that resolves the "Verify SSH fingerprint" issue automatically.