Have FTP running-Now I want to switch to SFTP. How?

You mostly have exactly the right idea. Forward port 22 to your Mac.

You also need to enable System Preferences -> Sharing -> Remote Login. That will enable the sshd daemon.

NOTE: You might want to consider some enhancements. Instead of forwarding port 22, tell the router to forward a high number port on the Internet into port 22. Then use *sftp -oPort=12345*, where 12345 is the high number port you select.

You might consider using *scp -P12345* which is more flexible and very scriptable vs sftp. Once I learned about scp I stopped using ftp/sftp unless I had no other choice.

You could look at using private/public keys and disable normal logins via /etc/sshd_config -> *UseLogin no* (this is a very advanced option).

OK the suggestions were just things to think about for the future. You can evolve into them as you feel the need.

I'm not that advanced in my knowledge of scp, never mind appreciating why scp might be a better option than SFTP.

scp is the ssh cp command. It works very similar to regular Unix cp command, except over a secure ssh connection (just like sftp).

scp /path/to/file username@remote.host.addr:/where/to/put/it
scp username@remote.host.addr:/path/to/file /where/to/put/it
scp -r /directory/tree/to/copy user@remote.host:/where/to/put/it
scp file1 file2 file3 file4 user@remote.host:/where/to/put/them
scp *.txt user@host.addr:/where/to/put/them
scp user@remote.host:"/somewhere/*.dmg" /where/to/put/them

why use an alternate, higher port number? Is it to throw off any attackers trying to hit my Mac on port 22?

Yes. It does not so much provide additional security, but it does limit the number of Bots knocking on your door trying to break-in. If you look at the "sudo more /var/log/secure.log" and see how many Bots are trying to break into port 22, that is after you forward internet port 22 to port 22 on your Mac. Using a high numbered port just stops your Mac wasting time listening to these break-in attempts.

ssh-keygen is how you create private/public keys. You create the keys on the system you are sitting in front of. You copy the $HOME/.ssh/id_rsa.pub (or id_dsa.pub) file to the remote system you wish to login to. You append the copied id_rsa.pub (or id_dsa.pub) file's contents into the remote user account's .ssh/authorized_keys file. That allows the remote system to know who you are and because your .pub key could have only been put in the remote account's .ssh/authorized_keys file, it knows you are who you say you are and that the local user has agreed to allow you to use the account via ssh/scp/sftp.

Over at work, I keep many files with greek characters in the file/path name. Is that acceptable? or will the transfer (SFTP or SCP) break down and report back an unintelligible error code?

I do not think so. I'm assuming it was not a problem when you were using ftp, so I do not see any reason that it would not work for scp or sftp. But then again, this is easy to check out.

As the link points out you could use something like Fugu which will give you a GUI interface to transfer files.

There is also CyberDuck that a lot of people like.

I am not sure I understand exactly how I go about doing this. I looked in Terminal in / and in ~/ and couldn't find .ssh.

ssh-keygen -t rsa # keep hitting Return until it stops asking questions.
scp $HOME/.ssh/id_rsa.pub username@remote.system.addr:
ssh username@remote.system.addr
password: **********
mkdir .ssh
chmod go-rw .ssh
cat id_rsa.pub >>.ssh/authorized_keys2
chmod go-w .ssh/authorized_keys2
logout # logout of username@remote.system.addr

Now you should be able to ssh, sftp and scp to username@remote.system.addr without needing a password.

NOTE: The protections of the .ssh directory is important, so do not skip the chmod commands.

If you are going to use Fugu, then Fugu has memorized your password and is just re-issuing your password as needed. No public/private keys needed. I'm guessing that Fugu is using your Keychain to store the passwords.

I'm more into using the command line for my ssh/scp/sftp usage, which means I'm the one that needs to memorize my passwords. Public/private keys frees me from that task.

I also have shell scripts that run without my interaction, so using public/private keys eliminates my having to hang around to enter passwords.

So anyway, if you are happy with what you have, just ignore my babbling about public/private keys. I forget that not everyone lives in the Terminal all day long.

Are you saying the public/private keys are only taking away the pain of having to enter passwords each time one logs in? I thought that these keys provide unbreachable security that simple SFTP does not. No?

ssh (sftp, scp) provides a secure encrypted end-to-end connection, no matter how you establish it.

One of the big differences between using your password and public/private keys is that the keys are 512 bits (or 1204 bits, or longer). You would need a 64 character password to equal 512bits. Most people that have to enter passwords on a regular basis tend create passwords that are easy to remember and type, not long and difficult to guess (your mileage may vary).

So using keys to login means you can choose a difficult password, or even configure the ssh daemon to ONLY accept keys, and thus make it more difficult for someone to break into the remote system.

If you write shell scripts to automate things (like I do), using keys means I can make secure connections without needing to enter passwords. This allows some of the scripts to run over night or as the result of some event that occurs when I'm not around.

On the other hand, I have to make sure I maintain control over my keys, especially my private key. If someone gets that key, they can pretend to be me.