I recently had a conversation with my boss and an IT contractor that they use. My request to allow outside access to a machine on the network via SSH was denied on the grounds that SSH is insecure. I asked for an explanation and unfortunately did not understand it - the contractor stated SSH was insecure but did not know why.

Why is SSH insecure? There seems to be something I missed during our conversation that I desperately want to understand.

My proposal for SSH included using key-based access and fail2ban.

UPDATE: To explain the discussion, as soon as I asked the contractor why he thought SSH was insecure he said, verbatim, "I don't know" and proceeded angrily with an increased tone of voice for the rest of the conversation. I tried to extricate myself but had to fend off some strawmen to avoid looking completely incompetent due to his badgering. I made the arguments that most of the good answers to this question make below and they were promptly ignored.

Those same answers are extremely unconvincing if viewed with a skeptic eye. I'm not sure if my (which is the IT contractor's) question sets an unreasonably high burden of proof which can never be met, for either direction. If that is the case it would be wise to speak to that.

| |
  • 23
    I think it's not so much "insecure" as that it's that external SSH access is less secure than no external access. – Shadur Mar 25 '17 at 14:51
  • Also it is good to take into account that SSH is quite old (and thoroughly tested) but using the older versions (ssh1 protocol for example) is quite insecure. the newer (and to my knowledge only used) ssh2 protocol can be quite secure, it depends on the keys / ciphers / security of the device on how secure it is. In general it is more secure than an HTTPS connection due to the defaults that uses the highestlevel of TLS connection that is possible for each connection (so TLS 1.2 / 1.3 for most connections) something not possible for widespread use in websites. – LvB Mar 27 '17 at 13:39
  • 1
    To answer the question, speculatively, the security admin was telling you that they didn't trust you with their company's entire system, but telling you politely. It's not that SSH isn't secure, but that a hacker could hack your computer, and then get access to the company's network, and they would have no way of knowing the difference. For a minor troll, try asking for a rlogin account and see if that gets you anywhere. – Chloe Mar 27 '17 at 16:51

Firstly, anyone who says "this isn't secure, but I don't know why" is completely negating the right to speak from a position of authority on the matter.

A few people have touched base on why opening an attack vector is often discouraged, but here's some things that negate the need for fear if used correctly:

  • VPN into the network, then SSH to the device
  • Use a non-standard port
  • Use private key pairs
  • Implement tools like fail2ban
  • Deny root user logins

Honestly, just one of those options makes hacking significantly harder. Implementing at least two means you can use SSH worry free.

That IT contractor should really consider a new trade.

| improve this answer | |
  • 1
    Why is using a VPN any safer than using SSH directly with keys? Especially if the VPN gets you inside the target network's peripheral defenses and possibly opens up a whole panacea of target computers. – Lawrence Dol Feb 14 '18 at 3:57

SSH is not typically considered insecure in and of itself but it is an administrative protocol and some organizations require two or more layers of control to get access to an administrative console. For example connecting via a VPN first then opening an SSH session which connects through that VPN. This simply provides multiple layers of defense in depth and prevents your systems from being directly affected by the latest SSH vulnerabilities.

Note: This is NOT a weakness in SSH itself and many organizations will still expose SSH on high TCP ports for use as SFTP servers then have a script move data to and from that system (not allowing the external SSH/SFTP server to connect to the rest of their network).

All protocols eventually have vulnerabilities so if you can require the use of two different ones (i.e. IPSEC VPN and SSH) and stay disciplined about remediation efforts when vulnerabilities are discovered then the window of time where known vulnerabilities exist in both protocols at the same time on your network should be very small. Statistically, the requirement for using two protocols should reduce the amount of time where you would have a single protocol exposed with a known vulnerability (assuming you actually patch/remediate vulnerabilities).

As a poor text graphic look the following:

Time ---> 

IPSEC ------------------------     ----------------

SSH   ---------       -----------------------------

Versus having just SSH, or a VPN, by itself:

SSH   ---------       -----------------------------

In the first example when an SSH vulnerability came out there wasn't one for IPSEC and vice versa so there was never a time, in this crude example, where your systems had vulnerabilities at both layers. This defense in depth is what is protecting the system behind these protocols which occasionally may have vulnerabilities.

In the second example, SSH by itself, the moment there is a vulnerability, or a password breach, or any number of other issues, an attacker can directly access your vulnerable system during the window of exposure.

I would ask if any other administrative protocols are being exposed and if so then you can question the technology bias but most likely you may be in an organization that doesn't allow any administrative protocols to be accessed directly from the Internet.

| improve this answer | |
  • 10
    @R0b0t1 - Tell them to copy all the data to a hard drive and burn all the remaining copies. Dig a 30m hole, place the drive at the bottom and fill with concrete. That would certainly make the data more secure that it is now. They want to pay in usability for security so that is a completely valid plan. – grochmal Mar 25 '17 at 16:53
  • 9
    @R0b0t1 Why not just access the server over SSH once on the VPN? This should satisfy everyone's needs: it's the most secure of this type of setup (and what my company, a financial services firm, does), allows you to access this server while out of the office, and mitigates situations where a flaw is found in the OpenSSH server or the SSHv3 protocol. – Stephen Touset Mar 26 '17 at 9:58
  • This answer makes it clear, to me, that the objection isn't "SSH is insecure," but is really "Using just SSH is insufficiently secure." It doesn't hit the data security triad of Confidentiality, Integrity, and Availability sufficiently for the objector's preference. – Nanban Jim Mar 27 '17 at 20:20
  • @NanbanJim Encryption provides confidentiality, message authentication code provides integrity. You can use an AE cipher mode to take care of the integrity or MAC (hmac or umac) I believe a well hardened SSH server and client can hit the data security triad easily – rhymsy Nov 20 '18 at 5:40
  • @rhymsy And that is your prerogative. You're not the one objecting. – Nanban Jim Nov 20 '18 at 13:43

I asked for an explanation and unfortunately did not understand it - the contractor stated SSH was insecure but did not know why.

Why is SSH insecure? There seems to be something I missed during our conversation that I desperately want to understand.

Treating security as a binary "secure" or "not secure" reflects a poor understanding of security; security is always a continuum, and nothing is perfectly secure.

The contractor in question seems to have a large lack of information about SSH if he/she can't even state why SSH is insecure, but adamantly believes that it is. Ignorance breeds fear, and my guess is the contractor is reacting to fear rather than knowledge.

SSH is no less secure than VPNs from major vendors. VPNs have security vulnerabilities too, and aren't "made of magic". We know this from the various leaks from the NSA, and there's no reason to believe these vulnerabilities are in the hands of only the NSA.

The real question comes down to need for access vs need for security, not one protocol over another. Remote access will likely decrease your security somewhat. Two remote access methods will decrease your security method further. Whether you enable one or more methods of remote access should be judged by the tradeoffs involved, not by maintaining a false sense of "security" as a binary concept.

| improve this answer | |
  • 4
    The contractor they use seems to have no or a very limited Unix or Linux background and to mainly support Windows. I tried to offer the argument that Windows would be susceptible to the same arguments presented against the use of SSH ("absence of evidence is not evidence of absence" in regards to extant security vulnerabilities) but, again, I am apparently misinformed as this is not the case. – user142998 Mar 25 '17 at 22:51
  • 2
    Here I must agree. I only ever hear this stuff from people who do not know what ssh truly is. – Joshua Mar 27 '17 at 1:41
  • +1 "nothing is perfectly secure" - One could imagine a perfectly secure system, except no-one would be able to access it. Passwords or even keys are vulnerabilities- intractable ones, in some cases, but they still provide access and any access point is a potential vulnerability. – Delioth Mar 27 '17 at 19:20

What is insecure, exactly?

To state it shortly, "Why is external access to SSH considered insecure?": it is not "SSH" which is insecure, it the "external access" part of your question which is.

SSH is just one technical mean amongst others to open your internal network to the outside world (which highly risky). It may be used, either standalone or associated with other technologies, in order to implement your remote access policy.

The remote access policy is the formal definition stating who can access what, when and from where, it defines all the rules which will then be implemented using various technical controls which will, in turns, provide proper authentication, authorization and audit services. All of this, of course, need to be properly documented and maintained.

Of course, you could just go on without all these administrative and maintenance burdens, but here is the point: taking such shortcut is precisely what would be insecure in your question.

So, why is external access to SSH considered insecure? Because it would cost too much to implement it properly in regards to the return on investment expected by the company.

Cost question

Cost here is not about buying software, it will merely be about paying people time first to design and setup this service, and then to maintain it over time (while these people are occupied with this there are other tasks they won't be doing). The actual cost will therefore be very dependent on the salary, current competencies and the complexity of your current infrastructure.

From a technical point-of-view, key based authentication and fail2ban is a good and well documented solution. Running this on high ports will also get it out of the majority of bots sight. But this will not prevent for instance a genuine employee from connecting to the internal network from his family computer overflowing with worms, viruses and backdoors of all sorts, thus unwittingly comprising the company's network. This is one of risks you may have to address.

From a management perspective chances are that the "boss" may be more interested in (monetary) weighting the various risks against the expected return on investments: what this will cost to setup and maintain? How much will this allow the company to earn or economize? What could it cost in case a disaster happens?

Risk is always there, with everything. If you manage to show that from a business perspective opening the internal network (or maybe some well-defined parts of it, which would be an effective way to reduce the risk) will be a profitable move for the company, you will have done half if not most of the journey. How to do it will then be just a matter of technical choices depending on what you planned to do. But you certainly must solve the question from a business and functional point-view before going down into technical details.

| improve this answer | |
  • What is the proper implementation? What cost does it have over the default implementation? I was proposing a system involving key based authentication and fail2ban. – user142998 Mar 25 '17 at 15:57
  • 1
    @R0b0t1: Hi, estimating the cost of a change in a company may be complex to very complex depending on the company, and is far beyond the cost of buying software. I've added a new section to my answer, I hope it may benefit you in any way :) ! – WhiteWinterWolf Mar 25 '17 at 16:41
  • Well, setting up the service took me about 30 minutes. Maintenance is another issue but I could have trained one of the engineers to do it or could have been on call (something they admittedly have some resistance to). I believe I followed most of the advice in your comment w.r.t. cost. Unfortunately, my employer was left with the impression that their network was more secure sans any remote SSH access regardless of how it was set up, and based their choice to disallow it on this basis – user142998 Mar 25 '17 at 16:47
  • 3
    @R0b0t1: Having no door is indeed more secure than having a door, as safe it could be. While setting up SSH and fail2ban may be quick at a personal scale, for a corporate network you may also need to setup network compartmentalization to ensure that SSH users cannot access more than they ought to, and proper auditing to detect unusual activity. Risks are there, this is a fact, and if there is no significant business advantage in allowing such access then indeed the expected reaction is for the management to reject the request. – WhiteWinterWolf Mar 25 '17 at 17:08
  • That line of thinking still seems like specious reasoning. How, exactly, would the authentication mechanisms of SSH be subverted? SSH relies on mature technology that is not considered suspect elsewhere. Speculation in the vein of phishing is not something unique to SSH and as such I feel it doesn't address my question – user142998 Mar 25 '17 at 20:17

SSH is not insecure, however it is not necessarily good practice to expose SSH to the internet for fear of remote compromise. By opening SSH to the world, you invite unnecessary visitors who will run bots against your deployment trying to get it. Even if they don't succeed, it's still unnecessary; if they do succeed, you could be in for a world of hurt. If the exposed system becomes compromised, it's easy to install a persistent backdoor and use this system as a leverage point to attack others in the network.

If you do expose it on the internet, disable password authentication and disable root login, only allow key-based access. If you must allow passwords, don't allow it for root and use a 2-factor solution with randomly generated passwords.

| improve this answer | |
  • 1
    How might these bots succeed? I have read it is best to disable passwords and use key authentication. Is key-based authentication insecure? – user142998 Mar 25 '17 at 5:10
  • 4
    I said it's not good practice. Security is nothing more then risk vs reward. The risk is exposing yourself to unknown 0-days or a user's laptop being compromised that exposes the keys. This is true for all exposed services. Obviously any laptop can be used to infiltrate a network but having an already open port like ssh makes that access easier once obtained. Only you and your organization can determine if the risk is worth it. I already stated I have SSH open on my VPS, I'm merely providing insight on some reasons it's bad practice. – Andrew Mar 25 '17 at 16:02
  • 1
    Yes. Security is entirely a risk-based game. You must analyze your environment, your configurations and your needs in order to determine what risk is worth accepting and to what degree a service must be configured in order to be considered secure in your environment. I'm simply stating that it's BAD PRACTICE to do, not that it can't be made to be a secure remote access method. Look around at hundreds and thousands of poorly configured servers with SSH that act as spam hubs for email and phishing sites. Historically, it has been configured poorly and left for malicious use. – Andrew Mar 25 '17 at 20:33
  • 3
    @R0b0t1 Misconfigurations happen. For instance, someone updates OpenSSH, and accidentally resets the configuration to allow password-based authentication and allow root to authenticate. Requiring access through a VPN before having access to SSH is defense in depth, and not necessarily an unreasonable security requirement. – Stephen Touset Mar 26 '17 at 10:00
  • 2
    OpenSSH and the SSH protocol are, as far as we know and independent of everything else, secure — the contractor involved was simply wrong on that front. That said, the fundamental notion of running a root-owned process that gives shell access to a machine on a public network interface is, by some measures, an unacceptable security risk which warrants layered defense. This doesn't miss the point of your question at all: the contractor poorly expressed and overstated his technical concerns, but the probable root of his concerns is reasonable. – Stephen Touset Mar 27 '17 at 8:33

SSH may be considered insecure because your organization may not have policies in place to control credentials.

Over time employees come and go. They may also change roles. If there is no mechanism to disable SSH access when needed, SSH would be insecure. This does not indicate a problem with the protocol or software. Rather its a general problem applicable to any remote access.

Any organization allowing SSH access would probably want to prevent password compromise by dictionary attack (in addition to making sure the SSH software is kept up to date). They could choose to limit failed login attempts perhaps by IP. They could choose to not allow password login via SSH at all, or as others mentioned could require dual factor authentication. However if they don't have a policy then the best policy may be to not allow SSH remote access.

If the contractor doesn't know why it might be insecure then they may actually be making the best decision to not allow remote access.

| improve this answer | |
  • 1
    Last line is highly relevant: "If the contractor doesn't know why it might be insecure then they may actually be making the best decision to not allow remote access." – Nanban Jim Mar 27 '17 at 20:26
  • "not allow remote access" - the danger here is that there is presumably a requirement for remote access and that a badly informed individual has some sort of control over how this will be implemented. There is a real danger of ending up with a much worse solution than ssh here. – symcbean Mar 28 '17 at 11:53