Much to my dismay, I found in a recent conversation with Linode support that it is impossible for them to disable password auth on lish (even by means of a support ticket).

This is a problem for me, because while I can assert due diligence to my clients on other aspects of server security (IE those I control) the fact that lish listens on known ports, cannot be configured to not respond to password auth, and can wreak absolute havok on my nodes makes it a pretty large single point failure.

I would really like it if it were possible to run lish in a certificate only mode for a given node. Secondarily, it would be nice to filter the IPs that could access lish for a given node. Both of these features would go a good ways toward me being able to represent to my clients that, despite recent events, Linode is a good choice to host their services.

Just set an exceptionally long and randomized SSH password for Lish... Lish might listen on known ports, but it's not running on your machine. That's like complaining that the Linode manager runs on port 80. That and everything SHOULD run on known ports. Putting services on non-standard ports is false security.

While I agree that ssh on a non-standard port isn't really security, it makes it easier to detect attacks (less botnet traffic). But that's hardly the point. I'm not asking for Linode to move to a non-standard port. IP filtering of valid source IP's (where a user can connect from, not over which port) was the only traffic related modification I requested.

Also, I HAVE an exceptionally long and randomized lish password, but that isn't as secure as an SSH key WITH an exceptionally long randomized password.

Basically what you are doing is telling me what the definition of "good enough" should be in my feature request. It might be good enough for you (and I mean that honestly), but if it's possible I would like the ability to lock it down a bit more. Those are my use case wishes, and just because they aren't yours doesn't mean they aren't valid.

EDIT:

Also, not to get off topic, but the Linode Manager running on port 80 is not a problem. The fact that I don't know whether there is any lockout system or how many failed login attempts before it sends them a notice is. It really isn't clear to me how vulnerable the manager is to attacks.

Please keep in mind that I'm a huge fan of my Linode service thus far. I'm not bashing the service, but I think this is something that would make it better.

There is an IP restriction option for the linode manager, although not for lish, to my knowledge.

Setting an exceptionally long SSH password would be, I'd imagine, no less secure than key-based auth, since the chances of brute-forcing it would be the same. What it would do is provide an additional attack vector, but one that is no less vulnerable by itself. Not ideal, but it does pretty much solve the problem in an inelegant way.

But I'd tend to agree that IP restrictions could be nice, perhaps just using the same IP restrictions as the manager itself.

Thanks for the info regarding the manager. I'll research that at get that running asap.

As for the long pass vs. pubkey issue, the chief difference is that the "real" key never traverses the network. It isn't just that the password is WAY more bytes, but the private key isn't actually sent in the exchange. Therefore the attacker would have to either crack the exchange (very hard, although theoretically not impossible) or obtain the private key.

http://serverfault.com/questions/204964 ... s-ssh-keys

EDIT:
Sorry, I meant to say that the public key isn't actually sent in the exchange. Obviously the private key isn't sent. derp derp.

DOUBLE EDIT:
Also, I have a 32 character lish password (192 bits). I have a 4096 bit SSH key encrypted with an AES256 cipher passworded with a 192 bit password. I feel that the second option is substantially harder to replicate through brute force methods.

Is there a maximum length on the password? Any reason you can't use a 683 character long password?

The password field on the page has maxlength="24" set, so yes there seems to be a max length.



I would also like it if the Lish password could be unset (in a "passwd -l" kind of sense).

I may be pointing out the obvious, but based on how that was phrased I just have to point out that the password for the key is irrelevant in terms of brute force attacks against the host.

The private key file is encrypted, the key password is only used to decrypt the key file.
Ie, it's only used to protect the actual key data in case someone gets hold of the key file, it's not in any way communicated to the host.

There is sort of a way to remove the password, when you create a new node if you haven't set a password you can't access lish, so just never set a password, you're stuffed for existing nodes but for new ones it's better than nothing. (I went through the same thing a few months ago)

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

Yes, that's absolutely correct. But it illustrates the nature of the problem. They'd have to get onto the client and brute force the 192 bit pass, or brute force a 4096 bit exchange. Either one should be difficult (assuming your client security is up to snuff). Having unsecured PKs isn't a good idea, but once somebody gets their hands on one it's exactly as difficult to brute force their way on to the server as it is to brute force their way into the password auth SSH server and spoof an IP.

Nice to know that I'm not the only one that walked into this. I think the simplest stop gap would be to put a warning on that page in the manager. It would at least stop people from making the mistake until a longer term solution is implemented.

I guess I don't have a 32 Character Lish password. I just tried entering the first 24 only. Totally worked. Thanks for the info.

Maybe im missing something, but im not quite sure how you could IP filter lish?

Given that you would need the IP's then of any user that has a server on that host so that would probably annoy those who dont want to have to provide a list of ip's that can connect to lish.

I suppose they could possibly do some after login lish filtering, but i guess if they get to that point they have already guessed a password.

Likewise though, lish is essentially the same as being in the data centre though.. You can boot, restart, etc to go into single user mode etc.

_________________
ServerAdmin - www.our-lan.com
"Diplomacy is the art of saying nice doggy whilst looking for a really big stick"
"In my experiece, any attempt to make any system idiot proof will only challenge God to make a better idiot"

You could filter it by user using the allow users directive in sshd_config I've used that before, however that would mean editing the sshd_config file and restarting ssh for each new node & ip address addition/removal

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

It's been suggested before in another thread (I can't be buggered to look it up, but I think it's somewhere in the security breach thread) that pam could be used to restrict individual users to logons from a given IP. This would mean a per-user whitelist for lish.

If lish is essentially openssh on the host machine then I can't think of a reason why this wouldn't work.

EDIT:
I believe you don't have to restart sshd when you do this, but could be wrong.