Live data from Hacker News

Cockpit – Administer Linux servers via a web browser

cockpit-project.org

51–60 of 152 posts

Re: Cockpit – Administer Linux servers via a web browser

#51
post #40

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 pri…

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

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.

Re: Cockpit – Administer Linux servers via a web browser

#52
post #46
post #15

Personally I'd much rather see a GUI that can help string together snippets of Terraform/CFN and Ansible/Chef/Puppet/Salt/whathaveyou. A visual IDE for infrastructure automation, if you will.

So the idea is that you would choose your changes in the GUI, but instead of actually changing the target, it spits out the required code to do it for you in a repeatable way? I would definitely find that useful for Terraform and Cloudformation. Searching for it, I see that AWS has a tool targeted at that: Cloudformation Designer. https://aws.amazon.com/blogs/aws/new-aws-cloudformation-desi... https://docs.aws.amazon…

Example Cloudformation Designer stack diagram (click View In Designer or scroll down for a screenshot):

https://userify.com/docs/enterprise/cloudformation/

If you have an AWS account, you can actually modify/fork the template on the fly by clicking on one of the objects in the diagram and editing its properties (which edits the YAML CloudFormation template in the background).

Re: Cockpit – Administer Linux servers via a web browser

#53
post #44
post #41

Does it have an SSH terminal built right in the browser? Not clear from the screenshots or documentation. If not you could also use Gate One[1]. [1] http://liftoffsoftware.com/Products/GateOne

Yes it does.

I wonder what library they use for it. The one used by VS Code seems to be nice and its developers active.

Ah, found it: https://github.com/xtermjs/xterm.js

Re: Cockpit – Administer Linux servers via a web browser

#54
post #7

what was wrong with webmin? (ducks)

https://nvd.nist.gov/vuln/search/results?adv_search=false&fo...

Yeah, getting Webmin security right is possible but very challenging. Whenever I'm doing a security assessment at a client and I see traffic to/from servers on port 10000 I always make a note that there's probably some vulnerabilities there that our pentest guys will want to explore.

I have no idea if Cockpit is any more secure, but Webmin does have its fair share of security issues.

Re: Cockpit – Administer Linux servers via a web browser

#55
post #40

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 pri…

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.

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.

Re: Cockpit – Administer Linux servers via a web browser

#57
post #4

Its pretty, usable, friendly, however No one is going to use this to manage more then a few systems.

If you need to manage a large and diverse infrastructure you should also consider Mist.io: https://github.com/mistio/mist.io

Disclaimer: I'm one of the founders

Re: Cockpit – Administer Linux servers via a web browser

#59
post #40

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 pri…

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.

"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.

Re: Cockpit – Administer Linux servers via a web browser

#60
post #30

Does it work on non fedora/redhat? Does it need an agent on managed systems? I'm developing a somewhat similar system[1], based purely on very easy to develop plugins, agentless, and integration with third parties where needed (Prometheus, for example).But without big corporate backup it is being difficult to keep the development pace. [1] https://github.com/serverboards/serverboards/

I've used it before on Ubuntu and it worked just fine. As far as I understand, Cockpit deals directly with Systemd and Docker, so any system based on Systemd should just work.
Post reply on HN