That belief is common, and incorrect.

Bear with me and I'll demonstrate why that's the case, and explain why it's a common belief.

It's complex, and most people won't invest the time to consider and understand the reasons why it's incorrect.

Many people believe it because many people believe it (a form of circular authority).
And because they over-invest in an emotionaly based opinion (which they won't test because they worry about where the results will lead - to further testing of their beliefs). It's foolish because they expend more time and energy defending their beliefs than it takes to test them, and change them when they prove wrong.
Note that those people get very angry when that emotional investment in "gut instinct" is challenged. Hence the title of this thread (it's a form of "la la la I can't hear you")

If it was correct there wouldn't be so many instances of attackers gaining access to password protected SSH.

The most common attacks (which your fail2ban logs will be full of) try a list of common passwords. That does have a low probability of success - but there are a lot of boxes allowing password SSH access. Sadly, most of those allow root logins.

fail2ban does limit attempts - by source. IPv4 only. Unless you enforce strong complex passwords dictionary attacks will succeed in a large number of cases.

Most admins do not enforce strong passwords. Key based authentication enforces the equivalent of very strong passwords - far stronger than the login buffer allows.
There's no need to guess - you can test the complexity of user passwords. Or simply enforce it by setting the default to key authentication only.

The default of encryption for a SSH connection is not relevant - it's the default. It doesn't render password access more secure than key authentication. In short it's a red herring. (there is no "providing" about it)

tl;dr your belief in the security of fail2ban is misplaced. An attacker can make unlimited attempts by just changing proxy every 3 attempts. There is a high-probability of them doing that. The more desirable access to your box, the higher the probabability.

The vast majority of unauthorised attempts you'll see in your logs are brain-dead bots looking for low-hanging fruit. Those attacks will only get smarter. Best to stay ahead of that curve.

Good security is about reducing risk as much as possible. Doing so is not about whether you "feel" it's secure, it's about whether it can be mathematically demonstrated it's safe. The point of the lead summary, and the article it references, is that it's been well demonstrated that poor passwords lead to poor security. The same big-brains that proved that also strongly recommend the banning of remote logins as root, and passwords for SSH access. There's a reason why the default SSH setting for all recent Linux and BSDs does just that - it's not to make your life hard, or the remote clients - it's to make life hard for attackers.

On the one hand as techs we want (proven) facts, on the other we are human and want to trust our intuitions, and we are lazy. It's that biased hand that is the cause of most security failures.

Sadly - that's the case with some VPS hosting providers, though I suspect you are being to optimistic about their motivations.

Most of the ones I'm familiar with do promote keybased ssh logins - e.g. it's the default in the images they provide. In the case of the low-cost VPS hosting company in which I have a proprietary interest, all the images we deploy (Ubuntu, Debian, and CentOS) default to no remote root login, no remote password authentication. Setup with a noVNC web interfaces, and sshkey management in the web management panel (so users can employ their personal ssh keys post-deployment. TFA for the web management console is available - but not the default.
We don't stop users from weakening their direct access to their VMs (it's the low-end box market sector) - nor does the (bare minimum) SLA cover "shoot-own-foot".
Where I deal with hosting providers that do high-level SLAs (e.g. obsessive) BP SSH configurations are mandatory.

Again sadly that is the case - they like to keep the bar low to allow drunk toddlers drive Ferraris as long as they enter valid credit card details.

However I was (redundantly) asking why someone who calls themselves a security professional and system administrator does not follow BP. That's distinct from why some businesses allow their clients to shoot-own-foot, that's just servicing a demand.

Could you expand on that? Do you mean - "it isn't true that if encrypted data is modified it can still be unencrypted and the information recovered"? It does sound like a self-defeating encryption scheme (see further down as to why your user case may significantly differ). If the point of encryption is to "prevent modification or access to information at any point in time" rather than "to prevent the reading of the drive at one, known, point in time".

Recovering data from a dm-encrypted disk which has damaged sectors is possible (trickier with SSDs) - even if it's LUKS (BP is to backup the headers and the key-stripe area in addition to the information). dm-crypt does block level encryption, I assuming you are referring to the discussion in context - dm-crypt.

tl;dr you are correct, it is possible to recover data from a disk if sectors have been damaged. Whether that will result in information being reconstructed depends on the the encryption schemes employed.

Which is why backups are kept (typically 3 if that information is important to retain), and damaged disks destroyed. If someone encrypts a partition and doesn't do that I can only presume that information is not something they value as much as they don't want others to know that they have it.

I "assume" that your interest in encryption is focussed on hiding information - in which case information integrity may be less important. I have no firm opinions on that subject, and the conflicts between obscurity and security aspects of being able to detect injected malware make it too complex for me to even hazard guesses.

If you use encryption and want to be able to recover information if that information has changed in any way by an unauthorised process - you're doing it wrong.

All remote logins as root should be disabled whether they require a password or TFA. AFAIK that's the default in all current release Linux and BSD distros - as is enforcing key based authentication instead of passwords. Those things won't reduce the amount of brainless brute-forcing attempts at gaining SSH access - but will reduce the likelihood of any of them succeeding to almost zero.

Changing the default port that SSH runs on will greatly reduce the traffic you'll see. Using some form of portknocking will reduce the stupid attack attempts even further.

In no way do any of those measures replace actual security. They do reduce the chances of dumb attacks succeeding. And in many instances I'm familiar with they allow service as normal. i.e. military contractors that get so many attacks per second that no one can login until the SSH port is reassigned. That still leaves logging as a problem - hundreds of port scans a day as slightly more intelligent attacks try and find the SSH port. The addition of some form of portknocking removes most of the noise from logs leaving mostly serious attack attempts - which makes monitoring and responding easier.

Reducing the number of SASL attacks is much harder. It's relatively easy to change client settings for SSH as it's rarely baked into programs. I don't have any opinions on how to deal with that, it's something we don't deal with.

Have you even read it? Or did you "think" no one else would?.

Was that the only thing you could find about portknocking in your Google rush?

It only says three "bad" things about portknocking:-

• Portknocking is bad because malware might install some form of portknocking
• portknocking is bad because it's security through obscurity - which is stupid as saying running ssh on a non-standard port is security through obscurity. i.e. obscurity is only bad if it's the only security.

• . Which is irrelevant because not installing portknocking doesn't affect in any way whether malware might install it's own portknocking.

• Knowing the knock can open your system. If it's the only system authentication you use. It shouldn't be.

There are other, more valid risks with port knocking which your "security powerslide presentation for n00bs from 2004 overlooked":-

• The knock sequence could be captured. Only if you don't enforce sequence rotation. Or better, use SPA
• It's another piece of software that could go wrong. Maybe, it's pretty well time tested and audited.
• It's hard to log. Not really. But if you find it hard you can do the same thing with iptables or authpf.

Portknocking is not a perfect solution - it's a way to lower your profile, just like using a non-standard port, which it very effectively does - which is why it's one way of meeting the mandatory requirements for ASD privileged networks. Keeping the hordes from the gates is just as important as securing the gates.
Employ it using default settings is not recommended, I'd increased the time outs (port knock fails, the port is locked out for a few minutes).

There are alternative solutions (I've already mentioned using iptables to achieve the equivalent of kernel level portknocking, and authpf) but there are also others. But you're the expert.

Allowing ssh passwords is certainly not Best Practise security. TFA is.

fail2ban? It works with IPv6 does it? (try sshguard it does). With passwords enabled, your ssh port visible and protected from bruteforce attacks only by fail2ban you must chew a shitload of bandwidth and log space. Given that, and your earlier post, you're definitely not in a position to decide whether I'm a security professional. I don't claim to be - that'd be a full-time job in itself, but the people who work for me are, as are the clients. Just about every client here is defence or directly connected, failing an audit would be to costly to rely on the sort of citations you supply to justify using well documented Bad Practice security.

That's not a citation - that's just stupid. Hint: you can't use an air gapped machine on the internet you moron.

Why do you allow password logins for SSH? Why the hell don't you have port knocking enabled for SSH?

It's a bullshit excuse on their part. See my earlier post earlier in thread for some javascript that may get around that.

The flaw you see is not where you think it is. The OP never said a password manager requires strong passwords. That would require idiot proofing - that's a whole other subject.

Using a password manager does not necessarily enforce good passwords - or prohibit the reuse of them.

Writing passwords down means you have to read them out, and type them in to use them - a practise that also does not necessarily enforce good passwords - or prohibit the reuse of them.

Writing passwords down means you have to read them out, and type them in to use them - a practise that encourages bad passwords and the reuse of them.

Using a password manager does not encourage bad passwords and the reuse of them.

The reason for the difference is in ease of use and amount of effort involved. People cut corners because they are lazy or in a hurry.
I touch type - most people don't, I make mistakes typing in complex passwords that have been written down. The more I use those passwords, and the more passwords I need to keep, the greater the incentive to practise bad security. Given that most people can't touch type - they have an even stronger incentive than me to practise poor security - the evidence from all the password list dumps and all the security tests on password usage just proves the same thing. People use dumb passwords, people reuse passwords. When they are asked why they do so they say it's because it's too hard to remember them - or to write them all down, keep control of the pieces of paper, and to type them back in each time.

The other risk with using either method for storing password is loss of the passwords. Passwords managers have to be backed up. Paper records of password needed to be backed up and secured. Password manager use passphrase protection so they are secured. (or should be - see my previous comment about idiot proofing)

That's interesting. Which browsers guess which form field takes a password please? It'd save me some time if you could tell me the function is used to guess it - but I can just dig through the documentation if you don't remember precisely.

I know how Iceweasel/Firefox finds a password form field - and it's not "guess" work.(it remembers the form field positions from when you hit the Submit button - if you have autologin enabled).
The password manager I use knows nothing of form fields - it handles password request from applications. When I'm not using Iceweasel I just copy and paste from the password manager (which I use to hold additional information relevant to each password).

A stock page login form field:-

<form id="bridgeForm" action="#" target="loginframe" autocomplete="on">
<input type="text" name="username" id="username" />
<input type="password" name="password" id="password"/>
</form>

<iframe id="loginframe" name="loginframe" src="$foobar.html"></iframe>

Refs: Firefox password debugging, the login manager

I'd have to disagree with that opinion. I would reconsider if someone showed me good reason. Typing password manually lead to password reuse and insufficiently complex password use.

Dishonest politicians that will sell their services to the highest bidder despite the fact their job requires that they serve their constituents - that'll do nicely. Or scum.

There are all sorts of people who sell their services. Some have absolutely no scruples about what they sell - or to whom. Some lobbyists are scum. And some marketers. Some prostitutes are scum?

Prostitute is a term that gets it's negative connotations from the dishonest and morally bankrupted self-righteous who like to blame people who sell their sexual services for the guilt their own desires brings them. And to perpetuate the myth that when the sex part of the brain wants something that they believe is wrong, they can act on those desires and dishonestly dodge the responsibility - because it's not the fault of the person the who owns the brain. (quick cover the table legs or grandpa will hump the table, no, grandpa needs a smack on the peepee with a birch).

In which case your passwords are toast no matter whether you typed them in by hand or they were injected by a password manager.

Do you have a citation for this common occurrence?

I can't seem to find one - though I only did a quick google and a search though the last decade of email from the Full Disclosure mailing list.

Also could you expand on how such an exploit would not be able to result in key logging that also result in a typed password being captured?

I agree with what made sense. You lost me with the "vaguely respectable OEM" bit. Could you expand on that please. I can be a bit thick.

Sound good - a bit theoretical. How does that get past a passphrase and encrypted password storage?

I'd disagree there - if I have that much access I can download what I need - if I'm too lazy to use what's already on the system.

Which browsers does not allow passphrase protection of the password manager?

I agree - that probably is the concern. I don't believe that's a legitimate concern. It definitely is a concern that it's expressed so vehemently with no supporting reasons. It may not be a troll, but it is as ugly as one.

• Consider that password managers come with a capacity for a passphrase for a reason? (those passwords are not stored in plain text)
• [citation required] Which computers use a password log? If some computers have a password log - how will keeping your passwords on scraps of paper protect you? i.e. are you talking of a computer where the authentication system is optical and you show the paper with you password on it? If so - what is that computer, it sounds interesting.
• Consider that if someone has physical access to your computer it's game over?
• Consider also that if someone has remote access to your computer they can also; elevate their privileges and negate the need for a password theoretically obtainable from a password log; they can install spyware - which will circumnavigate any password storage method (physical or electronic); that they've already breached your security - statistically those that write passwords down make other security mistakes e.g. resusing passwords or using poor passwords due to the difficulties in re-entering sufficiently complex passwords every time they need to enter them; that having just one password is often enough to start a domino effect resulting in capturing all of the important passwords e.g. if I have the password to your email account I can get many of your other passwords if you don't employ dual authentication systems and that account was used to set up an account, by requesting a password reset; that your email may contain enough personal information to be damaging in itself (I could declare your phone stolen, get the number ported, then get passwords reset the require a code that is sent to your phone; that your address book and information about senders and recipients may allow me to create other problems. (Mum, send me money - I my wallet was stolen etc)

I'm not suggesting you should never write down a password.
I'm certainly not suggesting password control on it's own is the basis of BP security - backups, risk management, and OpSec are also critical components. All of which must be employed.

Broad brush approaches to security are doomed to failure. There is no single security practise e.g. writing passwords on paper in code, or using a password safe that solves all security problems. Writing all your passwords down is definitely less secure than using a password manager. If what you are trying to secure is important enough not to trust to a password manager you should entrust is to several password managers and employ OpSec to segregate the risks across several computers - or don't take the risk.

When it comes to a choice between using passwords or cryptographic keys it's far better to use cryptographic keys.