TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

SSH: Use Password or Public-Private Keys?

49 点作者 dopkew超过 14 年前

8 条评论

lutorm超过 14 年前
I use one key everywhere, but the private key lives on two places only: a usb drive on my keychain and on a backup floppy. When I sit down at a system, I load the key into the agent and then unmount the usb drive. It seems that the only way the private key could be compromised is if someone breaks into the agent when I'm on the machine or if someone spoofs the connection to the agent (which, if I understand correctly, won't give them the key, only the ability to use the key while the agent is running).<p>If the usb drive is lost/stolen, there should be no information that reveals which systems it works on. The key also has a very long passphrase, since I only type it once per day, so that should at least make brute force attacks against the key difficult.<p>This seems like a pretty secure solution to me. What other weaknesses can you think of?
评论 #1889715 未加载
评论 #1886995 未加载
dedward超过 14 年前
Speaking from experience, while keys are more useful, and more secure if universally used properly - I've seen keys bite firms where it hurts much more often than passwords - because people at some level leave an unprotected key laying around, and that key ends up with root level access to a huge array of servers. The argument is made, in the article, that if people won't password protect their keys they are equally likely to email their password - but this doesn't ring true - it's more logical and straightforward for people to understand a password that needs to be kept secure than a keyfile, which is more abstract and they may not understand.<p>So - does that mean I wouldn't recommend using keys? No - but if you are going to use them, you have to couple that with strict policies regarding usage and rotation.<p>I use keys for systems where I'm the sole administrator - because I know MY key management practices - but in group situations, we generally stick to passwords as the primary entry point (and then perhaps keys when it comes to accessing clusters of servers - but we tend to treat those clusters as a single functional machine, so keys make sense here)
评论 #1886571 未加载
chrisbroadfoot超过 14 年前
Even better: two factor authentication.<p><a href="http://en.wikipedia.org/wiki/Two-factor_authentication" rel="nofollow">http://en.wikipedia.org/wiki/Two-factor_authentication</a><p>Are there any examples of people using these to access a sshd? I know it's becoming common practice for access to VPN, etc. but it'd be nice to have this without the hassle of a VPN.
评论 #1886234 未加载
评论 #1888305 未加载
Yaggo超过 14 年前
I use key-based authentication with password-protected key. I don't (mostly) have to type the password, because OS X is smart enough to store it to keychain (if enabled). I also have FileVault enabled and my login password prompted when resuming from a sleep, so I think my private key is pretty well protected.
评论 #1886070 未加载
Jabbles超过 14 年前
What's the problem with brute-force attacks? Why can't a simple incorrect-password timeout prevent them?
评论 #1886133 未加载
评论 #1886573 未加载
评论 #1886033 未加载
评论 #1886029 未加载
steveb超过 14 年前
There are a lot of open issues with ssh keys, especially in an internal environment with a lot of end users. Is is difficult to control the distribution of keys or force a key password policy.<p>1) Users will copy their .ssh directories to every server they have access to so that they don't have to type in passwords. To deal with this:<p><pre><code> a. You can limit where public keys are stored with the AuthorizedKeysFile directive in sshd_conf. Force all keys to be controlled by root and in a central location. b. Implement kerberos so that users don't need to use keys for single sign-on. c. only allow keys for functional ids (i.e. mysql), use IP filtering (from=xxx.xxx.xxx.xxx) on the public key to limit key access to a few administrative servers. d. If NFS homedirs are exported to the world, any attacker can mount them and read off the keys from .ssh directories. </code></pre> Other folks have mentioned brute-force attacks against your ssh daemons on the public internet. If possible, you should think about using a VPN/two-factor authentication to get access to your network or internal gateway servers.
steveklabnik超过 14 年前
My friends and I recently changed our server over from password to key-based, and a small unintended consequence came up: I could no longer SSH from my phone! I'm told that I can get my key on my phone somehow, but I've been too lazy to actually do it. Luckily I figured this out before it was important.<p>Then again, I'm not sure how important that actually is...
评论 #1887125 未加载
_b8r0超过 14 年前
Use password-protected key pairs when you can, passwords where you can't.<p>And always check the key fingerprints.