Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Before you get into half-arsed solutions like having an ssh buddy, disable root login and password authentication.


Yes, but the issue here is not root login, it's the prospect of something going wrong with your server(s) and having a trusted buddy around whom you can call on for assistance. It's actually pretty reasonable. My servers always crash when I'm literally somewhere in the jungle in Asia and can't possibly get to an online connection for at least a day. It's great if you can just call someone who takes care of the most pressing problems if/when they happen.


My servers always crash when I'm literally somewhere in the jungle in Asia and can't possibly get to an online connection for at least a day.

Get a watchdog timer.


I can't quite decide whether I really failed to bring my point across or if you're just pulling my leg here. Okay, I'll be more specific. Things happen to servers when you're not around. It helps to have someone you can call who can fix small things when they go wrong. You can't meaningfully automate every single thing that might happen. It might not even be a technical malfunction, maybe something unexpected needs to be done and it requires a person to do it...


I don't understand what's 'half-arsed' about deciding up front who I can trust to have login credentials for my personal machines.


Nothing wrong with deciding that. The proper way to give them access, however is to give them an SSH key, not a name/password set.


Well on the surface nothing, however login credentials can be stolen easily. Focus is on "easily". Sure keys maybe hijacked but the problem becomes non trivial and I am all for making burglars jump through a monkey bar before they even get to the door.


Prevention is better than cure.


Preparation is better than being unprepared.

(Not that I'm arguing your point. Just taking all steps that you can think of to prevent something, doesn't mean you'll actually prevent it. Being prepared for a worst case is always a good idea.)


Ideally you should not have to circumvent the default PermitRootLogin settings; it is there for a reason. And no need to give out root passwords, if you are so security conscious.

Our polo-necked messiah has given us iPhones that can even run an SSH client so how sort-of pointless to talk about "ssh buddies" and showing iPhone screenshots in the very same article? Since you were getting IDS alarms on your iPhone anyway, why didn't you SSH in and shutdown the machine yourself?

And on the root login bit: you would only need a sort-of dummy account for you logging in or for your "ssh buddy", if you love that idea. And all they need to be able to run is "sudo shutdown".


I was waiting for the article to mention the fact that you can SSH from any capable smart phone. Then he/others are saying using SMS to send commands from his phone is a good idea. [facepalm]

Get a mobile ssh client, set it and your sshd up with RSA keys, setup port forwarding on your home router on a non-standard port, disable Root login and move along.


You may have a cell signal but no (or prohibitively expensive, in the case of traveling abroad) data access.

Then again, if one of my servers was being hacked, I think I'd be ok spending $50 in data roaming to shut it down.

Although, there's the case of a really slow data. On T-Mobile I'll occasionally get an EDGE signal too useless to even establish an ssh session, let alone be interactive enough to use ssh. A text message can often be much more reliable and easy to use. Not sure about the security implications related to SMS remote control, though.


The SMS part was only added later... the proposed "solution" was: SSH buddy!

I don't know why this was linked here and got all those upvotes. I don't see anything special about it, really.


I assume that he already did this. That the alert comes when someone assumes root. But maybe I'm being naïve.


In /etc/ssh/sshd_config do:

PermitRootLogin without-password

That way root must use a public key to login, but other people can still use passwords.

(But watch out for sudo.)


The remote root login was my first thought too. Especially when I saw the sentence "... I'm pretty careful with machine security ...".

What's bad about password auth if your password is strong enough?


With passwords you are handing out what is needed to log in. With the ssh public key scheme, you only prove that you have the private key, but don't hand it out to the server.


I don't feel safe carrying a private key around with me on my mobile. It could be copied without my knowledge and brute forced in privacy. Whereas with password authentication, I can impose limits on the number of tries and also on the time between the tries. Am I wrong in thinking this?


This is why I have a completely separate private key that I generated for my phone, using a different password that's unrelated to the passwords I use for all my other machines' private keys, and I use password protection on the phone itself to thwart casual intrusion. If I lose my phone, it's trivial to remove the phone's public key from my servers' authorized_keys files, at which point the phone can no longer be used to log in.


Encrypt your private key!

This is very easy to do, and quite important for devices that can be stolen - including your desktop computer.

It's easy enough to setup ssh-agent on your desktop so you don't have to keep entering the password.


If you have a copy of the private key and the public key, you can bruteforce the passphrase. So use a big passphrase instead of a password.


passwords are replayable tokens. one-time passwords are not. people who actually are careful with machine security use ssh keys + sudo/opie.


Doesn't seem like front page news. Use key based auth and disable root login. You can also get an ssh client on your iphone if you don't mind keeping your private keys on it, just make sure to use a long password and be prepared to change all your server keys if you lose your phone. I also ban every IP that even tries to login as root.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: