4

I've recently had a conversation with a colleague (in a new job for me) around access to client's servers which are deployed in their premises.

They have said that allowing ssh access to those servers is something that any CISO would run from, so instead to access them they have a REST API interface over https. My understanding is that public key management on SSH is at least as secure as https, so apparently my understanding is not common (or colloquially correct).

What are the issues I'm missing? Is this a genuine thing or concern due to key compromise attacks (which are at least as common as CA compromises).

NOTE: I have tried searching for the answer on the interwebs. Not found anything useful yet.

2
  • 2
    I think there is some missing context. What are you accessing on the servers? How is SSH equal to REST as an access method in this use case? I can certainly see how an interactive account on a server would not be desired when a simple read-only REST API would do.
    – schroeder
    May 5, 2023 at 14:30
  • I would question your premise. Something a strict as the CIS Benchmark server level 2 still enables sshd.
    – doneal24
    May 5, 2023 at 15:43

3 Answers 3

4

The question is less about SSH vs. HTTPS as the transport protection, but about what actually can be done with the access.

SSH typically provides a powerful shell to run arbitrary commands, although what can be done with SSH could be restricted in theory (i.e. restrictive shell, execution of only specific commands, ...). Also typically no auditing is done of the activity, i.e. there is no reliable way to find out later what some user did.

A REST API instead usually provides limited functionality, although one might in theory also write some API which allows to execute arbitrary commands. Actions on the API are also usually logged, i.e. time and which user. One might also have different users (or tokens for automation) to get even more detailed auditing. And it might be restricted, which API calls or parameters are allowed for specific users.

In other words: REST API usually provides a more restrictive interface with better traceability than SSH and with more granular access control.

4
  • 1
    If you really want logging of commands, set up the users with a very restricted shell and force all, or mostly all, commands be run through sudo. Commands that give a shell could not be configured this way. Configuring sudo might be easier that writing a restrictive REST API. Advantage of the sudo solution is that you could then have trusted users with full privileges which would be hard under an API.
    – doneal24
    May 5, 2023 at 15:29
  • @doneal24: I don't understand the question as comparing just using SSH vs. writing a REST API for administration. I would rather expect that they have already an API (free or commercial) which is specifically designed for this purpose and the question is now between using this API or using SSH. And even if everything is enforced through sudo it does not mean that you get a similar detail of what is done - i.e. when editing a config file at most the fact that it was edited is logged but not what was actually changed and why. May 5, 2023 at 15:37
  • 1
    That's fair although it is not clear to me that an existing REST API is already in place. The details of the API would also be in question. Does it log which lines in a config file have been changed or just that it was changed? And, as I commented in the original question, is there an option for a trusted administrator to come in and make unrestricted (but possibly logged) changes?
    – doneal24
    May 7, 2023 at 19:22
  • @doneal24: There is nothing known about the specific implementations at the OP's workplace, i.e. how much auditing of SSH is actually done and what kind of REST API is in place with what capabilities. Therefore I can only make generic statements of how these approaches differ in typical scenarios, but not how exactly they differ in the OP's environment. But as I said: in theory SSH can be hardened for more auditing and REST API implementations might be weak. May 7, 2023 at 20:20
1

From my point of view you have more options there and more safe, for example.

  • Having a Rest API for management operations and regular operations(a web server for buying things) is a bad idea. A DDoS or a brute force attack will impact directly on your regular users and also if you have problems of capacity then your admin operations over the HTTP interface will be affected.

  • Having SSH on a prod server is perfectly fine if you can afford to have different network interface, a management interface just dedicated for that.

  • If you can not have an SSH on a dedicated management interface then your option is fail2ban that will give you more robustness in case your SSH is listening connections from the internet.

  • If you server is on AWS, GCS, Azure or others then you can share the interface and then control the access in other way with Security Groups or other access service that the cloud provider gives you.

Hope it clarifies your options.

1

I don't see a compelling argument why that REST API would necessarily be more secure. However, that depends on implementation.

For instance SSH can be configured to require public key authentication and disallow password authentication. Personally I enable SSH on the servers I manage but I only open port 22 to a few whitelisted IP addresses at firewall level (iptables, firewalld etc), that I control. So the only way to access SSH is by using one of my VPNs.

Do all this this and you've got a reasonably-secure setup - the attack surface is virtually nil.

How is access granted to that RESP API? By a user/password pair, a token, or some Oauth scheme? Note that a web service can also be restricted by using client certificates. Likewise, access to the API could be limited to certain IP addresses or address ranges, just like described above. That means access is only possible if you connect from a whitelisted location, or use VPN.

As you can see, the same techniques are available to both SSH and the API. The question is: is anything like this in place already?

Is there any protection against brute-force attempts? Just like Fail2ban can ban IP addresses attempting to brute-force SSH or other services. Fail2ban could also secure that API, as long as there is parseable log available.

All things being equal, the API limits what can be done on the server. A shell can be restricted too, but there are evasion techniques possible.

There may be plenty of reasons why they have that API, for example automation. But they could probably use Ansible (over SSH) as well.

Of course the API could have vulnerabilities too, like SQL injections, introspection attacks, you name it. APIs have been abused to exfiltrate data. Facebook, Twitter etc are testimony to that. So it could actually be an attack vector that makes the server less secure if it has severe design flaws (and there is no such thing as bug-free software). Whereas SSH is a mature protocol but the devil is in the implementation. Whatever you choose, you should always strive to reduce the attack surface so you have to protect the other layers as well and secure your perimeter.

Remaining points to consider: logging, auditing, alerting...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .