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.

Using both ssh and VPN is a reasonable choice.


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).

There is no need to be mysterious about it. A certificate contains a public key encoded within it.

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).

That answers the question. Thanks

jlinkels

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.

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.

You keep on repeating this thing, with funny colors and emojis, as if it were a real problem. It just isn't a problem.

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?

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.

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?

No, that's what the keys are for. Ssh is extremely vocal when they don't match what is expected.

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.

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.

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.

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!"

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.

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!

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?

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.

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.

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.

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:

   The connection is made to a system, not to a user.

   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:

   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. 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. Credentials can be selectively revoked. (If "you" quit or get fired, "your" badge drops dead. Mine doesn't.)

Your subject line literally says we should be using VPN, not SSH.

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).