LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 11-14-2017, 06:44 PM   #61
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,509

Rep: Reputation: 1811Reputation: 1811Reputation: 1811Reputation: 1811Reputation: 1811Reputation: 1811Reputation: 1811Reputation: 1811Reputation: 1811Reputation: 1811Reputation: 1811

Quote:
Originally Posted by IsaacKuo View Post
Quote:
Furthermore, if an intruder can "slip" a new certificate public key into the authorized-keys file, he can grant access to himself with a fairly-low probability of actually being detected. All he needs to do is to penetrate the system once, and hope that you're not paying attention.
Eh, you mean the intruder "just" needs root access once. With root access, there are a zillion different ways to insert a back door without messing with any configuration file. For example, unless you block outgoing web requests (the typical method by which a linux distribution will download security updates), it'll be possible for a compromised executable to reach out with a reverse ssh.
No, with ssh you only need plain user access to change the authorized_keys file for that user. However, I wouldn't be especially confident that your VPN server is safe after an intruder getting in "just" once.

Quote:
Which, honestly, I am more comfortable with when it comes to on-the-road access. You're assuming the client computer is never compromised, but what are the chances? Physical security on a laptop is typically going to be less robust. If I accidentally leave my laptop unlocked for a minute while distracted or something? It takes only a few seconds to plug in a USB device and run a script kiddie script.
Using both ssh and VPN is a reasonable choice.


