The target server will need to have password based authentication enabled in sshd. When this is setup for the first time, Cockpit will ensure that the user connected to primary server has the same password on the secondary server. The target server will need to have password based authentication enabled in sshd. When this is setup for the first time, Cockpit will ensure that the user connected to primary server has the same password on the secondary server.It then goes on to list how to use Kerberos or Public Key methods.
[Edit]: This diagram was really helpful: https://raw.githubusercontent.com/cockpit-project/cockpit/ma...
Note that when a user is authenticated in this way [public key] the authentication happens without a password, as such the standard cockpit reauthorization mechanisms do not work. The user will only be able to obtain additional privileges if they do not require a password.
I will wait until they get rid of this crazy requirement to consider using it.
The web server can also be run from the cockpit/ws docker container. If you are running cockpit on an Atomic Host this will be the default. In this setup, cockpit establishes an SSH connection from the container to the underlying host, meaning that it is up to your SSH server to grant access. To login with a local account, sshd will need to be configured to allow password based authentication. Alternatively you can setup a Kerberos based SSO solution.
AKA, it is up to your SSH server to grant access to the container.In fact, using key-based authentication just shifts the weak point from one server to another, and, if implemented incorrectly (let's login without passwords to several servers - how convenient!), it's a security disaster. People need to think rather than follow recommendations blindly.
So for the average user it makes sense to move to key based auth because it will remove a big attack vector. It is still possible that the workstation where the private key resides becomes compromised, but thats another attack vector that needs to be addressed by different security methods (eg, passphrase on the private key).
And it's common knowledge that passwords are super insecure and should be replaced, but oftentimes the people replacing them don't understand that it's possible to replace passwords with a less secure system, and don't have the skills necessary to judge that risk.
Key-based systems do have their risks. If I compromise your dev machine (probably using a simple password), I now have free access to all the machines your key unlocks.
Defense-in-depth is important, as well as a strong IAM system. You need physical security to protect your dev workstation, coupled with a strong login system to your machine, hopefully a VPN (locked with a physical token) or local network requirement to get onto your production servers, and then break-the-glass methods to check out permission to escalate your privileges when needed, followed with a keylogger for your admin session and attestation that your break-the-glass in production was necessary.
That being said, if you're looking for a replacement for logging into your production machines over the Internet with a simple password... key-based authentication is lightyears ahead of what you're doing. Passwords are far too easy to guess or brute force.
Like when people use the phrase "two-factor authentication" without knowing what the three factors actually are and why they matter.
The real reason is passwords are weaker is first and fore most people. People reuse passwords or choose ones that are too short or simple that brute force becomes possible. If passwords where chosen at random and of proper of length they can be equally as strong as a key. Further, passwords basically functions the same as a key symmetric cryptography. People just don't like to memorize long random strings. (Although many apply key stretching since passwords may be of lower entropy).
Second when it comes HTTP it really only supports basic and digest authentication which is based on MD5, and further is susceptible to offline brute force attacks, and a down grade attacks to basic without TLS.
Thusly, most websites just send your password over TLS. However, because each site basically can handle passwords however they want they can store them in plain text. Secondly, if your TLS sessions is compromised you sent the password over over that connection it can be compromised. Sadly, the browsers don't support J-PAKE which by the way has an RFC.
https://en.wikipedia.org/wiki/Password_Authenticated_Key_Exc...
I guess my point is password authentication can be just as secure, and really they are just shared secret crypto-systems. Problem is people choose low entropy passwords first and foremost. So just generating a key and saving locally avoids that issue.
Websites (HTTP) can use client X509 side certs as authentication and this gets rid users choosing bad passwords. However, if browsers implemented J-PAKE you don't have to worry about accidentally visiting the site via plain text will comprise your password or a comprised certificate authority. You could always validate the certificate yourself since we don't have something like J-PAKE in place.
For SSH long passwords can be just as strong, but you must verify the fingerprint matches your servers else you may get MITMed. Although if people see a server with SSH using password logins. They may try to brute force the password which may be annoying for the system admin. So the system admin enables key based authentication stop people from trying. Even though you have a high entropy password and your not worried about a brute force attack. The attacker does not know that so they will try anyways.
Key-based auth doesn't have this flaw so it's arguably safer in that it has one less entry point.
On the other hand, not sure I fully understand your argument. You are saying that not being vulnerable to password brute-forcing is not enough since you could still hack the server? or what exactly do you mean by "just shifts the weak point ... to another"?
I'm not the person who made that argument, but I can give you my reasoning to support it.
Your key is on your laptop and unlocks your server, now your server is safe. But your laptop is just secured with a password. I brute-force the password on your laptop, and now I have no barriers preventing me from accessing your server. Your server is secure, sure, but the risk was just pushed back to your laptop which may be more or less easy to compromise than your server (depending on the threat).
I'm not arguing that key-based authentication isn't a good step forward. If you're using passwords on your Internet facing servers, stop doing that and start using keys. But you also have to protect your keys and any machine those keys are installed on, otherwise you're just shifting the weak point to another machine.
But I agree, making it more difficult (force the user to consult the man page and look up the flag -- see openssl cert generation) would be better.
I’m okay with this, personally. What’s riskier: a public server listening on port 22 for any SSH traffic or my personal laptop which doesn’t accept random requests from the entire internet and is almost never out of my sight? And even if someone compromised my machine (e.g. theft), they probably don’t care or even understand what SSH keys are; they’ll probably just wipe the thing and sell it on the black market.
That’s not a good reason to ignore sound security practices, but threat model-wise, my laptop is much less likely to be targeted and successfully compromised physically by someone who wants to SSH into my build server.
I have a picture I like to use in my presentations where I was at a mostly-empty family restaurant and the person sitting next to me (alone) had their laptop sitting out and went to the bathroom without even locking the screen. In 15 seconds I could have popped in a USB drive and copied all of his SSH keys (and more) without anyone ever noticing. It could have been done before he even reached the bathroom door, let alone came back. I don't think you would do this, of course, but some people do. And your coworkers might.
On top of that, about 25%-30% of security incidents are caused by insider threats. Considering how easy attacks over the Internet are, that's an absolutely massive number. Even if your laptop never leaves your desk, it's entirely possible someone within your company might want to do some harm to you or the company and it might be the desktop support technician hooking up your new monitor while you grab another cup of coffee.
Your point about what's riskier is completely true: if you have Internet-facing servers using passwords, stop that and use keys. But when you do that, you need to study up on the new risks you may not be aware of. Security shouldn't just be a curtain you close. Companies/people who don't understand this love paying me shitloads of money to explain it to them :)
This is exactly what people think when reading the guides. In fact, it's not that there is one less entry point, but this entry point was moved and now exists on another machine together with the key. And since many people use one workstation to log in to several servers, you now have one single point of failure (an equivalent of using one password for all servers).