Bug Exposes OpenSSH Servers To Brute-Force Password Guessing Attacks 157
itwbennett writes: OpenSSH servers with keyboard-interactive authentication enabled, which is the default setting on many systems, including FreeBSD ones, can be tricked to allow many authentication retries over a single connection, according to a security researcher who uses the online alias Kingcope, who disclosed the issue on his blog last week. According to a discussion on Reddit, setting PasswordAuthentication to 'no' in the OpenSSH configuration and using public-key authentication does not prevent this attack, because keyboard-interactive authentication is a different subsystem that also relies on passwords.
Dictionary? (Score:1)
two minutes could allow for thousands of retries, which could be enough to guess common or weak passwords using dictionary-based attacks.
I really donâ(TM)t think dictionary attacks are going to work for any serious servers . Just take this random password for example O0k9uehry&6$83
Re:Dictionary? (Score:5, Informative)
Dictonary doesn't really mean English Dictonary, but a sorted list of common passwords and variations. Then just cycling through all of the entries. https://en.wikipedia.org/wiki/... [wikipedia.org]. The dictonary may well be based of stats and possible characters not used in english grammer.
Re: (Score:2)
Re: (Score:1)
You shift with your left hand and are right handed. Not really all that random. Decent CPUs can use deterministic algorithms to guess probable outcomes and create a dictionary based attack that would, eventually, find your password quicker than you might think. Not that I am an expert or anything but I have been cramming a bunch of articles on the subject into my head in an effort to pass time.
Re: Dictionary? (Score:2)
Not so random. Found a FreePbX phone system that requires ssh for phone traffic to pass to the VoIP provider. VoIP provider calls once a month saying a quarter of their total bandwidth comes from one number on the clients phone system and changes the private key used to authenticate. VoIP doesn't require ssh, so after figuring out all calls are being routed to a man in the middle, ssh gets disabled and phone quality improves, VoIP provider is happy. If the hackers only knew how to maintain good call quality
Re: (Score:1)
I have a friend who likes to opine that his connection to his ISP has been much more stable since the NSA started getting involved. I'd point out that it may be due to technical improvements but it is more amusing to hear him go off on his rant. He jokes about giving control of the whole infrastructure to them. At least, I hope he is joking.
Re:Dictionary? (Score:5, Funny)
The first entry in my dictionary is now 'O0k9uehry&6$83'. Check and mate.
Re: (Score:3)
Re: (Score:1)
You have no idea how many people I have told that there is no such word as gullible who have then gone on to look it up in a dictionary. It is sad and glorious all at the same time. I had a dictionary in my office and used it way too frequently for this joke. I used it a number of times while interviewing candidates. It was not a deal breaker but it was close. "No, really. It is not a word. Look it up..." It was far too easy to get the word gullible into a conversation. If you get bored and have a dictionar
Re: (Score:2)
You jest, but that's the exact purpose of many "How strong is your password?" websites.
They get a nice dictionnary of real-life uncommon passwords.
On a related note :
https://xkcd.com/792/ [xkcd.com]
Re: (Score:1)
[clippy]It looks like you're trying to save your file and quit using vim![/clippy]
Re: (Score:1)
Is that perl code?
Re: (Score:2)
Sent from your iPhone?
Re: (Score:2)
A bit ov
Re: (Score:2)
Re: (Score:2)
no.
Dictionary or brute-force has nothing to do with the kind of attack (against a hash or against a live service)
maybe you're mixing it up with rainbowtables.
Re: (Score:2)
Re: (Score:2)
no, they are a way to optimize a hashbreaking attack. A Dictionary attack against a webservice cannot be done with rainbowtables.
Re: (Score:2)
A repetitive attack against a service is so easy to prevent it's not even worth talking about.
Re: (Score:2)
Dictionary Attacks are just a class of attacks, which use dictionaries instead of brute-force (a-z aa-z ba-z, ...).
So they can be either online or offline.
Re: (Score:2)
Re: (Score:2)
My question is, how does this apply to DenyHosts [sourceforge.net]?
My guess would be that I'm still safe... try root at all, instant ban. Try an invalid account, grace one time (even I make a typo sometimes). Try a valid account more than 3 times? Banned. Unless, of course, this attack somehow bypasses the mechanism DenyHosts uses to detect those invalid logins... but I don't know that I saw enough information in the article to answer that question.
Re: (Score:3)
Denyhosts depends on login failures being logged to /var/log/auth (or similar) and it only checks those logs periodically (maybe once a minute?) The article indicates this bug allows a large number of attempts per *connection*. Does ssh even log the failure if the connection is not closed? I don't know the answer to that. In any case, it can make a lot of attempts in the interval between checks of the log.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
actually had this on my list today (Score:5, Interesting)
The unofficial official FreeBSD security posture: two layers, where the outer layer has a singular purpose in life.
Protecting sshd using spiped [daemonology.net]
Re: actually had this on my list today (Score:1)
Try port knocking
Re: actually had this on my list today (Score:5, Informative)
YES. Port knocking solved this years ago. For those unfamiliar with the concept, the idea is simple enough: my computer doesn't even let you try to log in unless you first hit a specific combination of ports first. For example, your IP address gets no response to an attempt to connect to SSH unless you first try to open ports 2234, 5039, 16, 38 and 27 in that order. (You don't get a response on those either, but my computer records those attempts and when you do hit them in that order, it opens up the real SSH port to your IP address for a connection attempt.) Add on an extra layer of security by having some ports that cause an automatic ban, so hitting port 2232 or port 2235 would mean your computer wouldn't get any access even if you otherwise hit all the required ports in the right order.
The best part is that you don't need any special software to set this up. Iptables is already built in and a bash script is sufficient to process the logs created by Iptables and unblock or ban when appropriate. The client just needs to get to a web page with links to the server and ports in the right order, so nothing more sophisticated than a browser is necessary. The worst part is that your firewall will block non-standard outbound traffic if it's sophisticated enough and if you're in a corporate environment, making changes to it may not even be an option.
I don't like alternate possible suggestions either. If you put up a web page to first authenticate people before opening SSH for connections, then the web server becomes the week point and I think SSH has a better track record of being secure than any web server I can think of. If you put up a VPN to authenticate people before allowing SSH attempts, then the VPN becomes the week point, and again, I don't know if VPNs are any more likely to be secure than SSH itself.
Any time you put two layers of authentication in front of allowing access, it should be more secure than having one alone, but with zero day exploits happening on pretty much everything, I'm inclined to think the first layer should be the one most likely to be immune. If that's SSH, and I think there is a reasonable argument SSH has a better track record than most any other authentication method, then using any other piece of software that people can connect to in front of it makes the potential for a breach higher.
I'm actually in favor of layered security and I use fail2ban (as others have suggested) and I put together a script to automatically ban "evil ips" when they repeatedly try unsuccessfully to connect to my machines, but really I feel that's more for my benefit of having less logs of automated attempts than being a serious deterrent to any half brained targeted hack attempt.
Re: actually had this on my list today (Score:4, Interesting)
So essentially an elaborate method of sending a clear text sequence of numbers (port numbers) to the server to allow access.
Re: (Score:2)
So essentially an elaborate method of sending a clear text sequence of numbers (port numbers) to the server to allow access.
I wouldn't even call it elaborate. But it is different, so it is distinct extra security layer which offers unique protection. Cracking it basically requires that attacker can sniff low level traffic between client and server, and knows to watch for port knocking sequences. The important property of port knocking is, attacker without privileged knowledge doesn't know if server expects port knocking sequence, and attacker doesn't know if they failed critically and got that IP blocked. So it effectively block
Re: (Score:2)
I simply disable all SSH access to all hosts except one.
I call that a jump box.
I then disabled all authentication except public key (I already had ChallengeResponseAuthentication and KbdInteractiveAuthentication set to no).
I enabled key, TCP and X11 forwarding.
I just use the jump box to get to all my internal hosts using public key authentication with password authentication as a fall-back.
In a pinch it can even act as a "poor man's VPN" by forwarding TCP to internal hosts.
Mostly, I use it in conjunction wi
Re:actually had this on my list today (Score:4, Interesting)
The unofficial official FreeBSD security posture: two layers, where the outer layer has a singular purpose in life.
Protecting sshd using spiped [daemonology.net]
Yeah. I used to have my SSH available on my public IP but finally got sick of getting emailed security loss that were a mile long with login attempts from Asian and Arabian countries I'd never been to. It was convenient being able to SCP files and everything without a hassle, but it wasn't worth the security risk.
Now, I just have our private access only and have to connect to my OpenVPN server first. Haven't gotten a single failed login attempt notification since. It's just really lame that it's come to this. You simply cannot have more than a bare minimum of ports open to the public or they WILL try to hack you.
Re: (Score:1)
Non standard port in the emphemeral range, with no password authentication, key only. Saw 1 NMAP scan attempt on that port in a total of 6 months use, still check the logs daily.
With key based authentication, is there any real risk to leaving a port unfiltered? Disregarding the paranoia that a rootkit will quickly leave you fucked.
Re: (Score:1)
Unfiltered ports leads to better OS fingerprinting which leads to more specific attacks.
Re: (Score:1)
So the only difference is that you sent yourself openssh failed login logs but not openvpn failed login logs?
Your openvpn is still on public IP. What does this have to do with security?
First, the attacker has to get through to SSH (Score:2)
As many attempts withing 2 minutes (Score:3)
However, OpenSSH servers with keyboard-interactive authentication enabled, which is the default setting on many systems, including FreeBSD ones, can be tricked to allow many authentication retries over a single connection, according to the researcher. “With this vulnerability an attacker is able to request as many password prompts limited by the ‘login grace time’ setting, that is set to two minutes by default,” Kincope said.
It is bad, but not so bad. At least the connection resets after 2 minutes by default.
Comment removed (Score:3)
Re: (Score:2)
Any half-way competent system administrator who has an SSH server open to the internet should well and truly have some method of brute force attack prevention already. SSH attracts hordes of bots moreso than a Windows XP machine attracted the Blaster worm in it's heyday.
It would have actually been interesting to propose a race. What would attempt to be breached first, a WIndows machine vulnerable to blaster, or an Linux machine with an SSH server that has login root and password password.
Re: (Score:2)
I like fail2ban. I started installing it on servers when I discovered a firewall getting so many SSH connections it couldn't hold anymore.
The only reason I found that was happening is my Nagios instance threw up a flag upon no longer being able to SSH into the firewall.
If you monitor for stability you will see security issues. If you code for security you will see stability. They tend to go hand in hand.
fail2ban works for this? sure about that? (Score:2)
you sure about that?
I mean, the point of the entire bug(more like a feature tbh) is that it gets around conventional checks for multiple failures(which is why you wouldn't be able to do this much of bruteforcing on normal connection because you would be banned).
the original blog post is unclear about that.
Re: (Score:2)
Old DenyHosts work too!
Re: (Score:2)
Re: (Score:1)
I have no IPv6 - access and thus I have zero experience with that stuff.
and yet you throw out networking advice as if you knew what you are talking about
Re: (Score:1)
Her... It is right in their username. I even clicked their link in their signature and confirmed that they do appear to be female. That would be the "girlie" part of "gaygirlie" that is their moniker.
Re: (Score:2)
And when I'm in a really bad mood and your source IP comes from HINET, I'll just block your entire subnet. Permanently. Because if there are actually any honest people on HINET, they're just lonely little fish in the shark tank.
I outright block smtp connections from them and any hosts that match these. There is nothing coming from hinet worth accepting.
hinet-ip.hinet.net
.dynamic.hinet.net
.dynamic-ip.hinet.net
Re: (Score:1)
Because you can't just block a /64? Right?
Re: (Score:2)
You can change the action that fail2ban performs and make it block a range of IP addresses. I already block /24 IPv4 netblocks after seeing attacks from close ranges of addresses.
Re: (Score:2)
ListenAddress 0.0.0.0
Few Hackers Smart Enough to Take Advantage of it (Score:4, Interesting)
The majority of attempts are done on root. It is not unusual to have thousands of attempts in 24 hours. They'll never get in that way; not because the root password is difficult (it is difficult enough that a few thousand guesses would not likely be sufficient) but rather because like any sane person I don't allow root to log in through ssh.
Occasionally I see "white pages" attempts, going through long lists of common names. They make usually no more than 3 attempts at each name (I presume one attempt is blank, haven't bothered to see what the others are). The problem with that strategy is that they pretty well never hit a valid name. Being as my ssh server won't respond any differently to a valid name than to an invalid one, they never get any useful feedback on that endeavor.
Now, important systems (say at large corporations) are probably targeted by more dedicated attempts than what gets directed at my server. I mostly see script kiddies from China who give up after 24-36 hours. These kids certainly won't benefit from this bug.
That said, I will still patch my server.
Re: (Score:3)
I see this all the time too. PubKey authentication only, Fail2Ban and no root logins help to keep the log clutter to a minimum.
After finally weening myself off of using the root account locally I now just lock root completely. "sudo passwd -l root". Doesn't disable root so "sudo su -" still works but you can't login directly as root when the password is locked.
Although there is less traffic in the logs now I still get some entries before F2B kicks in and I find some of the non-root attempts very amusing...
Re: (Score:2)
That's a good question and I honestly can't say it's come up. My guess is that if you are in single user mode then the lock is ignored. But that is just a guess, I'll have to experiment with sometime.
Re: (Score:2)
What you describe are automated attacks, yes the majority are from China... they are only looking for low hanging fruit which is why the attempts don't look very clever, but they don't have to be. They don't care about your server, they care about getting as many servers as easily as possible, and you do that by automation and wide spread attacks.
It's still good to stop these attempts from littering your logs and taking up resources so you can spot directed attacks by an actual person, not using default por
Re: (Score:2)
They don't care about your server, they care about getting as many servers as easily as possible, and you do that by automation and wide spread attacks.
I should have been more verbose, I am fully aware that they don't care about my server specifically. Indeed they would almost certainly try a lot harder if they did.
Don't be so cocky with your massive log of failed access attempts, everyone gets those
I am aware that it is quite common. I was not intending to come across as "cocky", I'm not sure why you came to that conclusion.
you should consider what happens when something with a brain tries to hack your server with a modicum of effort.
If someone wants badly enough to get in, they will get in. Indeed as you said most of the Chinese attempts are just looking for highly vulnerable systems that they can easily get in to. I have my system open in t
Re: (Score:2)
Have you considered a rate limiting system like fail2ban which blocks servers for a set time after a set number of failed logins?
Most of the time I see IP addresses come in, try root with a few password combinations and disappear back into the ether. But a few times I've seen bots attempt full dictionary attacks filling up my log files with useless SSH login errors. Fail2ban stopped that in its tracks and with a 15minute penalty for 3 login attempts I now see the number of logins reduced to the hundreds rat
Re: (Score:2)
Your data correlates with mine and I've been logging for years [I have 450,000 log entries at present and I have a non-published IP address, not tied to any DNS, so my traffic will be lower--just so I can login to my desktop from Starbuck's using my laptop]. More on this logger and my security config below.
Apparently, the keyboard interactive problem has been known [by Redhat] since at least July 2013, see https://access.redhat.com/solu... [redhat.com] and it sets ChallengeResponseAuthentication to "no" to specifically
Re: (Score:2)
Your data correlates with mine and I've been logging for years [I have 450,000 log entries at present and I have a non-published IP address, not tied to any DNS, so my traffic will be lower--just so I can login to my desktop from Starbuck's using my laptop].
I am comfortable stating that the script kiddies are most likely attacking my system by IP address alone, not by its domain name. I say this because I have yet to see a single one of their IP addresses show up in both my system and httpd logs. Of course, they may have seen the website and then attacked it by name from another system but that seems like more effort than it would be worth. I have also searched for their IP addresses before and found other blog entries from other people online - generally
Re: (Score:2)
Once again, we seem to be in complete agreement. I did the enhanced logging for amusement [That's why the logger never did a fail2ban equivalent]. Sometimes, I do "tail -f logfile" to watch the fun in realtime.
For a while, I've been considering paring down and packaging up my scripting environment for this and publishing it on github. The sshd patch and setup/modification of the config files [including changing the selinux attributes :-(] is all done by a perl script (as is the logger).
The only wrinkle i
Re: (Score:2)
Once again, we seem to be in complete agreement. I did the enhanced logging for amusement [That's why the logger never did a fail2ban equivalent]. Sometimes, I do "tail -f logfile" to watch the fun in realtime.
It is nice to see someone not calling me crazy over doing such things. I wouldn't do this in a production environment, and suspect you likely wouldn't either. Sometimes free entertainment is a funny thing in what some people find entertaining, I guess :)
I was considering adding automatic whois lookup, with abuse@blah.com scraping, and then send the applicable part of the logs automatically [with a copy to the FBI :-) :-) :-)]
Have you had any luck getting responses from Chinese ISPs when you report abuse? I used to do it fairly regularly but for years now it seems like I might as well just send the report to /dev/null instead. While the lack of response doesn't mean they ar
Re: (Score:2)
I never did post anything back to an ISP. I assumed the result would be what you saw in practice. Also, if it were "state sponsored", they would ignore it. If it were somebody trying to find a portal that would circumvent the "Great Firewall of China" [which I'd be in favor of], posting back might just "out" them [to the government].
I just got sshd patched/reinstalled. I just reverified that it disallows login/pw from public IP but allows login from local LAN on accounts that have no pubkey. So, I open
Password guessing attacks are a fact of life, so (Score:2)
Re-using the existing connection is of course useful to fend off the traditional killing techniques for rapid-fire password guessers (such as http://home.nuug.no/~peter/pf/... [home.nuug.no] and similar), but you still have to come up with the set of bytes that will let you authenticate. Which leads to the other thing --
The clowns I have been writing about ("The Hail Mary Cloud" -- http://bsdly.bl [blogspot.ca]
Account Lockout and Intrusion Detection (Score:1)
Every computer exposed to the internet should have an account lockout policy in place. For example, pam_tally can limit speed between password attempts and also lock the account on X number of bad passwords. Furthermore, some sort of intrusion detection should be in place. Fail2Ban, for example, is an exceptional added layer of security which will ban the IP upon failed attempts.
In short, "yawn" over this security bulletin. This is non-news.
Re: (Score:3)
Locking accounts? Wow, that could never be used for a denial of service attack.
Re: (Score:2)
Locking genuine accounts because of automated spam against them? That's just not going to wash for any public service that contains common usernames, i.e. every school on the planet with a user John Smith.
You can't just lock every user out because of a handful of random user checks. That's the point of passwords, if you don't have the password, you can't get in.
Reject early, yes.
Reject with limits, yes.
Reject multiple attempts from the same IP, yes.
But this is a BYPASS of such mechanisms. On one connecti
Re: (Score:1)
I was assuming, perhaps erroneously, that they meant to say that they blocked the IP address(es) of the attacking parties. That still, of course, has problems but they are lesser problems and fewer problems than locking the account itself out. I can not imagine that locking the account out would be a good idea really.
denyhosts (Score:1)
Re: (Score:2)
Fail2ban has worked well for me over the years. It's pretty easy to set up given it's sane, sensible defaults. Not comparing it to denyhosts, haven't use that. Just noting an alternative...
www.fail2ban.org
Linux not affected? (Score:3, Informative)
It's appears to be a non-issue for CentOS 6/7 as ChallengeResponseAuthentication is set to "no" by default, which also sets KbdInteractiveAuthentication to "no" (the suggested work-around).
Complete non-issue with reasonable passwords (Score:2)
Limited use of connections, tar-pitting, etc. are only for really bad passwords and provide only limited protection even there. Anybody that understands security already has passwords that are not guessable in practice.
I really don't give a shit.. (Score:1)
The faster they can blow through their dictionary the better. If 24 of these Advanced Persistent Chinese crackers get born every day going after me, and they can blow through their dict. in an hour I'll have 24 of them to deal with a day. If I make them spend 2 years doing it, then I'll have to deal with over 9000 knocking on my door.
But not DragonFly (Score:2)
Because DragonFly defaults to public key only operation. No passworded access is allowed unless the user explicitly enables it, and we've recommended against enabling it for years now.
-Matt
Fwknop is a potential 2nd layer to protect sshd (Score:1)
Port knocking is one way to avoid being a target of ssh attacks, but legacy port knocking has its own shortcomings. SPA (Single Packet Auth) has solved most of those problems. Fwknop is the only maintained spa implamentation that I know of. More info at https://www.cipherdyne.org/fwk... [cipherdyne.org]
undo mod please ignore (Score:1)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
OpenSSL's problems aren't from Microsoft. Honestly, Microsoft isn't nearly as bad as they used to be, security wise. It's a relief, really - I've been UNIX only for almost two decades, but I still have to maintain a few Windows machines for family members.
There's an excellent talk [youtube.com] by one of the LibreSSL developers at BSDCan 2014 that explains a lot of what OpenSSL's problem was (and still is, although there's been a lot of work done since to improve matters). Basically, it boils down to poor project mana
Re: (Score:1)
Honestly, Microsoft isn't nearly as bad as they used to be, security wise.
And here we are with Font vulnerabilities [microsoft.com]
This is broken so badly, that no popular (modern) browser can protect you against it. (Excepting, of course, console/text-based browsers, if any on Windows.)
Re: (Score:1)
THis flaw isn't even a mild flaw considering nobody worth a squirt of piss would ever rely on passwords to secure any SSH - be that from microsoft, libre or open.
The majority of servers running SSH rely solely on username and password authentication.
A strong, unique password known only to a single user is the most secure protection available.
Certificates don't add shit on top of that in terms of actual security.
Re:LibreSSL (MOO!) (Score:2)
THis flaw isn't even a mild flaw considering nobody worth a squirt of piss would ever rely on passwords to secure any SSH - be that from microsoft, libre or open.
The majority of servers running SSH rely solely on username and password authentication.
Do you have an authoritative citation for that? I'm surprised that so many have deliberately changed
the sshd policy.
A strong, unique password known only to a single user is the most secure protection available.
Do you have an authoritative citation for that?
And no, MOO is not authoritative.
Certificates don't add shit on top of that in terms of actual security.
Is a certificate what a cow calls encryption? Why would humans put "a certificate" "on top of" passwords?
The solution (if you don't haven't deployed port knocking
Re: (Score:1)
A strong, unique password (aka a secret) is the only thing that matters.
Certificates are nothing but long passwords that people can't remember and thus need to store in plaintext.
Encrypted certificates are nothing but long passwords that people can't remember and store in an encrypted form, thus requiring a separate password.
Encryption of a connection is done using a password. Whether you call it a password, a pre-shared key, or a certificate, it's all the same. It's a secret known only to the legitimate
Re: (Score:3)
A strong, unique password (aka a secret) is the only thing that matters
A secret matters. A secret password is not the only thing that matters. The modern default for sshd is already protected against the attack in the story - I put the relevant default setting in the post you didn't read when replying id_rsa.pub is stored on the remote system (as ~/.ssh/authorized_keys) - the only way an attacker can have access to that is if they already have access to the remote system. If they have access to the system the game is already over.
Certificates are nothing but long passwords that people can't remember and thus need to store in plaintext.
Certificates are nothing but long and complex,
Re: (Score:1)
Re: (Score:3)
H and L only differ on the 6th bit [wikipedia.org]. You can't expect from everybody to have all bits right!
Re:LibreSSL (Score:5, Informative)
Time to leave OpenSSL and its vulnerability of the week behind.
This has nothing to do with OpenSSL other than that OpenSSH uses OpenSSL. This is a bug in OpenSSH itself.
Re: (Score:2)
Comment removed (Score:5, Insightful)
Re:Any professional tools available? (Score:5, Insightful)
Re: (Score:2)
Re: Any professional tools available? (Score:3)
The ssh.com people are still selling theirs as I recall. Go ahead and ask them for indemnification against breaches, though - I'm sure they could use a good laugh on a Wednesday.
Re: (Score:3)
layers. VPN to ssh w good pass to critical servers (Score:2)
Note to exploit this would require that you used a dumb password on that critical server, connected it's management ports directly to the internet, and failed to use any monitoring software like fail2ban.
In such a scenario, so sshd is going to save you. Any will have some imperfection. On our critical servers, sshd runs on a non-standard port, so script kiddies never find it, we use good passphrases they wouldn't guess anyway, we installed fail2ban so they'd get blocked when they started trying, and rece
Re: (Score:2)
Good passphrases (not "qwerty" or "admin")
I don't do passphrases. All accounts on my systems have lock-out passwords ("*"). If you want to log in, you need to use an SSH key.
this exploits console/KEYBOARD passwords (Score:2)
What's relevant here is the password/passphrase you'd use if you were at the console, using a keyboard attached to the machine. So ssh keys, while a good idea, don't apply in this instance.
Re: (Score:2)
Console? I've never even seen any of the servers that I currently manage. I haven't logged into a console in probably 10+ years.
No network / firewall / boot problems in ten years (Score:2)
In ten years you've not had any servers with any kind of network problem, firewall issues, or "won't boot" kind of issues? Clearly any of those would prevent you from using SSH, so would have to be fixed from the console (possibly with a KVM extending the console physically).
I suppose if you only manage one server and never touch it, it might never have any network problems or boot failures.
Re: (Score:2)
Nope. I have not seen a single physical server in a decade, and at this point, I run everything in AWS. If an instance has a problem, I just snapshot it, kill it, and launch a new one. Once that's done, I can take my time reviewing the logs and state from the failed instance's snapshot to try to avoid future faults.
I literally have every password in /etc/shadow set to *. There is not a single account on any system with a valid password hash in shadow (as is the default on most AWS images). This is why I giv
Re: OpenSSH is for cows. (Score:2)
From his denial there it sounds like serious mental illness may be at play - schizophrenia perhaps. Somebody is probably going to doxnswat him now, thinking it's for his own good, but really it isn't. The cries for help were good, but fellas - guns are never the answer to medical problems.
Re: (Score:2)