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
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.
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 sshdMaybe 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.
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 debian@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,
btw, this is now docuemented here:
Regards,
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..
Regards,
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.
On Fri, 03 Mar 2017 00:56:56 +0000, Jason Kridner
<jkridner@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>
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.
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.
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.
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
Well the "root" user is still there..
The only thing we did was to disable:
ssh root@address.local
can you share a link to their install script?
Regards,
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
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.