Re: Root login change?

[Jason Kridner]

On Thu, Mar 2, 2017 at 6:22 PM Kurt Talke <kta...@eng.ucsd.edu> wrote:

Hi,

I’m wondering why logging in over ssh as root is not longer possible on the latest BBB image.  For installing embedded lab view, I need to be able to log in as root.

I tried changing the root password, which actually shows properly in /etc/shadow, but I’m still unable to ssh in as root even with the new password.  Is there any way to alter this?

It is a basic security step. You'll need to ssh in using the debian user (with temppwd password), then use 'sudo su -' (typing the password again).

To alter it, as root:

sed -e "s/^PermitRootLogin without-password/PermitRootLogin yes/" -i /etc/ssh/sshd_config

systemctl restart sshd

Maybe we can align on a better way to install the labview service? Can an installer be copied over to the debian user account and then installed using 'sudo'? Is there a way to have the user provide a password?

The issue is that I've gotten fairly embarrassed about our lack of default security. The tipping point was the analysis that security experts have provided me regarding the DDoS attack on DNS servers back in October that targeted IoT devices. The vulnerability was simply walking in the front door on many of these devices, such as doing ssh as 'root' with various default passwords and other dictionary username/password combos. Honestly, I'm not sure that they wouldn't try debian/temppwd, but at least now sudo will ask you a password.

We knew this change would generate screams and you are the first one to scream. Now we have to start working on the tradeoffs to keep your stuff working and stop participating in botnets.

 

-Kurt

[Jason Kridner]

On Thu, Mar 2, 2017 at 6:56 PM Jason Kridner <jkri...@gmail.com> wrote:

On Thu, Mar 2, 2017 at 6:22 PM Kurt Talke <kta...@eng.ucsd.edu> wrote:

Hi,

I’m wondering why logging in over ssh as root is not longer possible on the latest BBB image.  For installing embedded lab view, I need to be able to log in as root.

I tried changing the root password, which actually shows properly in /etc/shadow, but I’m still unable to ssh in as root even with the new password.  Is there any way to alter this?

It is a basic security step. You'll need to ssh in using the debian user (with temppwd password), then use 'sudo su -' (typing the password again).

To alter it, as root:

sed -e "s/^PermitRootLogin without-password/PermitRootLogin yes/" -i /etc/ssh/sshd_config

systemctl restart sshd

Maybe we can align on a better way to install the labview service? Can an installer be copied over to the debian user account and then installed using 'sudo'? Is there a way to have the user provide a password?

I forgot to make the suggestion that simply using a public key might be sufficient. You'd still have to get logged in as root once, but once you copied the public key into /root/.ssh/authorized_keys, the labview host would be able to repeatedly log in without providing a password.

https://www.debian.org/devel/passwordlessssh 

Of course, the above recommends never doing this as 'root', but it is still a lot better than allowing simple dictionary look-up passwords to the root user.

[Kurt Talke]

Hi,

I’m wondering why logging in over ssh as root is not longer possible on the latest BBB image. For installing embedded lab view, I need to be able to log in as root.

I tried changing the root password, which actually shows properly in /etc/shadow, but I’m still unable to ssh in as root even with the new password. Is there any way to alter this?

-Kurt

[Robert Nelson]

On Thu, Mar 2, 2017 at 6:22 PM, Kurt Talke <kta...@eng.ucsd.edu> wrote:
> Hi,
>
> I’m wondering why logging in over ssh as root is not longer possible on the latest BBB image. For installing embedded lab view, I need to be able to log in as root.

Huh? Really "I need to be able to log in as root." no you don't.

Login as "debian" first over ssh then use sudo to switch to root user:

aka:

ssh deb...@address.local

then "sudo su" to switch to root...

>
> I tried changing the root password, which actually shows properly in /etc/shadow, but I’m still unable to ssh in as root even with the new password. Is there any way to alter this?

sudo sed -i -e 's:PermitEmptyPasswords no:PermitEmptyPasswords yes:g'
/etc/ssh/sshd_config
sudo sed -i -e 's:UsePAM yes:UsePAM no:g' /etc/ssh/sshd_config
sudo sed -i -e 's:PermitRootLogin without-password:PermitRootLogin
yes:g' /etc/ssh/sshd_config

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

lol . . . So I'm left wondering how many people were watching last nights conversation between the three of us, and waiting to pounce . . .lol

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYghc88jZUVZ7By%3D_GCWJ%2BT8E%2BLLuuHHSB5TSF-h%3Di8dfg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

btw, this is now docuemented here:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#i_take_full_responsibility_for_knowing_my_beagle_is_now_insecure

[Robert Nelson]

On Thu, Mar 2, 2017 at 11:23 PM, William Hermans <yyr...@gmail.com> wrote:
> lol . . . So I'm left wondering how many people were watching last nights
> conversation between the three of us, and waiting to pounce . . .lol

at elc last week, i did have one person come up to me and ask if i was going to
provide a quick doc to revert back to insecure..

other then that, it seems pretty quiet, but maybe that wave is still coming in..

[Peter Lawler]

I reckon it's probably more likely that after 25 or so years, most people have either been trained out of the bad habit or just didn't think it was possible because it's such a risky thing to do.

iptables, however...

P.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYh6yjSUHYtDtka9YPgLaWUUBnvsGcZnW5CFpyHxu52Sgw%40mail.gmail.com.

[Dennis Lee Bieber]

On Fri, 03 Mar 2017 00:56:56 +0000, Jason Kridner
<jkri...@gmail.com> declaimed the following:

>The issue is that I've gotten fairly embarrassed about our lack of default
>security. The tipping point was the analysis that security experts have
>provided me regarding the DDoS attack on DNS servers back in October that
>targeted IoT devices. The vulnerability was simply walking in the front
>door on many of these devices, such as doing ssh as 'root' with various
>default passwords and other dictionary username/password combos. Honestly,
>I'm not sure that they wouldn't try debian/temppwd, but at least now sudo
>will ask you a password.
>

Let me guess -- the next step will be to have the first connection to
"debian/temppwd" require the user to change the password. <G>
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[William Hermans]

On Fri, Mar 3, 2017 at 5:56 AM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:

        Let me guess -- the next step will be to have the first connection to
"debian/temppwd" require the user to change the password. <G>

Anyone with half a brain should already be doing that one their own. Or expect to get "hacked". Quoting hacked, because it's not a hack, it's stupidity on the users behalf.

[William Hermans]

So let's imagine, someone gaining root access( known as rooting, or being rooted ) to your system is feeling charitable, and only runs something like:

WARNING - Do not do this ! You've been warned.

# gzip -9 -r /

What do you suppose will happen, and then what do you suppose you will do to fix this problem ? Removing files recursively + forcefully would probably be more likely. But worse still, what if the attacker simply hides a well written executable on your system some where ? Does this system belong to a business that uses it in some way to deal with sensitive data ? How secure if your local network ? What kind of damage are you most afraid of happening to systems on your network ?

Just think about the above for a while until it sinks in.

[Kurt Talke]

Thanks all,

For embedded Labview, the installation as to be done through their software, and they need to create a chroot for it, and thus need root user.  Their install app only includes a user name and pass, not the ability to sudo su.  Thanks for all the help.

-Kurt

[Robert Nelson]

On Fri, Mar 3, 2017 at 10:54 AM, Kurt Talke <kta...@eng.ucsd.edu> wrote:
> Thanks all,
>
> For embedded Labview, the installation as to be done through their software,
> and they need to create a chroot for it, and thus need root user. Their
> install app only includes a user name and pass, not the ability to sudo su.
> Thanks for all the help.

Well the "root" user is still there..

The only thing we did was to disable:

ssh ro...@address.local

can you share a link to their install script?

[Kurt Talke]

Its about at minute 4 of the video below.

https://www.labviewmakerhub.com/doku.php?id=learn:tutorials:libraries:linx:3-0:software-setup

They don’t give access to the actual script.  

-Kurt

[Dennis Lee Bieber]

On Fri, 3 Mar 2017 06:28:22 -0700, William Hermans
<yyr...@gmail.com> declaimed the following:

Well -- if I were exposing one to the wild, I'd probably delete the
debian account too, after creating a new user account.

[William Hermans]

On Fri, Mar 3, 2017 at 5:53 PM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:

        Well -- if I were exposing one to the wild, I'd probably delete the
debian account too, after creating a new user account.

That's understandable. One could actually just change the account name if they wished, along with the home directory. This leaves UID as 1001, which might be preferred for some cases. This has to be done as the root user, but there is nothing really wrong with using root, when needed.

Anyway, I start to get "evangelical" when it comes to security, as I worked in the security sector for a little while, and saw first hand the silly things people do, because they do not understand the implications of not operating a computer responsibly. Then these same people claim they've been "hacked" when really,no, they were not. Theend result is that we start seeing ( best case ) BotNET's with the ability to take down whole large domains at a whim. Worse case, people or organizations have things stolen form them.