I have a hardware firewall which currently doesn't forward any ports "inside". Will the following work?

1) Add new user "aqdfh" on Debian computer, with random string password.

2) Decide some particular nonstandard port, like 18267.

3) Set my hardware router to port forward 18267 to the Debian computer.

4) Install openssh-server on the Debian computer.

5) Configure openssh-server to only allow login of user "aqdfh".

Is that good enough?

Obviously, I'm going to use different names/numbers than "aqdfh" and "18267".

Once "in", I'm aware that the default ssh shell login is capable of all sorts of things--which I want to be able to do. I just want one centralized "front door" that's secured--a single forwarded port which admits exactly one user with a difficult to guess password.

Thanks!

wouldn't recommend different port numbers unless you have a really good reason to. obscurity is not security. same goes for a pseudo-random username. dictonary attacks use standard names... root, admin, webmaster, alice, bob, carol, dave... additionally you should look towards private key authentication instead of passwords. if ssh won't accept passwords at all, a password can *never* be guessed.

I'd recommend using an identity key on the client, adding the public ssh key to ~/.ssh/authorized_keys

Another package I've found useful is Fail2Ban, and I set the limit of failed logins at 1 before the inbound IP is banned by iptables.

I disable password authentication in sshd_config once I have my .ssh/authorized_keys appended with my different clients.

For a linux ssh in, sftp .ssh/id_rsa.pub from the system you will be coming from to ~/ on your inside/protected server, then cat id_rsa.pub >> .ssh/authorized keys

For SecureCRT, generate a key, sftp Identity.pub to your home directory, then cat Identity.pub >> .ssh/authorized_keys

If you don't know where you will be coming from, download putty and put puttyssh with your key on a jump drive, doing the same to add the public key to the authorized_hosts on the server you are going to. Then you can plug the jump drive into whatever system you are at, run putty from there, and you are good to go. Be sure to use the jump drive tools to protect it, and don't lose it or leave it plugged into a public system.

Once Password authentication is turned off, fail2ban takes care of quite a few people trying to guess accounts.

There's nothing wrong with changing to a non-standard port, as long as there are other security methods being used. Even if he was using a default install (non-keybased authentication), changing the port won't put him in any danger of being exploited...one port is as good as another. Now, if he's disillusioned into thinking that changing the port will make his server more hardened, he's wrong, but not necessarily in danger.

It doesn't hurt. I've read enough reports that there are lots of break-in attempts on the standard ssh port but far fewer on a random port.

Huh? A random string userid isn't going to be in a dictionary. Doesn't this argue in favor of a random string userid?

The private key can still be guessed--which is exactly as easy as guessing a random string password of equivalent bit-length. For example, 128bits is roughly equivalent to 22 alphanumeric characters.

For various reasons, I'd rather have a long and complex password rather than a thumbdrive. Naturally, I'll also keep a note of the public key of my Debian machine.

Still, I'll use private key authentication for ssh on my main server, at some point. I eventually intend to experiment with rsync to backup my mom's photos and scans (she produces prodigious amounts of artwork, but she simply isn't computer savvy enough to deal with a backup regime).

That's something I'll add on at some point; obviously since I'm going to be manually typing in a long password I'll set the number of failed logins to something a bit higher.

I figure that a bot-attack would tend to come from a zillion different IP addresses, but even so Fail2Ban can't hurt.

I feel that random port can increase security in some way - it never prevents any serious attack, or makes it harder, but instead there are less very dumb attacks and so logs are smaller and easier to read - and there is a chance the attack will be noticed at all.

Funny...coincidentally someone just posted this: LXer: Security Through Obscurity? It's Not All Bad

well i said i "wouldn't recommend" not "will hunt you down with an axe"... there's no harm in it, but if i were to write the book on the subject, i wouldn't make that suggestion, that's all. somethign like the use of fail2ban is much more intelligent.

Sorry, I understood "wouldn't recommend" as "it will be a bit worse". So I decided to express my opinion why it will be a bit better. But surely, fail2ban (keeping in mind botnet sizes nowadays) and even a port scanning detection tool (which will benefit a lot from a non-default port, unless adversary has control of a box next to some box in your usual routing path - and so can sniff traffic, which is not often) will give more. But it adds up, anyway. It'll give just 14 more random bits of safety, which are easy to use in a "3 failures give 10 seconds of timeout" manner. Just as with fail2ban and random login in addition to random password (as login failures are stored in logs cleartext, you can easily distinguish someone knowing username, but misspelling it from someone trying to guess - even a program can).