All the proposed answered will work for your command line experience. But let me chime in with my personal suggestion: do not do that. Never.
Rationale: you should know what are you doing; using
rm thinking that there is a safety net (with an alias, a global change in the executable(1), other things) will make you grow confident and you will make big mistakes when the safety net for whatever reason is not present --- that can be an update, another system, or whatever.
rm command is a (complex) shell around the unlink() family of system calls --- see it as the linux kernel service that disposes of files(2). Many programs will just use the system call, completely bypassing your safety nets.
For example, the command
find . -name test2.aux -delete
will directly call unlink, as you can see by using
strace on it:
strace find . -name test2.aux -delete
unlinkat(AT_FDCWD, "test2.aux", 0) = 0
...and I bet the SFTP server will do the same. These are out of scope to the "protection" of your alias or even the
rm binary substitution.
Even a simple
> file can destroy a file outside your safety net.
The only safe is a good backup(3). Learn to do it often, and double check all your commands. Triple if running as root.
(1) don't do that, unless the replacement command is ready to accept exactly all the flags and corner conditions that
(2) much more complex than that, really.
(3) or doing that at kernel level, probably by using a filesystem that has some kind of long term memory (a versioning filesystem). I remember working with VMS in the late '80s --- the filesystem did remember all version of a file appending a ";1", ";2" etc at the name, at kernel level. Handy but a maintenance nightmare.