Allowing Root Password Login via SSH to Dragonfly BSD
-
All other surviving BSD products are just rebranding or derivatives of one of these: TrueOS and FreeNAS are both derivates of FreeBSD. pfSense from OpenBSD I believe. GhostBSD is from one of them.
-
Mac OSX and Dragonfly both came from the FreeBSD ecosystem. But they each use a kernel that is not derived from FreeBSD's current kernel. In many ways, FreeBSD split from DragonFly So in a way, Mac and FreeBSD sort of came from Dragonfly because dFly is the "original" FreeBSD before FreeBSD changed its kernel.
-
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
All other surviving BSD products are just rebranding or derivatives of one of these: TrueOS and FreeNAS are both derivates of FreeBSD. pfSense from OpenBSD I believe. GhostBSD is from one of them.
pfSense is from FreeBSD.
-
@black3dynamite said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
All other surviving BSD products are just rebranding or derivatives of one of these: TrueOS and FreeNAS are both derivates of FreeBSD. pfSense from OpenBSD I believe. GhostBSD is from one of them.
pfSense is from FreeBSD.
Oh yeah. Not many things left derived from the non-FreeBSD BSDs any longer. The list is really light.
-
That's one of the nice things about the BSD ecosystem, people fork it way less often.
-
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
That's one of the nice things about the BSD ecosystem, people fork it way less often.
Speaking BSD ecosystem, how is the development of BSD hypervisor, bhyve?
-
@black3dynamite said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
That's one of the nice things about the BSD ecosystem, people fork it way less often.
Speaking BSD ecosystem, how is the development of BSD hypervisor, bhyve?
It's going, but I'm not following it closely. It's not very interesting at this point.
-
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
By default, Dragonfly disables both root and password-based logins from SSH. This can be a big pain if you are just using the system casually or temporarily. To fix this you need to first edit the configuration file for SSHD:
vi /etc/ssh/sshd_config
Then to allow root to log in via SSH make PermitRootLogin be "yes":
PermitRootLogin yes
And to allow root or any user to use passwords for SSH login change PasswordAuthentication to "yes".
PasswordAuthentication yes
You'll need to restart SSHD for this to take effect:
/etc/rc.d/sshd restart
A whole bunch of Linux distros do the same. You should choose a more general name for the thread - like "Allowing root password login via SSH".
Anyway, it's generally a better idea to use key based logins.
-
@thwr said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
By default, Dragonfly disables both root and password-based logins from SSH. This can be a big pain if you are just using the system casually or temporarily. To fix this you need to first edit the configuration file for SSHD:
vi /etc/ssh/sshd_config
Then to allow root to log in via SSH make PermitRootLogin be "yes":
PermitRootLogin yes
And to allow root or any user to use passwords for SSH login change PasswordAuthentication to "yes".
PasswordAuthentication yes
You'll need to restart SSHD for this to take effect:
/etc/rc.d/sshd restart
A whole bunch of Linux distros do the same. You should choose a more general name for the thread - like "Allowing root password login via SSH".
Anyway, it's generally a better idea to use key based logins.
This is the only OS I know that does this by default. People looking for Dragonfly issues will run into it.
-
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
@thwr said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
By default, Dragonfly disables both root and password-based logins from SSH. This can be a big pain if you are just using the system casually or temporarily. To fix this you need to first edit the configuration file for SSHD:
vi /etc/ssh/sshd_config
Then to allow root to log in via SSH make PermitRootLogin be "yes":
PermitRootLogin yes
And to allow root or any user to use passwords for SSH login change PasswordAuthentication to "yes".
PasswordAuthentication yes
You'll need to restart SSHD for this to take effect:
/etc/rc.d/sshd restart
A whole bunch of Linux distros do the same. You should choose a more general name for the thread - like "Allowing root password login via SSH".
Anyway, it's generally a better idea to use key based logins.
This is the only OS I know that does this by default. People looking for Dragonfly issues will run into it.
Debian disallows root login not sure about passwords.
-
@black3dynamite said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
@thwr said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
By default, Dragonfly disables both root and password-based logins from SSH. This can be a big pain if you are just using the system casually or temporarily. To fix this you need to first edit the configuration file for SSHD:
vi /etc/ssh/sshd_config
Then to allow root to log in via SSH make PermitRootLogin be "yes":
PermitRootLogin yes
And to allow root or any user to use passwords for SSH login change PasswordAuthentication to "yes".
PasswordAuthentication yes
You'll need to restart SSHD for this to take effect:
/etc/rc.d/sshd restart
A whole bunch of Linux distros do the same. You should choose a more general name for the thread - like "Allowing root password login via SSH".
Anyway, it's generally a better idea to use key based logins.
This is the only OS I know that does this by default. People looking for Dragonfly issues will run into it.
Debian disallows root login not sure about passwords.
Totally different as it...
- Allows passwords
- Creates the user
- Sets the user to be sudo
All of that is not used in Dragonfly.
-
@black3dynamite said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
@thwr said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
By default, Dragonfly disables both root and password-based logins from SSH. This can be a big pain if you are just using the system casually or temporarily. To fix this you need to first edit the configuration file for SSHD:
vi /etc/ssh/sshd_config
Then to allow root to log in via SSH make PermitRootLogin be "yes":
PermitRootLogin yes
And to allow root or any user to use passwords for SSH login change PasswordAuthentication to "yes".
PasswordAuthentication yes
You'll need to restart SSHD for this to take effect:
/etc/rc.d/sshd restart
A whole bunch of Linux distros do the same. You should choose a more general name for the thread - like "Allowing root password login via SSH".
Anyway, it's generally a better idea to use key based logins.
This is the only OS I know that does this by default. People looking for Dragonfly issues will run into it.
Debian disallows root login not sure about passwords.
At least Ubuntu is
PermitRootLogin without-password
by default
-
@thwr said in Allowing Root Password Login via SSH to Dragonfly BSD:
@black3dynamite said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
@thwr said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
By default, Dragonfly disables both root and password-based logins from SSH. This can be a big pain if you are just using the system casually or temporarily. To fix this you need to first edit the configuration file for SSHD:
vi /etc/ssh/sshd_config
Then to allow root to log in via SSH make PermitRootLogin be "yes":
PermitRootLogin yes
And to allow root or any user to use passwords for SSH login change PasswordAuthentication to "yes".
PasswordAuthentication yes
You'll need to restart SSHD for this to take effect:
/etc/rc.d/sshd restart
A whole bunch of Linux distros do the same. You should choose a more general name for the thread - like "Allowing root password login via SSH".
Anyway, it's generally a better idea to use key based logins.
This is the only OS I know that does this by default. People looking for Dragonfly issues will run into it.
Debian disallows root login not sure about passwords.
At least Ubuntu is
PermitRootLogin without-password
by default
Right, they allow a lot.
-
Dragonfly is tough by default because unless you use something like Salt, you can't connect to it to get keys to it in the first place. You can curl keys to it, of course. But you need totally different processes than you would typically use with any other OS to get it set up.
-
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
Dragonfly is tough by default because unless you use something like Salt, you can't connect to it to get keys to it in the first place. You can curl keys to it, of course. But you need totally different processes than you would typically use with any other OS to get it set up.
That means it's not even Ansible friendly. Pretty much agent-based tools like Puppet, Salt, etc... is the way to go.
-
@black3dynamite said in Allowing Root Password Login via SSH to Dragonfly BSD:
@scottalanmiller said in Allowing Root Password Login via SSH to Dragonfly BSD:
Dragonfly is tough by default because unless you use something like Salt, you can't connect to it to get keys to it in the first place. You can curl keys to it, of course. But you need totally different processes than you would typically use with any other OS to get it set up.
That means it's not even Ansible friendly. Pretty much agent-based tools like Puppet, Salt, etc... is the way to go.
Yup, unless you have some way to push the Ansible key ahead of time, like in a curl. So back to the beginning there