* Marc Chamberlin [01-16-19 23:36]:

I thought I would throw this out for discussion based on my recent experience with this particular package. I installed this in my new installation of OpenSuSE15.0. I thought initially this package SuSEfirewall2-fail2ban was a good idea for integration between these two applications. But based on my recent experience with trying to install it I got to say either this package needs to be tossed or fixed, as it stands it seriously breaks SuSEfirewall2 and it is not an easy thing to debug. Some of the problems I had, once it was installed were -

1. It forces the startup of the fail2ban service each time SuSEfirewall service is started, not something you might want sometimes, and not easy to figure out how to discover and stop this relationship.

why would you not want the service running?????

2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available)

and you are still running SuSEfirewall2 on Leap 15? change to firewalld, SuSEfirewall2 is no longer supported.

3. It caused/forced my networks internal NIC card to be relabeled as an external facing NIC, which then caused me to have 2 external facing NIC's and that broke all sorts of other services I had running on my server. (which led me on many wild goose chases trying to track down errors that other services such as Apache2, Tomcat, Apache James and even Named were reporting.)

fail2ban did not but you may have changed something to do that.

Given all the headaches this package caused me, my recommendation is to get rid of it, it is not really necessary AFAIK and my system seems to be running fine without it. Want to have some fun? Try it yourself, install the fail2ban service and this package also. Then restart the SuSEfirewall2 service and watch it belly ache. If you have two NICs like I do, one ext and one int then you will also see what happens with the int NIC.  Yarrg!

if you are not running a server, don't install fail2ban. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Marc Chamberlin [01-16-19 23:36]:

...

I thought I would throw this out for discussion based on my recent experience with this particular package. I installed this in my new installation of OpenSuSE15.0. I thought initially this package SuSEfirewall2-fail2ban was a good idea for integration between these two applications. But based on my recent experience with trying to install it I got to say either this package needs to be tossed or fixed, as it stands it seriously breaks SuSEfirewall2 and it is not an easy thing to debug. Some of the problems I had, once it was installed were -

1. It forces the startup of the fail2ban service each time SuSEfirewall service is started, not something you might want sometimes, and not easy to figure out how to discover and stop this relationship. why would you not want the service running????? When I am testing and trying to get things working. Turning on/off one or both services allowed me to do A/B comparisons and relax constraints. I was getting confusing results when I turned SuSEfirewall2 on and was

Hi Patrick and thanks for responding.  I will intersperse my answers with yours... On 01/16/2019 09:07 PM, Patrick Shanahan wrote: thinking I had turned off fail2ban.

...

2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available) and you are still running SuSEfirewall2 on Leap 15? change to firewalld, SuSEfirewall2 is no longer supported.

I wasn't aware that SuSEfirewall2 has been deprecated and that the OpenSuSE distro is switching to firewalld. I will look into using it but regret all the work I have put into SuSEfirewall2, over the years, getting it configured the way I want for all the services I am running... Oh well, guess that is called progress...

...

3. It caused/forced my networks internal NIC card to be relabeled as an external facing NIC, which then caused me to have 2 external facing NIC's and that broke all sorts of other services I had running on my server. (which led me on many wild goose chases trying to track down errors that other services such as Apache2, Tomcat, Apache James and even Named were reporting.) fail2ban did not but you may have changed something to do that.

Um I am not saying fail2ban itself is at fault, but the additional stuff that controls the sequence and dependencies for systemd, in starting both the fail2ban and SuSEfirewall2 services, that was added by the SuSEfirewall2-fail2ban optional package. When I figured out I was having troubles with the stuff that the package SuSEfirewall2-fail2ban had installed, I simply uninstalled it and SuSEfirewall began to work as expected (along with all my other services). I saw a warning message that was appearing when I was starting up SuSEfirewall2, about the reassignment of my int NIC card reclassifying it as an ext NIC which got me suspicious that something was broken with SuSEfirewall2. That and the warning about conflicts in systemd dependencies from fail2ban (also seen when SuSEfirewall2 was started) lead me to discover that it was this particular package that was causing problems. So I simply uninstalled it, and SuSEfirewall was once again a happy camper, along with all my other services that I was struggling to get working.

...

Given all the headaches this package caused me, my recommendation is to get rid of it, it is not really necessary AFAIK and my system seems to be running fine without it. Want to have some fun? Try it yourself, install the fail2ban service and this package also. Then restart the SuSEfirewall2 service and watch it belly ache. If you have two NICs like I do, one ext and one int then you will also see what happens with the int NIC.  Yarrg! if you are not running a server, don't install fail2ban.

But I am running a server! ;-)  With lots of services as I mentioned, including Apache2, Tomcat, Apache-James, Bind, DHCPD, VSFTPD, SSHD, VNC, VPN, PortKnock etc. All of which are/were dependent on SuSEfirewall2 defining network interfaces and ports correctly. And when the interface definitions, as I defined them in /etc/sysconfig/SuSEfirewall2, got overruled somehow by the installation of the SuSEfirewall2-fail2ban package, things got really confusing. And I had to spend a lot of time trying to understand why many of these services were failing... One thing I have learned through the school of hard knocks is never trust error messages! Most of them are either balderdash, lazy guesswork on the part of the developers, or most commonly the results from poorly designed/implemented error handlers in the software. Ya gots to wade through lots of red herrings before finding the kernel of truth sometimes  ;-)  and this problem was particularly nasty to resolve, with lots of misleading error messages to grok. Anywise, I will follow your recommendation and take a look at firewalld, but that still begs the question, why include this particular package in the distro anymore. IMHO it badly breaks things...     Marc... -- Linux Counter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Mathias Homann wrote:

Am Donnerstag, 17. Januar 2019, 06:07:11 CET schrieb Patrick Shanahan:

...

...

2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available)

and you are still running SuSEfirewall2 on Leap 15? change to firewalld, SuSEfirewall2 is no longer supported.

Seriously? I must have missed that in the release notes, link please.

I don't know about "SuSEfirewall2 is no longer supported", but the switch to firewalld is mentioned: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.0/ Search for "SuSEfirewall2" to skip down to "Removed Packages". -- Per Jessen, Zürich (4.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Mathias Homann wrote:

Am 2019-01-17 08:19, schrieb Per Jessen:

...

Anyone running a firewall will presumably have at least two NICs ?

So if your webserver has only one NIC you wouldn't put any firewall on it?

