Koozali.org formerly Contribs.org

Possible security enhancement for securing SSH

guest22

Re: Possible security enhancement for securing SSH
« Reply #15 on: November 24, 2014, 01:27:32 PM »
IMVHO, ssh with keys is secure enough..

we should really work to replace pptp vpn with openvpn as the default vpn in SME

again, depends on the security policies. Question remains, for a secure VPN solution, pure IPSEC or OpenVPN? Or I could be mistaking at all.

I am not in favor of any flavor, just want to make sure we choose an industry standard, deploy able in all kinds of scenarios. Where I *read* that pure IPSEC is "most compatible" with routers, gateways and such HW devices.

guest

Offline ReetP

  • *
  • 2,359
Re: Possible security enhancement for securing SSH
« Reply #16 on: November 24, 2014, 03:27:36 PM »
Stefano,

check the bugs as a PPTP replacement is being looked at as we speak  :-P
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Offline Stefano

  • *
  • 10,782
  • Skype account: maghissimo
    • Smeserver italian community
Re: Possible security enhancement for securing SSH
« Reply #17 on: November 24, 2014, 03:40:49 PM »
I have no doubt about it :-D
Consulente di Smeserver.it -  Soluzioni e supporto su Sme server in Italia

Offline DanB35

  • ****
  • 764
    • http://www.familybrown.org
Re: Possible security enhancement for securing SSH
« Reply #18 on: November 27, 2014, 09:17:59 PM »
Google Authenticator, is that talking with any Google service in any way?
No, it isn't.  Google Authenticator was developed by Google as an implementation of RFC 6238, and multiple open-source implementations for both the client side and the server side are available.  By default, the Google code calls a Google site once, on account setup, to generate a QR code with the account details (username and host, but not password) and secret key, but if that bothers you, you can bypass the QR code entirely and enter those details manually.  Or, no doubt, that can be generated locally as well.

There is no need to communicate with any external resource on login to verify the one-time password; that is done directly between the client and the server.  The only requirement is that the client and server both have clocks that are pretty close to each other.
......

Re: Possible security enhancement for securing SSH
« Reply #19 on: November 28, 2014, 06:58:06 AM »
Thank you for clarifying that DanB and great conversation guys, btw I also wanted to say thanks for all you do as part of this great project I really like it, it's not difficult to use, has everything you need, easily customizable, great support and I like how several of you chimed in on a thought I had that I haven't had a chance to play with yet and all the suggestions are much appreciated.

BTW I hope you guys had a good thanksgiving if you celebrate it.
« Last Edit: November 28, 2014, 07:30:04 AM by sektor »

guest22

Re: Possible security enhancement for securing SSH
« Reply #20 on: November 28, 2014, 07:33:52 AM »
By default, the Google code calls a Google site once, on account setup, to generate a QR code with the account details (username and host, but not password) and secret key, but if that bothers you, you can bypass the QR code entirely and enter those details manually.  Or, no doubt, that can be generated locally as well.

Thanks for clarifying that.

It also means that by creating an account with Google, I agree to the consolidated Terms of service of all Google services, including the fact that Google is required to comply with the US Patriot Act. Same for any Android device that registers with Google. (or any Apple device for that matter).

So for me a no go area. But good talk.

guest

guest22

Re: Possible security enhancement for securing SSH
« Reply #21 on: November 28, 2014, 07:41:12 AM »
BTW I hope you guys had a good thanksgiving if you celebrate it.

Thanks but in EU and November 28th here already. BLACK FRIDAY!!  :wink:

Re: Possible security enhancement for securing SSH
« Reply #22 on: November 29, 2014, 05:44:09 AM »
Did you get your shopping done?

Offline TerryF

  • grumpy old man
  • *
  • 1,156
Re: Possible security enhancement for securing SSH
« Reply #23 on: November 29, 2014, 10:05:44 AM »
All HF wants for Xmas is a mustard seed grinder :-)
--
qui scribit bis legit

Offline DanB35

  • ****
  • 764
    • http://www.familybrown.org
Re: Possible security enhancement for securing SSH
« Reply #24 on: November 29, 2014, 01:57:09 PM »
It also means that by creating an account with Google, I agree to the consolidated Terms of service of all Google services, including the fact that Google is required to comply with the US Patriot Act.
Please, enough with the FUD.  There is no need to create an account with Google to use Google Authenticator.  You don't even need to use Google's app, as there are others that will handle the client side too (I use Authy, for example).

