6 ms·

Why does it require that the server has password logins enabled? This seems contrary to every "secure your server" guide I've seen and opens your server up to t

Why does it require that the server has password logins enabled? This seems contrary to every "secure your server" guide I've seen and opens your server up to the password guessing game. It seems like a cool product, but that's a huge non-starter. 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.

reacharavindh 9y ago
Great value-add of reading HN comments! I will wait until they get rid of this crazy requirement to consider using it.
- derimagia 9y ago
  Sounds like a lie to me. 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.
thechriswalker 9y ago
I don't think it does. That quote is from the section explaining how to configure "Password" authentication. i.e. to use Password authentication, you must enable it on the target server. It then goes on to list how to use Kerberos or Public Key methods.
- kruffin 9y ago
  You are right, I missed the one liner above this that stated it needed one of these methods: [password, kerberos, or public key]. However, it does sound like if you use the docker image that you need password logins on the primary machine unless you modify the docker image to add a public key. I may just be reading wrong again though. [Edit]: This diagram was really helpful: https://raw.githubusercontent.com/cockpit-project/cockpit/master/doc/cockpit-transport.png https://raw.githubusercontent.com/cockpit-project/cockpit/ma...
- kruffin 9y ago
  Reading again, it does look like the installation is limited in some way if you choose to use public keys and your user doesn't have the privileges (without sudo) necessary for some of Cockpit's commands it tries to run. 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.
dvfjsdhgfv 9y ago
Probably because these "security guides" just repeat what others said without any real consideration? 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.
- dvfjsdhgfv 9y ago
  I'd appreciate a good argument apart from downvoting. In every discussion I had about it with fellow sysaddmins we agreed the convenience of passwordless logins can't be considered a security feature in spite of what someone wrote and what others repeat.
  - crypt1d 9y ago
    No glove fits everyone. There are many answers to the problem and each depends on the set of circumstances in which your service exists. Security is, simply put, risk management. To put things into a context: the 'average Joe' user is rarely going to be targeted specifically - which means that the biggest attack vector of the average user is brute forcing by bots and phishing attempts or maybe a key/password stealing malware. Hence your argument that 'key-based auth' just shifts the attack vector is partially incorrect because automated attacks do not focus on a specific target but on a specific vulnerability - like password guessing bots for example which move from IP to IP and try a bunch of simple password. If these passwords don't work, the bots will not try to hack a dev's workstation, they'll just find an easier target. 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).
- freehunter 9y ago
  "Common knowledge" is a big problem in the security industry, like you mentioned. It's common knowledge that you need a 32 character randomly generated password with special characters and numbers and mixed case, right? But actually that's less secure, and now security folks have to work overtime to convince people otherwise. 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.
marmaduke 9y ago
You could run a dedicated SSH server listening on local host, accessed through a tunnel. Not ideal but not non starter either, if the benefits of Cockpit are that big.

reacharavindh 9y ago

Great value-add of reading HN comments! I will wait until they get rid of this crazy requirement to consider using it.

derimagia 9y ago
Sounds like a lie to me. 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.

thechriswalker 9y ago

I don't think it does. That quote is from the section explaining how to configure "Password" authentication. i.e. to use Password authentication, you must enable it on the target server. It then goes on to list how to use Kerberos or Public Key methods.

kruffin 9y ago
You are right, I missed the one liner above this that stated it needed one of these methods: [password, kerberos, or public key]. However, it does sound like if you use the docker image that you need password logins on the primary machine unless you modify the docker image to add a public key. I may just be reading wrong again though. [Edit]: This diagram was really helpful: https://raw.githubusercontent.com/cockpit-project/cockpit/master/doc/cockpit-transport.png https://raw.githubusercontent.com/cockpit-project/cockpit/ma...
kruffin 9y ago
Reading again, it does look like the installation is limited in some way if you choose to use public keys and your user doesn't have the privileges (without sudo) necessary for some of Cockpit's commands it tries to run. 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.

dvfjsdhgfv 9y ago

Probably because these "security guides" just repeat what others said without any real consideration? 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.

dvfjsdhgfv 9y ago
I'd appreciate a good argument apart from downvoting. In every discussion I had about it with fellow sysaddmins we agreed the convenience of passwordless logins can't be considered a security feature in spite of what someone wrote and what others repeat.
- crypt1d 9y ago
  No glove fits everyone. There are many answers to the problem and each depends on the set of circumstances in which your service exists. Security is, simply put, risk management. To put things into a context: the 'average Joe' user is rarely going to be targeted specifically - which means that the biggest attack vector of the average user is brute forcing by bots and phishing attempts or maybe a key/password stealing malware. Hence your argument that 'key-based auth' just shifts the attack vector is partially incorrect because automated attacks do not focus on a specific target but on a specific vulnerability - like password guessing bots for example which move from IP to IP and try a bunch of simple password. If these passwords don't work, the bots will not try to hack a dev's workstation, they'll just find an easier target. 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).
freehunter 9y ago
"Common knowledge" is a big problem in the security industry, like you mentioned. It's common knowledge that you need a 32 character randomly generated password with special characters and numbers and mixed case, right? But actually that's less secure, and now security folks have to work overtime to convince people otherwise. 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.

marmaduke 9y ago

You could run a dedicated SSH server listening on local host, accessed through a tunnel. Not ideal but not non starter either, if the benefits of Cockpit are that big.