Known_hosts, SFTPClient, and Erlang SSH

Questions / Help
, ,
1

I’ve spent some time mucking around SFTPClient because, unfortunately, my line of work requires me to deal with SFTP as one of the main means of getting data from various dinosaurs.

One of the major headaches I have hit, and I don’t think it has anything to do with SFTClient so much as something going on with the underlying Erlang tools is… known_hosts. Our deployed environments have read-only file systems so whenever we add another source for SFTP, I need the fingerprint to be in a static known_hosts file. This is actually fine and desirable in many ways except…

When I get a fingerprint from using ssh-keyscan or just trying ssh or sftp and checking my own known_hosts I’ll have a domain name. Whenever I connect through SFTPClient I end up with an IP address.

This is… not great. I want the domain name, not the IP because if that changes… things break and I gotta update the file and deploy. (Also, I’m not asking for solutions to this issue. Most of it is beyond my control.)

Not only is my Erlang not great, I’m a pretty casual SSH’er. When I have to do anything complicated I’m probably following a guide given to me by IT or some online guide. So my ignorance could be totally at play. The thing is, I don’t know where the issue really lies. Is this an Erlang library thing? The way SFTPClient is using Erlang? Something with an ssh config?

If anyone is more expert in this than me, please help! Haha. I’m working toward expanding my knowledge here but the number of hours in a day are painfully finite.

1 Like
2

Not the exactly fix that you wanted, but you can silently accept host and not save the host: ssh — ssh v5.3.1

Then you avoid the issue with read only fs, and since you know the domain and likely use some form of authentication, then that is good enough. The known_host file is mostly to avoid domain hijacking, but in your case it’s the reverse.

I also want to add, if you’re concerned about MITM attacks here, don’t. You, your infrastructure provider and your clients would have bigger problems then.

3 Likes
4

As is tradition, reading the docs while not stressing and being in a hurry helped.

Thanks for, more or less, pointing me back to the documentation I had tried so hard to avoid deep-diving into.

add_host_key/4 and is_host_key/4 from the :ssh_client_key_api let me handle persisting the known hosts. Checking out the code in :ssh_file got me most of what I needed.

The only thing I haven’t dug deeper into is the situation with the IP address instead of a hostname. I don’t know if this related to what SFTPClient is doing or something inside Erlang. The code in :ssh_file certainly suggests non-IP address hostnames can happen.

When (if) I ever have time, I think I’m going to just drop SFTPClient entirely and use Erlang directly for this. One less dependency and I can’t even tell how actively maintained the former is.

3 Likes
5

Use inet — kernel v10.3.1 or the reverse to lookup hostname or ip.