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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

SSH: Best practices

284 点作者 cujanovic超过 9 年前

22 条评论

LinuxBender超过 9 年前
The article didn&#x27;t make mention multiplexing and MaxSessions defaults in OpenSSH. The default is 10 which means you auth once, and all subsequent logins are without auth and without syslog entries. If you manage secure systems and have 2FA, this allows bypassing 2FA and logging.<p>All I have to do is trick your folks into testing a ruby &#x2F; python &#x2F; perl &#x2F; bash script for me that will drop a key on your machine, fire up ssh using that key and tunnel back to my host. Now I have full control of your secure (banking, government, eCommerce) environment, completely bypassing 2 factor authentication. Just one link to one of your email distros and up to 10% of your folks will run it.<p>Combine this with sudo credential caching and now I have root on all of your systems without having to bother finding vulns.<p>Thx to Prandium for the demo of this simple social engineering exploit.
评论 #11054785 未加载
评论 #11053817 未加载
hackercomplex超过 9 年前
Developer laptop compromise is probably the biggest security risk that any startup company faces, because the developer laptop is an uncontrolled environment with a lot of &quot;attack surface&quot; which may have been previously compromised.<p>In my view there are emerging best practices in this area. There are two ways to reduce this risk and both are controversial:<p>1. Force developers to only develop software using an SSH terminal (by first connecting to a developer VPN via 2FA and then sshing into their secure development environment where may use tools like tmux, vi, and their programming language of choice to get the job done). In this scheme copying source codes or security credentials to a developer laptop is considered a violation and becomes a fireable offense no questions asked.<p>2. Require all developers to run a private USB-bootable linux desktop shell which is known to be clean. In this case they remain free to utilize modern desktop editors and code emulators (such as android simulator). It&#x27;s even possible to setup secure persistence in these environments so that the developer&#x27;s browser configuration, network&#x2F;vpn config, dotfiles, apt installs, etc are stored on an encrypted filesystem on USB device. The reason why a USB image is preferred is because it&#x27;s annoying to ask a new employee to repartiation her personal harddrive.<p>My suspicion is that as more of the tools developers need to rely on are cloud-based: (example: github, cloud9, jenkins, etc) we will eventually see these modern best practices against client-side attacks being adopted more broadly. The quality and reliability of hot-bootable ultra secure cloud operating systems has gone thru the roof over the past couple of years and I assume this trend will only accellerate due to the fact that Google Chrome OS continues to penerate more of the market and consumers are getting used to it.<p>TLDR: ssh keys existing on developer harddrives is an info-sec anti-pattern, they should only ever exist in system memory or in an encrypted partition on a USB stick.
评论 #11056527 未加载
评论 #11056159 未加载
评论 #11056163 未加载
评论 #11056418 未加载
heinrichhartman超过 9 年前
Cached version <a href="https:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:BZ3ZeqaqyLAJ:https:&#x2F;&#x2F;blog.0xbadc0de.be&#x2F;archives&#x2F;300+&amp;cd=1&amp;hl=de&amp;ct=clnk&amp;gl=de" rel="nofollow">https:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:BZ3Zeq...</a>
评论 #11053130 未加载
jsn超过 9 年前
The part about gateway hosts says:<p><pre><code> &gt; Host B &gt; ProxyCommand ssh -W B:22 A </code></pre> That could be improved:<p><pre><code> &gt; Host B &gt; ProxyCommand ssh -W %h:%p A </code></pre> Then you can use wildcards for B (&quot;Host 10.11.12.*&quot;), and use custom ports (&quot;ssh -p 2222 10.11.12.13&quot;).
评论 #11063174 未加载
r0muald超过 9 年前
I thought using per-service SSH keys was an useful mitigation against e.g. GitHub public keys being exposed:<p>- <a href="https:&#x2F;&#x2F;blog.benjojo.co.uk&#x2F;post&#x2F;auditing-github-users-keys" rel="nofollow">https:&#x2F;&#x2F;blog.benjojo.co.uk&#x2F;post&#x2F;auditing-github-users-keys</a><p>- <a href="http:&#x2F;&#x2F;arstechnica.com&#x2F;security&#x2F;2015&#x2F;06&#x2F;assume-your-github-account-is-hacked-users-with-weak-crypto-keys-told&#x2F;" rel="nofollow">http:&#x2F;&#x2F;arstechnica.com&#x2F;security&#x2F;2015&#x2F;06&#x2F;assume-your-github-a...</a><p>- <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9645703" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9645703</a>
评论 #11053245 未加载
noondip超过 9 年前
Here&#x27;s a brief guide for setting up SSH with YubiKey as a smartcard which complements this article nicely - <a href="https:&#x2F;&#x2F;github.com&#x2F;drduh&#x2F;YubiKey-Guide" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;drduh&#x2F;YubiKey-Guide</a>
评论 #11055073 未加载
评论 #11055902 未加载
eeZi超过 9 年前
Good advice, except the &quot;remove all system passwords&quot; part. Do not do this. It&#x27;s a really bad idea. There are occasions where you <i>do</i> need to authenticate using a password, most importantly on the local console - what if your server lost network access?<p>And that sudo workaround is bad since it requires agent key forwarding, which you shouldn&#x27;t use for the reasons the author himself noted a few paragraphs up.
bisby超过 9 年前
Weird, where I work we&#x27;re not allowed to use key auth. They claim it&#x27;s for PCI since they can&#x27;t enforce that the keys are passworded&#x2F;encrypted.
评论 #11055863 未加载
评论 #11055003 未加载
评论 #11055011 未加载
评论 #11063190 未加载
评论 #11057846 未加载
评论 #11054931 未加载
akerro超过 9 年前
I bookmarked something similar: <a href="https:&#x2F;&#x2F;stribika.github.io&#x2F;2015&#x2F;01&#x2F;04&#x2F;secure-secure-shell.html" rel="nofollow">https:&#x2F;&#x2F;stribika.github.io&#x2F;2015&#x2F;01&#x2F;04&#x2F;secure-secure-shell.ht...</a>
评论 #11053986 未加载
rphlx超过 9 年前
Also, move sshd to a random &amp; rarely-used TCP port. Won&#x27;t help much against a skilled &amp; determined targeted attack, however the &quot;security through obscurity&quot; is not entirely worthless. Using something other than 22 is quite effective at avoiding spray-n-pray scans and exploits.<p>For extra credit, set up port knocking.
评论 #11056334 未加载
STRML超过 9 年前
SSH&#x27;s new AuthenticationMethods directive is extremely useful for pairing SSH keys with a password and&#x2F;or 2FA. You should absolutely use keys everywhere, and encourage your users to encrypt their keys, but enforcing a password as well ensures that logins are &quot;something you have&quot; (the SSH key) and &quot;something you know&quot; (the password) as a sort of 2FA.<p>As a cherry on top you can put the password in LDAP or RADIUS server and hook up traditional 2FA (Google Auth, Yubikey, Email, SMS) for that legendary 3FA (ah... &quot;something (else) you have&quot;). Sounds hokey, but defense is best in depth.
评论 #11053770 未加载
rodionos超过 9 年前
Org question. We use a shared key and a shared account to manage our servers. When someone leaves the team we have to regenerate the key for the account. I&#x27;m sure it&#x27;s not recommended, so what&#x27;s a good way to manage ssh access in a team setting? I&#x27;d like avoid sharing the key so that access can be revoked from user without regenerating the key for everyone?
评论 #11054915 未加载
评论 #11055161 未加载
评论 #11054976 未加载
评论 #11055224 未加载
tbe超过 9 年前
&gt; f=$(mktemp) &amp;&amp; ssh-keyscan korell &gt; $f &amp;&amp; ssh-keygen -l -f $f &amp;&amp; rm $f<p>&gt; Unfortunately ssh-keygen does not support input from stdin, so this example is slightly more complicated than it should.<p>Any shell that supports process substitution can fix this for you with something like;<p>ssh-keygen -l -f &lt;(ssh-keyscan korell)
mfontani超过 9 年前
How about <a href="https:&#x2F;&#x2F;github.com&#x2F;ccontavalli&#x2F;ssh-ident" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ccontavalli&#x2F;ssh-ident</a> ? Is that still a &quot;best practice&quot;, since the author doesn&#x27;t mention it in this blog entry?
评论 #11054951 未加载
sapereaude超过 9 年前
Great post!<p>BTW, you can also now use hardware devices (like TREZOR and KeepKey) to perform &quot;ssh-agent&quot; functionality in hardware, with minimal setup work.<p>Blog post: <a href="https:&#x2F;&#x2F;medium.com&#x2F;@satoshilabs&#x2F;trezor-firmware-1-3-4-enables-ssh-login-86a622d7e609" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@satoshilabs&#x2F;trezor-firmware-1-3-4-enable...</a><p>Source code: <a href="https:&#x2F;&#x2F;github.com&#x2F;romanz&#x2F;trezor-agent" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;romanz&#x2F;trezor-agent</a> (the README has several demo screencasts).
antoniomika超过 9 年前
I remember reading about a tool Instagram used for SSH management, but that might not be a &quot;best practice&quot;. (<a href="http:&#x2F;&#x2F;instagram-engineering.tumblr.com&#x2F;post&#x2F;11399488246&#x2F;simplifying-ec2-ssh-connections" rel="nofollow">http:&#x2F;&#x2F;instagram-engineering.tumblr.com&#x2F;post&#x2F;11399488246&#x2F;sim...</a>)
balgan超过 9 年前
And yet we still see things like <a href="https:&#x2F;&#x2F;blog.binaryedge.io&#x2F;2015&#x2F;11&#x2F;10&#x2F;ssh&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.binaryedge.io&#x2F;2015&#x2F;11&#x2F;10&#x2F;ssh&#x2F;</a>
gdamjan1超过 9 年前
It would be a cool to have a `forward agent connection once` option to ssh. when I know I&#x27;d have to `git pull` once on the server but don&#x27;t need the agent forwarding after that.
carlisle_超过 9 年前
&gt;Do not SSH cross-server<p>This doesn&#x27;t make sense. You can safely setup SSH agent forwarding to ssh from server to server without storing your ssh private key anywhere but your local host.
评论 #11054712 未加载
RRRA超过 9 年前
Has anyone used ProxyCommand to chain through 2 or more gateways and has a config example to show?
评论 #11055512 未加载
评论 #11065710 未加载
hobarrera超过 9 年前
What amazes me about these articles is that they keep recommending NOT to use password-based logins for SSH: Why are people still using that?
评论 #11065721 未加载
n1000超过 9 年前
Still a big fan of the BetterCrypto guide: <a href="https:&#x2F;&#x2F;bettercrypto.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bettercrypto.org&#x2F;</a>
评论 #11053676 未加载