… or “confine untrusted users to their home directory (and give them no shell access as well)”

So you’ve setup your company secured internal Debian APT repository server by allowing apt operations only via SSH with prior public key exchange. Great.

Since creating an OpenPGP key requires some randomness (eg. move mouse, reading or writing from/to File System), the process of creating it on a remote connected host (via ssh) may take a lot of time or even get stuck.

I stumbled upon the problem of fail2ban not banning after I had moved my ssh server to non standard port (let’s say 22022).

..And that’s why I use to hide the most server signatures I can on production servers.

In the unlikely event of receiving a phone call while editing from remote an important config file with vi, you surely have experienced that PUFF! your connection to the server is stuck, your file is stuck as well, and all your editings are lost.

You already know that it is not so smart to leave SSH running on your servers on default port and accessible from every internet address (ie. no firewall restrictions, no host allow/deny).. but in real world it happens to do so since, let’s say, you have no static IP, you have no access to firewall rules and so on.

Today we’ll take a look on how to setup SSH to take advantage of the one-time passcode support provided by Google Authenticator package.

Mar 2 14:42:47 polpot sshd[1794]: Authentication refused: bad ownership or modes for file /home/muhammar/.ssh/authorized_keys

One day or the other it will happen again, and again you will forget how to fix it. Fact.