I noticed recently as I am looking to setup an FTP server for a client (using the Surfer app if I can) that in the Access Control tab, the server name they'd have to connect to is the
my.<domain>.<tld>, which is personally something I don't really want clients seeing (which was also why I had requested the mail server being accessible from another subdomain which works now in the recent versions).
I'd like to request that there be a way to change the server they access to the domain of the client. So something like
my.cloudron.com(for example). Even if it was still mandated to be something like
sftpas the subdomain if it makes it easier to code, it'd at least remove the weird-sounding
mysubdomain which makes no logical sense to other users.
There may be a technical reason that it's not done that way, not too sure, but wanted to at least request it if that was possible. I assume there can be redirects created for the SFTP functionality if implemented, right?
Good idea. It's actually quite simple to do because SFTP does not require certs. It's on top of SSH. You can just put a A record to the server and it should work.
So, essentially, setting SFTP server name simply sets up DNS record and also changes the display of SFTP server name in various places.
@girish I get my A Record and my CNAME mixed up often but as I understand they are the same thing, with A pointing to an IP and CNAME pointing to an A record pointing to an IP? So, CNAME wouldn't need changing if the server was later moved to another IP?
As I say, not tested this as having a crazy day but would be interested to know the results, and actually, seems a good enough idea to make it a core platform thing to standardise subdomain usage and make documentation match for a little clarity. I'm a fan of self-explanatory naming wherever possible.
@marcusquinn I think you have it right about the DNS records. From a user point of view (i.e someone who manually has to setup DNS records), CNAME will work better. Since when you move the server, you don't have to adjust the DNS. From automation point of view, they are similar but for Cloudron A is better simply because that's the only DNS record we have automated and have code for In Cloudron case, since it's all automated, the user won't notice a difference even when moving across servers.
CNAME might work - I can try that, good suggestion - a little unsure that'll work for me as I don't have any wildcard certs (they're per hostname) which would then throw a mismatch, however if you're saying SFTP doesn't require certs then I suppose that may be a moot point and should work. I'll try this later today.
I had a moment to test it out so just tried and yes the CNAME workaround seems to work well.
Thank you, guys! Didn't expect that to work because of SSL but didn't realize they didn't really require certs on those connections. Yet somehow it's still the more secure connection type, haha. I think I'm going to have to do a little learning on that one later.
I think it'd still be nice to be able to configure the SFTP server name from within Cloudron, but this CNAME workaround will do the trick for now. Thanks again.
Actually I just ran some more tests and found out that a CNAME record isn't even needed. Since my DNS records for the domains I manage are wildcard (i.e. no A records for individual services, but is just the * and @ DNS records to the IP address), it seems I can actually throw in anything I want. So I tested for example whatever.<domain>.ca and still put in the username and password and it was accepted by the SFTP server.
This is interesting as I expected it'd only respond to my.<domain>.<tld> but I suppose that isn't the correct understanding because if it were a CNAME record all it'd be doing anyways is looking up the associated A record and hitting the IP.
I think this works because the lack of certs needed for the handshake. This is strange to me though... am I understanding the above correctly?
Yet somehow it's still the more secure connection type, haha
Its security is based on the hash that it asks you to check the first time you connect to a new server. You now, the prompt that everybody confirms without even reading ^^
the prompt that everybody confirms without even reading
haha, so true. Yeah I got a pop-up that was like "This is a new key" or something and just accepted it. Basically the same kind of message that happens with SSH. I just have certificate-based SSH though where it needs my key to even connect (i.e. you couldn't connect to my server over SSH without it), so I was surprised I didn't need that on my SFTP connection, thought I'd maybe need something similar. But I guess this makes sense then the more I think about it. Just caught me off guard. haha.