Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cockpit – Administer Linux servers via a web browser

cockpit-project.org

Post reply on HN
Print view View original

61–70 of 152 posts

Re: Cockpit – Administer Linux servers via a web browser

#61

Post by saganus »

dvfjsdhgfv wrote: post #50
kruffin wrote: 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'm neither a sysadmin nor a securyt expert, so I might be terribly wrong, but, as I understood it, password-based authentication was undesirable because the attacker could try to brute-force it.

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

Re: Cockpit – Administer Linux servers via a web browser

#62

Post by briffle »

freehunter wrote: post #59
dvfjsdhgfv wrote: post #50

Earlier quoted context omitted.

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

the part that gets me is that key based authentication is much, much more secure, as long as you have a passphrase. How many 'howtos' and other sites on the internet say to just create a key with no passphrase? Its right up there with the number of guides I see for deploying things on Redhat, that first have you disable selinux.

Re: Cockpit – Administer Linux servers via a web browser

#63

Post by freehunter »

saganus wrote: post #61
dvfjsdhgfv wrote: post #50

Earlier quoted context omitted.

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'm neither a sysadmin nor a securyt expert, so I might be terribly wrong, but, as I understood it, password-based authentication was undesirable because the attacker could try to brute-force it. 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-forci…

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

Re: Cockpit – Administer Linux servers via a web browser

#64

Post by epicide »

dalore wrote: post #27
maxaf wrote: post #26

Earlier quoted context omitted.

I haven't used it personally, but judging by the marketing video Tower is mostly an enterprise dashboard with some self-serve features that allow invocation of Ansible playbooks (or perhaps some larger unit of automation - I've no idea if they made something up just for Tower); but the playbooks would still need to be hand-coded elsewhere.

Ahh I thought you meant you got some playbooks/roles/modules written but you have a gui to say which are run where. More of a higher level. But I think I see what you mean and I like the idea. A low level GUI that lets you look up specific tasks in ansible and have it create the playbook for you at the end. That would be pretty cool and not that hard to write actually.

Combined with Ansible Galaxy, I think you get pretty close.

Re: Cockpit – Administer Linux servers via a web browser

#65

Post by evol262 »

snuxoll wrote: post #43
INTPenis wrote: post #37

I tried it on my fedora 26 last year and my impression is that it has a far way to go and a lot of problems to resolve on the way. It's nowhere near a complete server administration product that will let you avoid the terminal. Perhaps for simple tasks but I fail to see the purpose.

Cockpit itself is trying to be a "platform of sorts for modules to hook into. oVirt, for example, will install a cockpit plugin during installation of a hypervisor node allowing you to manage the local host or global cluster maintenance state and see how many VM's are running on the system (I would argue this is of limited benefit since you could just login to the oVirt Admin portal to do the same thing, but hey). So…

I'm the maintainer of the oVirt plugin.

The real advantage of it is that it allows installation of hosted engine easily, and a 'single pane' overview of a host (oVirt Node status without using nodectl, etc)

Since Cockpit wants to deal with dbus, the push is for other utilities (postfix, snmpd, etc) to publish relevant information over dbus, rather than teaching Cockpit the format of each and every configuration file on the system.

I wrote the Tuned plugin for Cockpit, and I maintain the oVirt plugin. I gave a talk at Devconf about plugin development, which is extremely easy, but the Cockpit team is small. It's very easy to write plugins for it, but even easier if they expose dbus.

That said, the cockpit API (http://cockpit-project.org/guide/latest/api-base1) makes handling files/processes from client-side Javascript in plugins simple. It's just that you'd need yet another config file parser...

Re: Cockpit – Administer Linux servers via a web browser

#66

Post by freehunter »

briffle wrote: post #62
freehunter wrote: post #59

Earlier quoted context omitted.

"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 ofte…

the part that gets me is that key based authentication is much, much more secure, as long as you have a passphrase. How many 'howtos' and other sites on the internet say to just create a key with no passphrase? Its right up there with the number of guides I see for deploying things on Redhat, that first have you disable selinux.

Yeah as someone who works in the security industry, the ubiquity of security awareness targeted at end users is both a blessing and a curse. It's a blessing because now many more people know what key-based authentication is. It's a curse because now people get mad when my report has a finding that their no-passcode single key authentication system is worse than the "use your RSA token to check out the constantly-revolving root password" system they just replaced.

Like when people use the phrase "two-factor authentication" without knowing what the three factors actually are and why they matter.

Re: Cockpit – Administer Linux servers via a web browser

#67

Post by evol262 »

dalore wrote: post #32
evol262 wrote: post #28

Earlier quoted context omitted.

It is: https://hub.docker.com/r/cockpit/ws/

It mentions atomic though. And nothing about docker on the install guide.

'atomic' is a wrapper. Just look at the dockerfile.

Given how much cockpit wants to, y'know, manage the real system, running it in docker is senseless, and there's no reason to have it in the install guide. If you want it to actually manage your host, use the dockerfile.

Re: Cockpit – Administer Linux servers via a web browser

#68

Post by evol262 »

guhcampos wrote: post #60
dmoreno wrote: 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.

Again, Cockpit does not explicitly deal with systemd.

Cockpit deals with dbus, and systemd is conveniently available there (hostnamectl, etc). storaged, networkmanager, and other functionality is not dependent on systemd, so it's really just the system journal, changing the hostname, and checking service status which would fail without systemd.

Docker is not required at all either, though it's an option.

Re: Cockpit – Administer Linux servers via a web browser

#69

Post by dvfjsdhgfv »

saganus wrote: post #61
dvfjsdhgfv wrote: post #50

Earlier quoted context omitted.

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'm neither a sysadmin nor a securyt expert, so I might be terribly wrong, but, as I understood it, password-based authentication was undesirable because the attacker could try to brute-force it. 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-forci…

> Key-based auth doesn't have this flaw so it's arguably safer in that it has one less entry point.

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

Re: Cockpit – Administer Linux servers via a web browser

#70

Post by INTPenis »

snuxoll wrote: post #43
INTPenis wrote: post #37

I tried it on my fedora 26 last year and my impression is that it has a far way to go and a lot of problems to resolve on the way. It's nowhere near a complete server administration product that will let you avoid the terminal. Perhaps for simple tasks but I fail to see the purpose.

Cockpit itself is trying to be a "platform of sorts for modules to hook into. oVirt, for example, will install a cockpit plugin during installation of a hypervisor node allowing you to manage the local host or global cluster maintenance state and see how many VM's are running on the system (I would argue this is of limited benefit since you could just login to the oVirt Admin portal to do the same thing, but hey). So…

That's great. Before I tried cockpit I tried Kimchi which was also a sort of base for plugins, they had a libvirt plugin.

But it was far from finished and required a lot of work. I ended up having to go to the terminal to solve things a lot of the time.

So being a Fedora/RHEL fan I will definitely try cockpit with libvirt or ovirt and keep an eye on how it develops. But I also expect the same issues I saw with Kimchi, being forced back to the terminal to solve issues the gui can't do, or for some reason gets stuck on.

Post reply on HN