Quote:
Originally Posted by 273 View Post
Do you have any examples of this being explioted? I ask because I can't say just as I type whether I have that set or not but I know that I cannot attempt to use SSH to connect to my machine without having a valid key.
This article seems fairly convincing that ChallengeResponseAuthentication is by default basically another form of password authentication (although it's meant to allow some other custom kinds of authentication).

Quote:
Originally Posted by sundialsvcs View Post
Quote:
Originally Posted by haertig View Post
Just a point of clarification for the users here that are new to this stuff: you do not find "certificates" in an "authorized_keys" file. You find "public keys". The two are quite different things. Since we have gone back and forth between "certificate authentication", "pubkey authentication" and "password authentication" in this thread, it's important to keep the terminology correct so as not to confuse the less experienced. This was just a simple typo by @sundialsvcs, but could throw some users into a fit of misunderstanding.
Thank you for the clarification.

But, functionally speaking, the two are, at some level, similar
There is no need to be mysterious about it. A certificate contains a public key encoded within it.
 
Old 11-14-2017, 07:51 PM   #62
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
Quote:
Originally Posted by sundialsvcs View Post
And it just might be open to the entire world, maybe giving all of them this prompt:

login:
This is getting ridiculous. It just isn't hard to disable password login in sshd. Your scaremongering just makes your argument less credible.

It takes like 5 minutes for a newbie to read the entire sshd_config file and figure out how to say "n" to everything they don't want. It takes 2 minutes for a newbie to confirm that an attempt to ssh in does NOT produce a login prompt.

The only part that requires a tiny bit of outside knowledge is determining what would be a good custom port to use (e.g. one that isn't used for something else, and which isn't blocked by whatever filters the ISP may have).
 
Old 11-14-2017, 08:30 PM   #63
jlinkels
LQ Guru
 
Registered: Oct 2003
Location: Bonaire, Leeuwarden
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,191

Rep: Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039
Quote:
Originally Posted by sundialsvcs View Post
Set up your "sshd" so that it listens only to the inside of the tunnel.
That answers the question. Thanks

jlinkels
 
Old 11-15-2017, 08:39 AM   #64
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177
Quote:
Originally Posted by IsaacKuo View Post
This is getting ridiculous. It just isn't hard to disable password login in sshd. Your scaremongering just makes your argument less credible.

It takes like 5 minutes for a newbie to read the entire sshd_config file and figure out how to say "n" to everything they don't want. It takes 2 minutes for a newbie to confirm that an attempt to ssh in does NOT produce a login prompt.

The only part that requires a tiny bit of outside knowledge is determining what would be a good custom port to use (e.g. one that isn't used for something else, and which isn't blocked by whatever filters the ISP may have).
Come, now. There's no reason to take personal offense at an opinion, even if you don't agree! No "scaremongering" here. We're just talking about crypto technology here, and there are no hard-and-fast rules. Pax.

That being said – I can port-scan your entire IP-address in a couple minutes, and discover which port-number you are using, because you are using "a TCP/IP port." And then, I can discover that I am talking to "sshd." The next thing that my scanner must do is to try to throw a user-id and password at it. Yes, at that point I can determine whether you are allowing password authentication. (If you aren't, I know that it's useless to try. But you are the smart exception, not the rule. The typical experience is that instead "the hornets gather, by the thousands, incessantly pounding your system and sucking-up valuable resources in doing it, until you – poor slob – finally run out of dictionary." )

"ssh" also has the potential problem of being optional, because it operates as a user-level program on top of the stack. If you don't do it right, each and every time you do it, traffic might not actually pass through the "ssh tunnel" that you have created. You might well be sending data "in the clear" and you don't know it. You could be talking to a "man in the middle" and once again you wouldn't know. At the end of the day, "ssh" is precisely what it was designed to be: "a shell," which can also be pressed into service to provide a limited form of tunneling between two specific logged-on user sessions.

OpenVPN, properly used, literally does deliver on the promise of a "virtual private network." A single user can connect to another system, and/or two distant subnets can be linked to one another, and the result is as if the two systems were connected by a bulletproof – yet, undetectable – piece of wire. It serves all system users and processes. This becomes the outer bastion of defense, with "sshd" perhaps being the second layer of defense but not the first. (Or, as when connecting two subnets, no further defenses are deemed necessary.) The result, as promised, is that there are now no unauthorized connection attempts, because the secret door, which uses no TCP/IP ports at all, cannot even be found by the uninitiated.

Last edited by sundialsvcs; 11-15-2017 at 08:45 AM.
 
Old 11-15-2017, 08:43 AM   #65
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 5,281

Rep: Reputation: 1924Reputation: 1924Reputation: 1924Reputation: 1924Reputation: 1924Reputation: 1924Reputation: 1924Reputation: 1924Reputation: 1924Reputation: 1924Reputation: 1924
The 'ace-in-the-hole' for SSH for me is the ability to create a reverse secure shell tunnel.
I often tunnel between a work server and my home computer. The home IP address is subject to change, which requires updating a URL by dynamic DNS. The work server runs a cron job that regularly calls out to the home URL and establishes a reverse SSH connection if available (using key authentication and host key checking). I can then tunnel back to the work server (again using key authentication and host key checking).
The work server is seen as having a static IP address, so it is easy to firewall off unwanted SSH probes on my home router. The work server has no SSH port open for incoming connections, so also a 'dwarvish' door.

I appreciate that SSH by default has minimum security, as it allows for easy setup of new machines. The hardening process after initial key exchange is simple and well documented.

For simple setups, SSH is easier. VPN comes into it's own in corporate environments with many users. Managing SSH keys for more than a few users rapidly becomes painful. Configuring a VPN client can be a very time consuming process.
 
Old 11-15-2017, 09:08 AM   #66
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
Quote:
Originally Posted by sundialsvcs View Post
Come, now. There's no reason to take personal offense at an opinion, even if you don't agree! No "scaremongering" here. We're just talking about crypto technology here, and there are no hard-and-fast rules. Pax.
You keep on repeating this thing, with funny colors and emojis, as if it were a real problem. It just isn't a problem.

Quote:
That being said I can port-scan your entire IP-address in a couple minutes, and discover which port-number you are using, because you are using "a TCP/IP port." And then, I can discover that I am talking to "sshd." The next thing that my scanner must do is to try to throw a user-id and password at it. Yes, at that point I can determine whether you are allowing password authentication. (If you aren't, I know that it's useless to try. But you are the smart exception, not the rule.
Do you have ANYTHING to back that up? How many folks are using a custom ssh port and also allowing password authentication? How does that compare to the number of folks using a custom ssh port and locking it down? My guess is that the latter is the common thing, not "the smart exception".

And do you have any idea at all about how many folks have OpenVPN on the standard ports, or not configured to your particular opinion on exactly how it's supposed to be done? Do you think you are "the smart exception", or do you think everyone else has OpenVPN configured exactly the way you insist is the only correct way to do it?

Quote:
The typical experience is that instead "the hornets gather, by the thousands, incessantly pounding your system and sucking-up valuable resources in doing it, until you poor slob finally run out of dictionary." )
See, there you go again. Claiming a problem which is not a problem, using a silly emoji and you think this helps make your point. In reality, it just makes your point look silly.

Quote:
"ssh" also has the potential problem of being optional, because it operates as a user-level program on top of the stack. If you don't do it right, each and every time you do it, traffic might not actually pass through the "ssh tunnel" that you have created. You might well be sending data "in the clear" and you don't know it.
You know what? I just really don't see how this ever actually happens. If you actually care the slightest bit about security, you have a firewall filter on your router. It's only going to have your one custom ssh port open. So how the heck are you supposed to accidentally connect up through that router via an insecure "in the clear" protocol? It'll just bounce off iptables rather than actually working.

And when you use an ssh tunnel, you've got to hit localhost, not some other IP address out there. How are you supposed to accidentally not know you're hitting a completely wrong IP address that's not localhost? How the heck are you supposed to mistake some random IP address or host name for localhost?

Quote:
You could be talking to a "man in the middle" and once again you wouldn't know.
No, that's what the keys are for. Ssh is extremely vocal when they don't match what is expected.

Quote:
A single user can connect to another system, and/or two distant subnets can be linked to one another, and the result is as if the two systems were connected by a bulletproof yet, undetectable piece of wire
Yeah, I don't want that on-the-road. I want a very limited connection that is only used for a couple things on a temporary basis. I don't trust my on-the-road laptops as much as I trust the machines that always stay at home.
 
Old 11-15-2017, 09:18 AM   #67
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,298

Rep: Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957
Quote:
Originally Posted by sundialsvcs View Post
"ssh" also has the potential problem of being optional, because it operates as a user-level program on top of the stack. If you don't do it right, each and every time you do it, traffic might not actually pass through the "ssh tunnel" that you have created.
The same is true for OpenVPN if the default route isn't set up or pushed to the client, or if some of your traffic has a more specific route that is used in preference to the VPN route.

On a slightly different topic, how can you set up a VPN server so that the VPN starts automatically when the server reboots without having the server's private key exposed in an unencrypted file on that server? I'd love to use VPN as my primary access to my LAN from afield, but that VPN has to come up on an unattended reboot.

Last edited by rknichols; 11-15-2017 at 09:19 AM.
 
Old 11-15-2017, 10:11 AM   #68
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD, Raspbian, Arch
Posts: 2,280

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
With either SSH or VPN, you need to make sure that ALL traffic is going across the tunnel (assuming that's what you want - there are cases where you don't).

It is very easy to set up an SSH tunnel (often referred to as "Dynamic Port Forwarding" or "SOCKS Proxy") and find that the majority of you traffic goes down that tunnel, but your DNS queries do not. DNS queries can reveal a lot about who you are and what you're doing, so you can't always equate them to "unimportant collateral traffic".

With VPN, the server can push directives down to the clients instructing them to send all traffic down the tunnel. But the thing is, the clients don't have to obey this. They can ignore the directive.

With VPN, usually the server directive is good enough. But you still have to check.

With SSH, the choice to send everything down the tunnel is made on the client end. There is no server directive to prompt the client. So it's easier to screw this part up when using SSH than with VPN (but just barely - you have to remember that the server directive is only a suggestion, not a hard and fast rule).

It is a good idea when setting stuff like this up, to establish your secure connection (tunnel) and then check for DNS leaks by going to the site https://www.dnsleaktest.com/ and running their "Extended Test". If you see DNS responses coming back from places outside of what you normally see from your home ISP (assuming your VPN/SSH server is running at your home), then you know you have a DNS leak that needs to be plugged.
 
Old 11-15-2017, 02:20 PM   #69
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177
Quote:
Originally Posted by rknichols View Post
On a slightly different topic, how can you set up a VPN server so that the VPN starts automatically when the server reboots without having the server's private key exposed in an unencrypted file on that server? I'd love to use VPN as my primary access to my LAN from afield, but that VPN has to come up on an unattended reboot.
I solve the problem by ensuring that the /etc/openvpn directory is owned by root and has a rwx------ permissions-mask.

However, also note that the "certificate and key" information for the server, as stored in this directory, actually serves the self-same purpose as does the "certificate and key" information in each client's credentials: it acts to identify the machine. The certificate is handed to the remote party, and the corresponding secret-key is used to decrypt whatever that remote sends back. But this secret could be replaced at any time, so long as the certificate and the key were replaced together. The mere possession of a certificate/key pair is not "the profound secret."

The certificate/key pair, whether possessed by the server or by any peer, is in fact only a form of identification. A form of identification that is only accepted if it is found to be properly signed. Both client and server use the (public) ca.crt file, shared by all, to verify that a certificate has been signed by the expected authority, and this alone is what causes them to accept it.

The "profound secret" is the signing key which must be used to cause any certificate that is issued to be accepted as "authentic" by all parties. But, they cannot create a new credential given this information, because they do not possess ca.key. Although anyone can crank-out a new SSL key in a matter of a few seconds, they cannot cause it to be accepted.

This "signing" concept does not exist in ssh. If a public-key is present in a authorized-keys file, it is taken to be valid, simply because it is present. While, of course, this is infinitely stronger than "a password," there is still no third-party involved.

- - -
And, please note: "I am not engaged in 'ssh bashing' here!"

Last edited by sundialsvcs; 11-15-2017 at 02:24 PM.
 
Old 11-15-2017, 02:36 PM   #70
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
I do not find it acceptable for access between my computers to be subject to a third party's authority. If I were to use VPN, I'd use some method of authentication which does not involve signing by a third party CA.
 
Old 11-15-2017, 02:44 PM   #71
haertig
Senior Member
 
Registered: Nov 2004
Distribution: Debian, Ubuntu, LinuxMint, Slackware, SysrescueCD, Raspbian, Arch
Posts: 2,280

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by IsaacKuo View Post
I do not find it acceptable for access between my computers to be subject to a third party's authority. If I were to use VPN, I'd use some method of authentication which does not involve signing by a third party CA.
That method would be called "self-signed certificates".

Third parties are not authorizing anything. They're just signing certificates saying that they have researched, and indeed who you say you are is really who you are. You probably don't need that within your own network.

However, Firefox, Chrome, and other browsers will still throw up a warning for self-signed certs, even if they are on your own internal network. You need to add yourself (the one who self-signed your certs) to the list of trusted CA's in the web browser. Or, just ignore the warnings and plow right ahead.

But in any case, it is not the third party that is authorizing anything. Only you can do that.
 
Old 11-15-2017, 02:46 PM   #72
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177
Quote:
Originally Posted by IsaacKuo View Post
And do you have any idea at all about how many folks have OpenVPN on the standard ports, or not configured to your particular opinion on exactly how it's supposed to be done? Do you think you are "the smart exception", or do you think everyone else has OpenVPN configured exactly the way you insist is the only correct way to do it?

See, there you go again. Claiming a problem which is not a problem, using a silly emoji and you think this helps make your point. In reality, it just makes your point look silly.

You know what? I just really don't see how this ever actually happens. If you actually care the slightest bit about security, you have a firewall filter on your router. It's only going to have your one custom ssh port open. So how the heck are you supposed to accidentally connect up through that router via an insecure "in the clear" protocol? It'll just bounce off iptables rather than actually working.

No, that's what the keys are for. Ssh is extremely vocal when they don't match what is expected.
C'mon, don't get personal. We're just two technicians, talking about two different sets of cryptographic technology, and I'm pointing out the advantages of one of them in a fairly-particular use case. If there was no validity to what I am saying, then of course VPNs would never have been invented. (Or, per contra, ssh would no longer be used.) Since neither of these things has happened – or ever will – "let's move on, shall we?" There must be common t-e-c-h-n-i-c-a-l ground.

Of course there are many varieties to "ssh tunneling," some of which basically steal-the-playbook from VPNs by also linking themselves into various levels of the TCP/IP protocol stack, but my comment about "accidentally connecting in-the-clear" particularly speaks of outbound connections. Since ordinary, run-of-the-mill "ssh tunnels" do not intrude at all into the stack, there are many assumptions that are being made, all of which must be carefully followed by the user who is setting up the tunnel, without which the traffic might pass "in the clear." VPNs, on the other hand, do integrate into the protocol stack by default, such that they are literally-equivalent to a hardware device on behalf of all system users.

Apparently, some people have interpreted my thread as being "ssh bashing." This is not and never was the case. But, given that there is a sticky thread here that is specifically talking about "failed SSH login attempts," I think that my comments have genuine and pragmatic merit. (And, if I may say, "ought not be perceived as cause for conflict!")

OpenVPN has several fundamental architectural differences which are very significant:
  1. The use of the UDP protocol, combined with the ability to conceal itself so that "unauthorized connection attempts" literally do not occur.
  2. The connection is made to a system, not to a user.
  3. The connection is integrated into the network protocol stack at one of two levels, and therefore covers all possible connections between the systems, regardless of what the users or the processes on either of those systems do or do-not do.
  4. Both parties identify themselves to each other, relying on a third party ("the CA") to establish authenticity. Mere possession of anything – a password, or a public-key – is not enough. The parties can verify the credentials, but cannot create credentials which would pass this same verification.
  5. Credentials can be selectively revoked. (If "you" quit or get fired, "your" badge drops dead. Mine doesn't.)

However, I never intended to suggest that I was slamming anyone for choosing to use "ssh!" Nor that I was bashing the "ssh" technology!

Last edited by sundialsvcs; 11-15-2017 at 02:51 PM.
 
Old 11-15-2017, 03:10 PM   #73
Quantumstate
Member
 
Registered: Jun 2005
Location: Seattle, Ecotopia
Distribution: CentOS 7.4 with KDE
Posts: 262

Rep: Reputation: 22
Well I for one, welcome my new VPN master. Agree, Isaac cool it.

First though comes research on which is truly the most secure method, OpenSwan, OpenVPN, or IPSec.

I'm aprehensive of the complexity, although I am now conquering email! The Mount Everest of applications!

Nothing I've found can equal sshfs for remote mounts though. Used it for years. And reverse SSH tunnels are wonderful.

What exactly do you get with VPN? Access only to remote daemons that are listening?
 
Old 11-15-2017, 03:49 PM   #74
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,349
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
Quote:
Originally Posted by sundialsvcs View Post
C'mon, don't get personal. We're just two technicians, talking about two different sets of cryptographic technology, and I'm pointing out the advantages of one of them in a fairly-particular use case.
You're the one claiming we shouldn't be using SSH, and one of your reasons you keep repeating is just...wrong. I don't see any reason I should concede about that point. When following simple straightforward guides on how to use ssh securely, sshd simply will not be presenting any sort of login prompt. It's that simple.

Quote:
If there was no validity to what I am saying, then of course VPNs would never have been invented.
VPNs could easily have been invented for completely different reasons. For one thing, the basic thing that VPNs tend to be used for is very different from what ssh tends to be used for. Most installs of sshd are used for a remote console interface and/or file transfers. I'm unaware of VPN even being able to do either of those things. It's apples and oranges.

I seriously don't think VPN was invented just because ssh may produce a login prompt. That makes no sense. It would be much easier and simpler to fork a ssssh (super secure ssh) which has no ability to do password authentication.

Quote:
Apparently, some people have interpreted my thread as being "ssh bashing." This is not and never was the case. But, given that there is a sticky thread here that is specifically talking about "failed SSH login attempts," I think that my comments have genuine and pragmatic merit.
Come on, the second reply already says how to completely shut out ssh login attempts.

The bottom line is that if someone is using ssh and is naively using password authentication where it's not appropriate, the solution is NOT to use VPN instead. The solution is to lock down sshd to use a passphrase protected key instead.

Quote:
OpenVPN has several fundamental architectural differences which are very significant:
  1. The use of the UDP protocol,
  1. Would you say that anyone using TCP protocol instead is doing it wrong?

    Quote:
    combined with the ability to conceal itself so that "unauthorized connection attempts" literally do not occur.
    I haven't addressed this before, but honestly I'm skeptical of attempted security through obscurity. It reminds me of the port knocking craze, which really never made sense compared to just using key based authentication. I use a custom port on ssh mainly because it's considered best practices rather than thinking it seriously improves security.

    The basic problem is that there aren't very many ports - just 65536, or the equivalent of a measly two bytes worth of password length. If someone is trying to brute force a connection, it only adds TWO BYTES worth of difficulty to the security key...which is already 256 bytes long.

    If someone magically has the ability to brute force a 256 byte long key, a 258 byte long key isn't going to save you. They'll just slam all your ports rather than just one port and they'll get it soon enough. (But no, actually that won't happen - because a 256 byte long key is already too much to brute force.)

    Quote:
  2. The connection is made to a system, not to a user.
  3. Okay sure, that's sure different. Depending on the use case, this could be highly undesirable. Certainly, for my remote access use case I definitely want to lock it down to just one specific regular user. For my local LAN use case, I want something a bit different.

    Quote:
  4. The connection is integrated into the network protocol stack at one of two levels, and therefore covers all possible connections between the systems, regardless of what the users or the processes on either of those systems do or do-not do.
  5. Both parties identify themselves to each other, relying on a third party ("the CA") to establish authenticity. Mere possession of anything a password, or a public-key is not enough. The parties can verify the credentials, but cannot create credentials which would pass this same verification.
  6. Credentials can be selectively revoked. (If "you" quit or get fired, "your" badge drops dead. Mine doesn't.)
Quote:
However, I never intended to suggest that I was slamming anyone for choosing to use "ssh!" Nor that I was bashing the "ssh" technology!
Your subject line literally says we should be using VPN, not SSH.
 
Old 11-15-2017, 05:24 PM   #75
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,298

Rep: Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957
Quote:
Originally Posted by rknichols View Post
On a slightly different topic, how can you set up a VPN server so that the VPN starts automatically when the server reboots without having the server's private key exposed in an unencrypted file on that server? I'd love to use VPN as my primary access to my LAN from afield, but that VPN has to come up on an unattended reboot.
Quote:
Originally Posted by sundialsvcs View Post
I solve the problem by ensuring that the /etc/openvpn directory is owned by root and has a rwx------ permissions-mask.

However, also note that the "certificate and key" information for the server, as stored in this directory, actually serves the self-same purpose as does the "certificate and key" information in each client's credentials: it acts to identify the machine. The certificate is handed to the remote party, and the corresponding secret-key is used to decrypt whatever that remote sends back. But this secret could be replaced at any time, so long as the certificate and the key were replaced together. The mere possession of a certificate/key pair is not "the profound secret."
Possession of that signed key pair would allow someone to impersonate my VPN server. Fortuntely, I find it does not allow someone to impersonate a client if the cert has been properly restricted (error=unsupported certificate purpose).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh session "disconnects" after "route add default ppp0", any suggestion? pettha Linux - Networking 2 09-15-2014 04:38 AM
[SOLVED] Don't understand how to use SSH keys with "ssh" and "scp" commands on Lubuntu maples Linux - Newbie 12 03-10-2014 10:09 PM
Is anyone familiar with "KiTTY"? (SSH client - based on "PuTTY") haertig General 1 09-22-2013 04:32 PM
"Keep laptop running on lid close?" + "ssh via crossover cable?" FatalKeystroke Linux - Laptop and Netbook 7 03-11-2011 07:53 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 02:05 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration