SSH Public Key Authentication vs Username/password for API Access

Question

I have a linux device that will be making periodic call to an API server, say everytime the system boots up. Everytime then it should authenticate itself and then do its thing.

I can either store the username/password in a .config file, or create a public id_rsa.pub SSH-key.

My question is this: Why is the SSH authorization considered better? I mean if somebody gets access to my linux machine, then they can read both username/password OR the SSH key and they can then copy these information to their own laptop.

Am I missing something here? Note These username/passwords are all generated by me and will all be random 256bit strings. So the typical reasoning of people will use weak and predicable passwords does not apply here.

Update

How about the following approach:

You have a seed number, which will be a md5 of something. This value is stored on the server and every machine.

Now, during authentication, a client will send two strings,

str1 = md5(timestamp + random());
str2 = md5(str1 + seed);

The server will receive these two numbers and will accordingly recalculate str2 from str1. If str2_from_server == str2, then a token is generated and sent back. This token will expire with one use or after a period of time.

The tokens will be saved in a table key/value pair of str1 str2 token and can never be reused again (realistically, this table will be cleared every once in a while so that it does not grow infinitely large).

Is this any superior/inferior to SSH?

Answer 1

There are several differences.

First, by setting up your API server to accept username/password (as opposed to only allowing access via keys, which is increasingly a best practice to do) you potentially decrease its security in general, as, now, users with weak passwords on the system (or, worse, services that you install which may have hardcoded default passwords) will make it possible to breach your server. Brute-force attacks are suddenly an option for those wanting to break into your system (which, if you run an SSH server on a public IP you are guaranteed to see almost immediately). Disabling ssh login via passwords and requiring login keys is as simple as setting: "PasswordAuthentication no" in your sshd_config and restarting the sshd service (or your server). I do this on every linux box I build as one of the first steps. Plus, this encourages setting up a very long and random password, since (if you set up /etc/sudeoers properly) you will never actually use it for anything. :)

Second, with the ssh key option, you can easily set up the authorized_keys file in such a way that it will:

1. Only allow access from a specific IP; and
2. Only allow the accessing user/script to execute a certain command.

This way, even if someone compromises your client box, the stolen key can't be used to log into your server from anywhere else in the world, and, if you set it up properly, it can't even be used to login from your client for anything other than what you allowed. For example, I use this to set up accounts/keys that can do nothing except rsync with certain options from a certain folder. So, even if the key were stolen, the attacker gains nothing other than being able to execute the command that the client machine is executing itself anyway, and only from the client's IP, nowhere else. I.e., gaining the key has not allowed the attacker to compromise the API server. You might be able to restrict an account that's password-based to only execute a certain command or only login from a certain IP, but I've never seen this done and don't know how easy it is.

Third, when you want to give access to your API server to another person/system in the future, and you want to use passwords, you run into the key distribution problem (ironically enough). I.e., you have to have a secure channel to exchange the initial account password so that the user can log in. With SSH keys, all they have to do is email you their public key (which isn't something needing security), and (as long as you trust the email is from them, which there are ways to ensure), and you can give them access.

So, I hope this has convinced you that there is value to using keys (and, really, you should not be using password-only access on anything; keys or 2FA for public services are the only way to go :-)). Cheers.

Answer 2

Why is the SSH authorization considered better? I mean if somebody gets access to my linux machine, then they can read both username/password OR the SSH key and they can then copy these information to their own laptop.

Yes, true, if someone gains full access to your machine, you are in trouble either way.

Am I missing something here?

Yes. All the situations in which an attacker has not already gained full access to your machine. There are easily implemented attacks that are possible with username/password authentication that are not possible with SSH keys.

Answer 3

Well, if you drop the idea for username/password (that is not secure at all for this use) you could implement a chrooted environment for the ssh-client to connect into. using ECDSA or RSA Public key encryption, (you ship the private key with the app, and store the authorized keys outside of the chroot).

Especially if you make a "dropbox" for the clients to write to, or make a FIFO/LIFO special file with just write acces from the chroot environment. you can let the client safely write to the server without giving it any read access whatsoever.

If it's just a file you want to upload, utilize the build-in sFTP client of ssh. This would mean you can just upload a file directly, without giving shell access at all in the chroot environment.

If you trigger the ssh connection through a script on the "client" you do not need to have a ssh.config file. You can just specify the command line arguments you want in the script.

As for why a key is better, security-wise, we just need to look at how the SSH system uses the keys:

• SSH-client asks for SSH server (what version and key exchange / authentication types do you support)

• SSH-server replies with capabilities and public key token.

• SSH-client answers with a secret encoded "encryption token"(a operation of the public key token with some encryption magic) that is signed with your private key.

• SSH-server authenticates the signature (public key decrypts the message) and validates the encryption token, it then replies its own encryption token based, using similar ways as the client.

• SSh-client validates the received encryption token.

• SSH-server sets up a secure tunnel using the new keys. than starts the shell.

• ssh-client sets up the secure tunnel endpoint and starts the shell proxy.

  yaay ssh connection established.

I suggest you read up on SSH and keys and chrooting so as to better understand what you are trying to do.