Ah yes, that's true, I was thinking more of a router, but you're right of course. -- Per Jessen, Zürich (6.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Peter Suetterlin [01-17-19 06:15]:

Patrick Shanahan wrote:

...

if you are not running a server, don't install fail2ban.

Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....

but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Peter Suetterlin wrote:

Patrick Shanahan wrote:

...

if you are not running a server, don't install fail2ban.

Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....

Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders. -- Per Jessen, Zürich (5.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan wrote:

* Peter Suetterlin [01-17-19 06:15]:

...

Patrick Shanahan wrote:

...

if you are not running a server, don't install fail2ban.

Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....

but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.

Well OK, with that definition of course all of my computers (even the Pi) are servers. This is the end of the Desktop :D -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hi carlos, Am 17.01.19 um 14:41 schrieb Carlos E. R.:> The non supported status has been mentioned on the lists, but apparently

there is no official message. In fact I'm still using it on two 15.0 machines till I set aside time to do the migration.

I remember a thread where someone found that SuSEfirewall service files installed by other packages are being removed, causing SuSEfirewall to fail, too. I tried to find that thread but failed. I think it affected Tumbleweed.

Meanwhile, SUSEfirewall2 in 15.0 got updates, I saw changes compared to 42.3

Warning: firewalld does not support NFS below V4, because it does not support NFSv3 and ypserv/ypbind, random ports.

if you want to change to firewalld: install firewalld-rpcbind-helper firewall-rpc-helper.py --help and follow the examples. this will change /etc/sysconfig/nfs for static nfs maybe if not inside this file present, add the line: RQUOTAD_PORT="" (to make sure all rules are applied (maybe for later use of this service) after that: yast firewall remove nfs remove nfs3 add the new created nfs-server-static and of course you have to uninstall susefirewall2 before... simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Bob Williams wrote:

On Thu, 17 Jan 2019 08:15:43 -0500 Patrick Shanahan wrote:

...

* Peter Suetterlin [01-17-19 06:15]:

...

Patrick Shanahan wrote:

...

if you are not running a server, don't install fail2ban.

Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....

but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.

Could you clarify please?

"ssh is a server service" = "accepting ssh logins is a server task"

If I don't have sshd enabled and active, and only use ssh to connect to other machines, am I running an ssh server?

No. sshd is the server part.

I had always thought not, but this thread is confusing me.

Don't get confused. You're right ;^>

The same applies to rsync and rsyncd.

Same there. Running rsyncd to accept remote connects = server. using rsync (usually then via ssh) for syncing is not. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/17/2019 07:38 AM, Bob Williams wrote:

On Thu, 17 Jan 2019 08:15:43 -0500 Patrick Shanahan wrote:

...

* Peter Suetterlin [01-17-19 06:15]:

...

Patrick Shanahan wrote:

...

if you are not running a server, don't install fail2ban.

Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.

Could you clarify please? If I don't have sshd enabled and active, and only use ssh to connect to other machines, am I running an ssh server? I had always thought not, but this thread is confusing me.

The same applies to rsync and rsyncd.

Bob

Hmmm this thread seems to have gone sideways but I think I got an answer... Since SuSEfirewall is going the way of dinosaurs I suspect my question about the SuSEFirewall2-fail2ban is moot.... Bob, as for the distinction, I would argue that the distinction between servers and desktops, and whether you are running an ssh server or not, lies in whether you are opening up ports on your system to accept incoming connections. If you are just initiating outgoing connections, such as using ssh to connect to other systems, or a mail client like Thunderbird to pick up your email, then you are not running a server. Fail2ban is a support service designed to prevent attacks against a server's services from some idiot who is attempting to gain access by guessing login names and passwords. Therefore it is monitoring incoming connections and thus falls in the realm of being a service/server.     Marc... -- Linux Counter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Many thanks, Peter, Marc and Jeffrey -- Bob

On 17/01/2019 17.30, Per Jessen wrote:

Carlos E. R. wrote:

...

On 17/01/2019 14.49, Per Jessen wrote:

...

Peter Suetterlin wrote:

...

Patrick Shanahan wrote:

...

if you are not running a server, don't install fail2ban.

Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....

Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.

I do both.

When you're using keys, there is no need to change the port. You gain nothing.

Less noise on the logs, banging the port 22 produces nothing. Actually, apparently my router has its own ssh service, and it can not be stopped. I had to firewall it instead, because IRC would not let me in: they actively probe ports on clients: [19:19] [Notice] -freenode-connect- Welcome to freenode. To protect the network all new connections will be scanned for vulnerabilities. This will not harm your computer, and vulnerable hosts will be notified.

...

Curious thing is, I have no idea if there are attempts at my router, it doesn't report anything.

With keys, there is nothing to report.

Yes, the attempts. There is noise. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 17/01/2019 16.38, Bob Williams wrote:

On Thu, 17 Jan 2019 08:15:43 -0500 Patrick Shanahan wrote:

...

* Peter Suetterlin [01-17-19 06:15]:

...

Patrick Shanahan wrote:

...

if you are not running a server, don't install fail2ban.

Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....

but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.

Could you clarify please? If I don't have sshd enabled and active, and only use ssh to connect to other machines, am I running an ssh server? I had always thought not, but this thread is confusing me.

The same applies to rsync and rsyncd.

In Linux, many things provide "server" facilities. It does not mean that the machine is a public or internal server. In Windows world, they have a different product that is called Windows Server, and charge for it differently. In Linux any machine can act as server easily. If you use ssh on your laptop to connect to your desktop, then you desktop is asking as server and the laptop as client. And the role can be reversed instantly, even simultaneously. If you share a directory on your desktop to access it from your laptop, then the desktop is acting as file server. Regarding ssh, then you need to have the sshd service running to be a "ssh server". And the port opened in the firewalld. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 1/17/19 8:30 AM, Per Jessen wrote:

...

...

Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders. I do both. When you're using keys, there is no need to change the port. You gain nothing.

...

Curious thing is, I have no idea if there are attempts at my router, it doesn't report anything. With keys, there is nothing to report.

Unless a zero-day is discovered in sshd! BTW, I remember when I first installed SuSE 5.2 on my home computer the documentation for the firewall was still in German.  I decided to just turn it off until I could figure things out later.  Alas, I was quickly pwned via a remote-root vulnerability in mountd.  I caught it right away and re-installed the system, this time with the firewall running. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/17/2019 02:48 PM, Lew Wolfgang wrote:

Well, doesn't all security rely on obscurity?  The goal should be to increase obscurity as much as possible.  Crypto keys can be guessed, if you can throw enough guesses.

Actually, no.  The method can be open, provided the keys are secret.  Given the size of current keys, they'd take a huge amount of guessing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 1/17/19 11:53 AM, James Knott wrote:

On 01/17/2019 02:48 PM, Lew Wolfgang wrote:

...

Well, doesn't all security rely on obscurity?  The goal should be to increase obscurity as much as possible.  Crypto keys can be guessed, if you can throw enough guesses. Actually, no.  The method can be open, provided the keys are secret. Given the size of current keys, they'd take a huge amount of guessing.

Yes, of course, but theoretically possible to guess nevertheless. The risk of there being a vulnerability in the sshd daemon is probably greater, which is why a bad guess filter is also a good idea, along with firewall ACL's to limit who can connect (if appropriate for the requirements, of course). Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 17/01/2019 22.10, Lew Wolfgang wrote:

On 1/17/19 12:33 PM, Carlos E. R. wrote:

...

On 17/01/2019 20.53, James Knott wrote:

...

On 01/17/2019 02:48 PM, Lew Wolfgang wrote:

...

Well, doesn't all security rely on obscurity?  The goal should be to increase obscurity as much as possible.  Crypto keys can be guessed, if you can throw enough guesses. Actually, no.  The method can be open, provided the keys are secret. Given the size of current keys, they'd take a huge amount of guessing. And that's not security through obscurity. That would be using a non-published secret crypto method, and where knowing the method would instantly lead to opening the door. Example: hiding the door latch somewhere, like with with a button press that you can not see with simple eyes.

Huh?  Throwing guesses at a public crypto system doesn't require any knowledge of the method. It might take a few billion years, but it's possible to do.  You might get lucky at the first guess! Of course, one could put bounds on the guesses if you knew the encryption algorithm, that's what hacker reconnaissance does, like identifying the version number of the sshd server.

No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password.. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 1/17/19 1:17 PM, Carlos E. R. wrote:

No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password..

The "lock mechanism" of ssh is known, can it be opened without knowing or guessing the password? The mechanism of a doorknob lock is known, the one good key is obfuscated by hiding it among all the keys that won't work.  Security through obscurity! Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 17 Jan 2019 19:33:54 +0100 "Carlos E. R." wrote:

In Linux, many things provide "server" facilities.

The one that always used to provoke the most arguments was X windows: The X windows server runs on the client machine. The X windows client runs on the server machine. So .. horses for courses, and make sure you've defined terms in advance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Lew Wolfgang wrote:

On 1/17/19 5:49 AM, Per Jessen wrote:

...

Peter Suetterlin wrote:

...

Patrick Shanahan wrote:

...

if you are not running a server, don't install fail2ban.

Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.

Security through obscurity?  What could possibly go wrong?

Hi Lew Obviously YMMV, but we had a number of systems where we didn't want to use keys (can't remember why, it's 10+ years ago), moving the port was sufficient to stop the brute force attacks. At the time, someone also suggested picking a new port every day, but we never implemented that. Today, I would insist on using keys. -- Per Jessen, Zürich (-1.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Lew Wolfgang wrote:

On 1/17/19 8:30 AM, Per Jessen wrote:

...

...

...

Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders. I do both. When you're using keys, there is no need to change the port. You gain nothing.

...

Curious thing is, I have no idea if there are attempts at my router, it doesn't report anything. With keys, there is nothing to report.

Unless a zero-day is discovered in sshd!

Nothing much to report except : sshd[11505]: Accepted publickey for user from 192.168.112.114 port 59294

BTW, I remember when I first installed SuSE 5.2 on my home computer the documentation for the firewall was still in German.  I decided to just turn it off until I could figure things out later.  Alas, I was quickly pwned via a remote-root vulnerability in mountd.  I caught it right away and re-installed the system, this time with the firewall running.

Going a bit off-topic here, but I expect we have all been there. I had a webserver compromised by someone brute forcing the password and I think we also had someone very close to gaining access by way of a PHP vulnerability. It was caught by outbound emails failing. -- Per Jessen, Zürich (-2.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/01/2019 02.18, Lew Wolfgang wrote:

On 1/17/19 4:31 PM, Carlos E. R. wrote:

...

On 17/01/2019 22.32, Lew Wolfgang wrote:

...

On 1/17/19 1:17 PM, Carlos E. R. wrote:

...

No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password.. The "lock mechanism" of ssh is known, can it be opened without knowing or guessing the password? No

But you said that once the encryption method (not the key) is known the lock can be opened.  SSH's encryption methods are open-source, they are known.

Exactly. And even knowing the method in detail, you still need the key to open it, so it is not "security through obscurity"

...

...

The mechanism of a doorknob lock is known, the one good key is obfuscated by hiding it among all the keys that won't work.  Security through obscurity! No, that is not obfuscation.

I have 2000 different keys.  One of those keys work in my door lock.  To keep Per from sneaking in and drinking all of my beer, I put all 2000 keys in a bag and hang it on the front door.  The one good key is hidden among 1999 other ones.  It's obscured, isn't it? If not, what is it?

This is a bit contrived, people don't put a bag of keys by the door. If you do that, you are changing the premises. Still, I don't think that is obfuscation; it would be similar to posting a list of passwords with one correct. Even so, the key lock system is not using obfuscation, just a small set of possible password combinations. However. Keylocks. Someone, somewhere, at some prison, used the inmates to assemble some brand door locks. The inmates got thus intimate knowledge of how the lock worked, and designed a system to break it. Soon all the thieves in the country knew how to open those locks easily. That is security through obscurity, and it was found out :-p Compared to analysts finding a debility in some encryption software allowing to break the codes easily. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Lew Wolfgang wrote:

On 01/18/2019 04:20 AM, Carlos E. R. wrote:

...

...

But you said that once the encryption method (not the key) is known the lock can be opened.  SSH's encryption methods are open-source, they are known. Exactly. And even knowing the method in detail, you still need the key to open it, so it is not "security through obscurity"

I'm talking about obscuring the one good key with a large number of bad ones.  You're taking about the lock, I'm talking about the keys. I think we're talking past each other?

Maybe this has gone a bit too off-topic? -- Per Jessen, Zürich (0.2°C) member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org