Common Ports

Corey

@Daniel @nabo Anyone heard of FTP over TLS? - that's what everyone uses now.

@Daniel I love sftp, but don't expect end users to even know what it is.

Kuro

@Corey said: Anyone heard of FTP over TLS? - that's what everyone uses now.

FTP over TLS = FTPS...

Corey

@kuro You are right however I didn't think TLS was the only secure method, still runs on port 21 as well.

Maounique

@nabo said: Following this reasoning we could all go back and use Telnet instead of SSH.

I could always use telnet over ssh... I am known to use other strange methods of transfer such as CIFS over ssh, remote fs shared folders for virtual machines, FISH, whatever can be set up faster without installing anything I only needed once and do the job.
There are so many protocols, most of them secure by default, plenty to choose from. If that isnt enough, we can start mixing and remixing.
M

marrco

@raindog308 said: I'm curious - this is only necessary if you're running a DNS server, right?

correct

[@raindog308 said] I didn't think that you had to give shell access to give sftp access. I seem to recall you could set the user's shell to /bin/false and they could still sftp?

also correct

[@sleddog said] sftp and scp are "over-ssh" and require a valid user shell like /bin/sh, /bin/bash, etc. Or at least that's the way it was the last time I checked....

using Subsystem sftp internal-sftp with --shell /bin/false works fine too. At least if you're using standard ssh. I'm not sure if the config works with dropbear too.

nabo

@Corey said: Anyone heard of FTP over TLS? - that's what everyone uses now.

So that should be fine then: http://packages.debian.org/en/squeeze/telnet-ssl But I'm still rather sticking to OpenSSH and SCP.

@Maounique said: There are so many protocols, most of them secure by default, plenty to choose from. If that isnt enough, we can start mixing and remixing.

You can mix protocols as you like. However, ports indicate a specific protocol. If you are using a mixed protocol ftp+ssl over the standard ftp-port and are using another network (hotel, train, airport) they might likely not allow that transactions. That's also why you will put OpenVPN from 1194 to 443 as they normally allow HTTPS but do not want people to use a secure VPN. That's the only drawback. If you're on your own network you can of course use whatever you like.

jcaleb

counter-intuitive is port blocking by default.

Maounique

Usually I mix protocols because not worth the time and space to install something for a one off operation.
I dont use other ppl's networks even if the hotel/bus/whatever provides one for free as long as I can use my CDMA/GSM links at reasonable speeds (99% of the cases). If it is required (i am some place where I have to transfer from the local network something) and ports are blocked at the source, destination or both, I pipe it through some machine of mine. Can change SSH listening port on the fly as required, I think most ppl use this kind of setup for such puposes.
Port blocking doesnt change my protocol prefference, only available software at target and source does.
M

nabo

@Maounique said: If it is required (i am some place where I have to transfer from the local network something) and ports are blocked at the source, destination or both, I pipe it through some machine of mine

And this is the problem we're talking about. That won't be possible if the ports are blocked by the provider.

@Maounique said: Port blocking doesnt change my protocol prefference, only available software at target and source does.

Port blocking will most likely effect the protocol preference as some public access point might block specific ports and disallow ssl on any standard port. (eg. a hotel is blocking all ports except port 80. You won't be able to put ssh on 443 as it is blocked. Putting ssh on 80 will also not work as those standard routers for public wlans have packet inspection that will disallow ssl on the standard port. This set-up is quite common with hotels, airports, trains, libraries, universities etc. Even my home-router has packet inspection (named traffic shaping)).