Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I hear it over and over again, people saying SSH access via passwords is a bad habit, and that key authorization is the way to go. But is it really a security issue as long as your password is strong? Or are they just exaggerating?
Say I think of a long, obscure password, that is not difficult for me to remember, for example.
climbingupa7407footmountaininin7407seconds!
Isn't that plenty secure enough to not even need to think about using a key?
Isn't using a key "instead" of a password potentially less secure, because if someone steals a computer with your key on it, somehow steals a key, or accesses it when you turn your back, they could log right in without needing to know credentials right? Whereas a password they could never do that.
There is more to it than the complexity of the password... A man in the middle attack is far more easier to be pulled off in a SSH with password connection, but almost impossible with key authorizations
In that case. Is it possible (and easy/common) to setup the standard openssh server to allow login via either passphrase protected key or password?
The idea would be the passphrase protected key would be used 99.95% of the time
For example, I normally only have one laptop I ever plan to use to connect to the ssh server. Well what I'm on vacation, and that laptop gets lost/stolen/corrupted, etc. And I need to buy a new one, borrow one, use a cell phone, etc. I'd be locked out without a key right? In that case, having password login as an option would let me gain entry right?
Or is there a better way to cope with that issue? Storing a passphrase protected key in the cloud perhaps?
Threat is minimal. I'm just an average joe, with nothing much important on any of my computers besides personal files and photos nobody else would care about. I just like to err on the side of caution, and also learn to do things the right way.
Threat is minimal. I'm just an average joe, with nothing much important on any of my computers besides personal files and photos nobody else would care about. I just like to err on the side of caution, and also learn to do things the right way.
"They" don't give a flying one about the contents of your machine.
The value is in "owning" a machine that doesn't point back to them.
Threat is minimal. I'm just an average joe, with nothing much important on any of my computers besides personal files and photos nobody else would care about. I just like to err on the side of caution, and also learn to do things the right way.
For example, I normally only have one laptop I ever plan to use to connect to the ssh server. Well what I'm on vacation, and that laptop gets lost/stolen/corrupted, etc. And I need to buy a new one, borrow one, use a cell phone, etc. I'd be locked out without a key right? In that case, having password login as an option would let me gain entry right?
Assuming you will come home from vacation at some point, you just nuke the old key from authorized_keys and setup a new key pair on the server.
If you absoultely must access your home server while on vacation after getting your laptop stolen, you could have proactively emailed your (passphrase protected, hence encryped) private key to yourself using gmail or some other web-based free email. You can access gmail (or whatever) from anywhere using any browser on any computer.
So is there a good solution to using passphrase protected key encryption, but also have a backup plan just in case a key somehow gets lost?
Perhaps keeping a copy of the key in a cloud location, or web e-mail avaialble for re-download? If that is indeed a good solution, are keys cross platform compatible? Like if the key was made on linux, but then I needed to use it in putty for windows, or in an android ssh program?
Threat is minimal. I'm just an average joe, with nothing much important on any of my computers besides personal files and photos nobody else would care about. I just like to err on the side of caution, and also learn to do things the right way.
Then enable both key and password access... From the moment a key gets stolen (let's say with your laptop), don't ever use it again.. (so backup in this case fails -- that's not to say you shouldn't have a backup in some place) and remove it from the servers 'authorized_keys'
Or use two keys... One for permanent usage, and one on a USB Stick, for worst-case scenarios...
Just be sure, when using passwords to connect, man in the middle isn't likely to happen (no Wifi is a good start)..
Security wise, ensure that 'root' can't connect to your ssh server and setup something like fail2ban
Don't overstress about this, security should be as simple as it can be...
Last edited by Smokey_justme; 02-26-2014 at 05:20 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.