Cool idea, and as long as your connection was completed before the port number changes, you'd be good to go. Except.. * you're sharing a TOTP secret with one

Cool idea, and as long as your connection was completed before the port number changes, you'd be good to go. Except.. * you're sharing a TOTP secret with one (or more) servers (probably all of your servers), or else you'll have to track multiple TOTP codes for each server * throughly defeats legitimate automated scripts (i.e., backups, fabric, security scans, etc) that need SSH for automation * hard to fix (increased complexity) We recommend fail2ban or denyhosts at Userify[1] (plug: ssh key management), which do a pretty reliable job of blocking inbound traffic after a few (configurable) failed key attempts. They watch failed login attempts in the log file and then block the originating IP. Still, as recommended in the article, consider running your sshd on a high port (standardize across your org), since it will definitely keep your logs cleaner, perhaps the same port throughout your org. It's amazing how many script kiddies this simple trick blocks. This is also handy on a jumpbox[2]. The time cost does represent a real increase in time for scanners (depending on the scanning pattern, possibly thousands of times slower), and so actually ramps up the time cost in attacks. It's kind of like blocking spam... this trick might seem like security through obscurity, but it will dramatically slow down/eliminate automated attacks against random targets of opportunity (which is what most attacks are). Also it truly does almost completely wipe out the random attack spam from your logs, leaving room for the good stuff. Of course, the author states this TOTP trick was really a joke and a cool experiment. Don't actually do it in production. :) 1. https://userify.com https://userify.com 2. https://userify.com/docs/tips/jumpbox/ https://userify.com/docs/tips/jumpbox/