Is it ok to distribute an OS with a passwordless ssh root access... ?

[Linux-SWAT]

Is it ok to distribute an OS with a passwordless ssh root access, and without informing the users ?

---EDIT: FYI, ssh is a network access.

 

[PowerGod]

With "ok" do you mean in a legal way ? This is a thing that could change in every country...

Anyway seems a little generic as a question... I suppose that if the OS is distributed "as is, without responsibilities", then it could be "ok" for simplicity, but mainly it is always good to know a thing like this.

 

[Linux-SWAT]

It's a very basic question, not especially about legality.

 

[PowerGod]

Well, then for me, distributing could be ok, but not informing is a no go.

 

[pimaster]

I feel dirty voting yes but I thought it'd be interesting to discuss.
Raspbian comes with a default user who has sudo access. A default password is just as bad as no password. (Now that I've started to think about it, SSH access may not be on by default).
What are the chances of deploying a distro with this open access and not log into it? Is the problem that you expect people to use the distro via the GUI and auto log in is enabled by default on a lot of systems?
Would I expect an end user distro to do this? No. Absolutely not.
Am I ok with a development distro doing it? Yes.
I guess there are lessons to be learned from development or debug processes making it from testing into live (there were some Android packages causing issues for some products?)

 

[ingoreis]

I have no Problem with "no Password"
Every User who want a Password can simply add one.

The only Thing i suggest is:
Inform the Users and give them the Command which simply set a Password when they realy want one.

This Idea ist good because many Users are angry...password here...passwords there...passwords everywhere.

And when i have the Choice for personal use at Home...i do not use Passwords when i can.

 

[Linux-SWAT]

Ingoreis, it's a ssh root password, so anyone on the network can log into the devices with administrator access.

 

[ingoreis]

Yes and its your Home Network
Your Home Network is normaly secured with an Firewall on your Router.

When you use that Device on other Networks you can simply setup a Password.

My Choice was for using @home

 

[Linux-SWAT]

 

[elw3]

I have no problem with a passwordless distro, a slight problem with ssh being on by default and a huge with not telling the user.
But this all depends on what kind of distro that is, my desktop computer has other standarts than that crap webstick for the TV.

 

[ghostpatch]

no, thats irresponsible. I'd stay away from any distribution adopting such security practices -.-

@Elw3 unless you throw it a DMZ network you should care about the crap in your home network...

 

[levi]

As others have hinted at, my problem is a device being distributed that's running with sshd enabled. Even if it's on your home network, you can't be sure that there isn't a rogue device there, and I guess there might be users who run routers that put everything in the DMZ*, either by design or it's something the users configured to make their simple setup work.

I see no need to run an open port on anything being shipped to a customer, regardless of whether challenge response or even no password is enabled, and regardless of which user it gives access to. A crackable httpd can also give you root access on many machines.

* I guess that's a term that I need to think of a new one for. The public internet is essentially militarized in the modern world, so claiming a zone that's connected directly to it is 'demilitarized' sounds a little backwards to me.

 

[FBnil]

No. Not for customers, not for the kids, not for grandma, not for the ones I hate (I take pride in securing the thing!).
Maybe for police work (hacking the laptop of a criminal).
Yes for a honeypot, but only for the lulz.
Yes if you can only su to root with a local account. (for example: Knoppix)

At $work, the direct root access through ssh is disabled. This stops low-key brute force attacks (those that run slowly over many months).
What I DO have is ssh-keys, to login passwordless to a server (with my own userid), then sudo rules to su to root in a passwordless way (which actions are logged far away on another server). The root password itself now is >12 characters and untypeable, and only needed if all fails (dead sshd, access through the root console, etc).
Now my $work laptop came with a thing I had to sign, and that I could get audited at any time, yada yada. Basically, scans run in the background and get reported, and a human (security officer) could check what I am doing by connecting to my screen. But I signed for it.
The laptop hdd is encrypted with LUKS, and contains 2 passwords, in case you forgot yours, and... for legal reasons.
3rd party access to support stuff has to go through a change, and at the client side, we flip a router to let them through for the duration of the change. Some servers are so secured that it's 4 eyes only (a security officer looks at all that is being typed in) and the 3rd party needs to come personally.
Some servers dial home (to another 3rd party) for status updates (stupid windows servers), and if they have a problem, they complain that they need a patch. We provide it from a local repo.

If you still need direct root access to give support.... then

Research port-knocking, where you need to do something first before you can access the machine.

Or use ssh to execute a sudo su immediately after logging in.

I once entertained putty and kpscript to fetch the password.

Now, a more grayhat things could be to run monitoring (IFTTT?) that detects your presence, and swaps the /etc/hosts.[allow|deny] to allow only your device to log in to root (or swaps in your ssh_keys) or swaps out the /etc/shadow/passwd to an easy password, then swaps back.
A workable example is going to a certain webpage (target server needs to run httpd), and after an easy action that runs a cgi bin that uses my IP address to allow login from that IP address.
Or here is a nice one: http://codecapsule.com/2010/07/06/knock-knock-secure-your-ssh-server-using-port-knocking/

And now for a BlackHat mindset:

Now, if you want to DENY that you can log in as the user "root", why not create a user called "notroot". Then set the password of "notroot", and you are ready to log in as "notroot" but still get root rights. Note the id is zero for that nonroot user:

fbnil@spica:~$ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/bash
notroot:x:0:0:root:/root:/bin/bash

 

[levi]

Yeah, I run my server denying root logon and passwords, and log on using a key that I unlock on my local machine. It doesn't mean I can forget my user password though, since my login account is a sudoer, so I need to password for that at least. If sshd dies (or more commonly, the network falls over) and I have to log in on the actual machine, I can log in to my user account there and patch things up.

 

[ible]

i would say it's important to inform users, preferably turning off ssh by default.

i like passwordless, but ideally the first-open screen should ask for a new password.

 

[TeDaDeS]

If people know what SSH is and want to use it they are also smart enough to remove the password if it's their choice. Probably they will change it, not remove it.
When you are unaware of SSH and it's not secured, that is pretty bad. I agree that usage at home could a the only situation where you would allow it, but still I wouldn't prefer it.

 

[levi]

Yeah, I guess this is about the fact the prototype Pyra currently have passwordless sshd enabled in the default OS images. I can see the benefit of doing that for the prototypes, as you're likely to be reconnecting to them often, and you can kind of assume those users are going to have some sort of firewall in use.

The only question I have is whether this sshd also runs on the cellular data network; if the developers install a sim, and miscreants get to know the ip they could enslave the machine that way.

 

[NetBLOKS]

No, it`s not OK for an out-in-the-world distro.
YES, it`s ok for prototype testing, as it should be reasonable to think, that the specific testers check for their root logins (I always test that...)

 

[TeDaDeS]

Yeah, I guess this is about the fact the prototype Pyra currently have passwordless sshd enabled in the default OS images. I can see the benefit of doing that for the prototypes, as you're likely to be reconnecting to them often, and you can kind of assume those users are going to have some sort of firewall in use.

The only question I have is whether this sshd also runs on the cellular data network; if the developers install a sim, and miscreants get to know the ip they could enslave the machine that way.

I can understand that developing/debugging software might be useful with passwordless systems.
But there are better debugging interface alternatives more suitable for connecting to your machine (serial/telnet).
Having SSH implies that it's secure somehow, which in this case is not.

 

[PCXT]

It's totally OK if it's well documented. What is a difference between passwordless access and universal password which is quite standard in embedded distributions? If it is clearly in documentation or installer, users will be able to secure it when configuring system as they want - with password, key, device or a keyfile.
This is a similar security risk as offering the ridiculous root access in Raspberry Pi (which is by default IoT-oriented), or adding backdoored drivers to Linux distributions, like recently.
In both cases there is almost no word in documentation about it in RPi or about backdoors in drivers.