I don't think this is something especially useful for SSH security, as public-key authentication is already there and is more secure.  But let that decision be made on the facts, one of which is that Google isn't going to get any information about you, your site, or your account unless you specifically send it.  You don't need a Google account; Google doesn't check your logins; and your login, hostname, and secret key are only sent to Google if you take the URL it gives you and put it in a web browser to get a QR code.

Here's the output of running google-authenticator:
Code: [Select]
bash-4.1$ google-authenticator
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/dan@sme-test%3Fsecret%3DESIX2XUGQN2WJWW2
Your new secret key is: ESIX2XUGQN2WJWW2
Your verification code is 610810
Your emergency scratch codes are:
  72938720
  47270924
  37045962
  28597796
  33967286

Do you want me to update your "~/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

As you see, the first thing it gives you is a URL.  If you plug that URL into your browser, it will show you a QR code that you can use to set up the account on your smartphone.  And you'll see that the URL goes to Google, so it's possible they could retain the user, hostname, and secret key (I have no idea whether they do or not, but they could).  This is the only part of the process that communicates with Google at all, and it's optional.  If that concerns you, you can instead enter the key manually into your smartphone or other app.  If this were to be integrated with SME Server, the QR code could just as well be generated locally, so users could have the easy setup of the QR code and there would still be nothing in Google's logs.

ETA: Here's a pretty good writeup on how the system works: http://garbagecollected.org/2014/09/14/how-google-authenticator-works/
« Last Edit: November 29, 2014, 02:14:13 PM by DanB35 »
......

guest22

Re: Possible security enhancement for securing SSH
« Reply #25 on: June 07, 2016, 12:04:30 AM »
I'd like to bump this thread. Interesting topic to keep alive.

Offline DanB35

  • ****
  • 764
    • http://www.familybrown.org
Re: Possible security enhancement for securing SSH
« Reply #26 on: June 07, 2016, 01:34:39 AM »
Holy necro-thread, Batman!

Several topics were discussed in this thread--which did you think were worth reviving?  On a quick review, I see:
  • 2FA for SSH
  • 2FA for server-manager
  • 2FA for VPN connections
  • Relative merits of different VPN software/protocols

I don't really see any value in 2FA for SSH; public key authentication is a secure and mature technology.  I don't see the value in it for access to the server-manager either; the LAN is presumed to be safe, so the extra layer would be unnecessary.  I could see it for VPN connections, if they were otherwise secured with only username/password, but I'm not sure if it's feasible to implement.
......

Offline Jean-Philippe Pialasse

  • *
  • 1,469
  • aka Unnilennium
    • http://smeserver.pialasse.com
Re: Possible security enhancement for securing SSH
« Reply #27 on: June 07, 2016, 02:43:08 AM »
I second Dan for ssh ( regarding public rsa key exchange is used and password disabled), vpn ( using correct keys and not passwords) and server manager (as it is on https on lan only or trusted external ip or over ssh or vpn)

This could however be nice for email client connexion (webmail and pops/imaps). From the outside of the LAN and for other similar http auth.

One point changing from the time of this thread is the possibility of accepted ssl certificate with letsencrypt, that ease the use and trust of https connexion to SME.

Offline DanB35

  • ****
  • 764
    • http://www.familybrown.org
Re: Possible security enhancement for securing SSH
« Reply #28 on: June 07, 2016, 03:01:48 AM »
This could however be nice for email client connexion (webmail and pops/imaps). From the outside of the LAN and for other similar http auth.
That's certainly possible, at least in principle, with webmail (Horde doesn't currently support 2FA, but maybe an alternative webmail app does), but could it work with POP/IMAP?  I admit I know very little about the internals of either protocol, but I don't know of a way that they could require a third login credential (user/pass/token) and validate it against the proper backend.

Quote
One point changing from the time of this thread is the possibility of accepted ssl certificate with letsencrypt, that ease the use and trust of https connexion to SME.
Definitely, and I look forward to LE support being part of the base distro.
......

guest22

Re: Possible security enhancement for securing SSH
« Reply #29 on: June 07, 2016, 06:19:16 AM »
This could however be nice for email client connexion (webmail and pops/imaps). From the outside of the LAN and for other similar http auth.

That is exactly what I am looking for, just not limited to webmail but for all (contrib) web applications. If at all possible.....