blocks|key|3966300|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<h2>TL;DR</h2>
Your best bet is really to create a policy that enforces the use of encrypted private keys or multi-factor approaches such as 2FA or OpenPGP cards. How you enforce the policy is up to you, but there are endpoint solutions and detective scripts you could write to periodically validate that passwordless client keys are not stored in an accessible way.
Multi-factor authentication (MFA) and other identity or source restrictions configured on the server side are also valid options, and avoid a lot of the complications and downsides of key escrow while still increasing the overall security posture. Ultimately, you have to determine your actual threat model, and consider which of the many potential controls best address the organizational, administrative, and user concerns that will be associated with any risk-reduction measures you might use.
You should also consider the security trade-offs inherent in any control you decide on. All controls require trade-offs in architectural and system security, as well as convenience and usability. Controls around SSH are no different in that regard.
<h2>Analysis and Recommendations</h2>
<blockquote>
Is it possible in SSH to strict &quot;pubkey with a password&quot; required for login?
</blockquote>
If you mean can you require both a public key and a server-side password, yes.
The SSH server has no way to determine whether a client's private key has been locally encrypted on the client side with a password or not; that information isn't part of the client/server key exchange protocol. While it is certainly possible to write a privileged script to scan private keys locally to see if they're encrypted or not as part of a post facto detective control, there is currently no mechanism in OpenSSH to prevent keys from being generated as passwordless keys in the first place.
That's why multi-factor authentication and other server-side configuration controls are useful. There is no scenario under which the server can determine whether the key material presented was from a private key encrypted on disk, stored on an <a href="https://en.wikipedia.org/wiki/OpenPGP_card" rel="nofollow noreferrer">OpenPGP card</a>, or otherwise protected on the client side.
If your threat model considers unencrypted private keys a risk, you should either implement client-side detective controls, multi-factor authentication, or some form of key escrow such as:
<ul>
<li>OpenPGP-compatible cards or hard tokens (I personally like using pre-configured <a href="https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP" rel="nofollow noreferrer">YubiKey tokens</a> for this, but there are other options and your mileage may vary) where the user cannot disable passwords on the device;</li>
<li><a href="https://man.openbsd.org/ssh-keygen.1#CERTIFICATES" rel="nofollow noreferrer">OpenSSH certificates</a> signed by a trusted certificate authority, along with an <a href="https://man.openbsd.org/sshd_config#AuthorizedPrincipalsFile" rel="nofollow noreferrer">AuthorizedPrinciplesFile</a>;</li>
<li>proxied client keys using tools such as CyberArk's <a href="https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PASIMP/Privileged-Session-Manager-SSH-Proxy-Introduction.htm" rel="nofollow noreferrer">Privileged Session Manager for SSH</a> that authenticates the user but never exposes the proxied private keys directly to either clients or servers;</li>
</ul>
or use various other server-side controls that limit who can present a given SSH key or certificate using server-specific features. For example, with OpenSSH you might look at:
<ul>
<li><a href="https://man.openbsd.org/sshd_config#Match" rel="nofollow noreferrer">sshd_config Match blocks</a> to restrict source IP addresses;</li>
<li>stacking additional PAM modules with <code>UsePAM yes</code> while ensuring that public key authentication by itself is not sufficient;</li>
<li>adding <a href="https://fidoalliance.org/what-is-fido/" rel="nofollow noreferrer">FIDO</a> as an additional MFA mechanism using the OpenSSH <a href="https://man.openbsd.org/sshd_config.5#PubkeyAuthOptions" rel="nofollow noreferrer">PubKeyAuthOptions</a> setting, with or without touch required; or</li>
<li>other client factors and server-side restrictions.</li>
</ul>
Note that most of these measures require additional infrastructure (such as a certificate authority system, hardware security module, additional software systems, or other administrative overhead) and administrative management, and may create other risks because key escrow itself can create vulnerabilities and potential breach targets.
<h2>Comparing Controls</h2>
Escrow solutions are often preventative controls, but come with all the security caveats of key escrow and key management. They also require the clients to trust the party performing the key escrow, and this can create problems for non-repudiation. On the other hand, most of the client-side solutions you might implement are detective controls, and are thus not suitable for use with untrusted clients, untrusted users, or environments where monitoring must be continuous.
That's why MFA is really the low-hanging fruit here. By combining something the user has (e.g. a presumatively-private SSH key) with something else such as a password, TOTP token, one-time password (e.g. <a href="https://en.wikipedia.org/wiki/S/KEY" rel="nofollow noreferrer">S/Key</a>, OPIE, <a href="https://www.cl.cam.ac.uk/%7Emgk25/otpw.html" rel="nofollow noreferrer">OTPW</a>, port knocking, or similar), you make it harder for simple possession of an unencrypted private key to be the sole means of access to a protected system.
<h2>See Also</h2>
<ul>
<li>Books and articles
<ul>
<li><a href="https://www.linuxjournal.com/content/configuring-one-time-password-authentication-otpw" rel="nofollow noreferrer">&quot;Configuring One-Time Password Authentication with OTPW&quot;</a>. Jacobs, Todd A. Linux Journal, Issue 225. (January 2013, pp. 76–88).</li>
<li><a href="https://rads.stackoverflow.com/amzn/click/com/1642350079" rel="nofollow noreferrer" rel="nofollow noreferrer">PAM Mastery (IT Mastery)</a>. Lucas, Michael W. Tilted Windmill Press, September 2016.</li>
<li><a href="https://rads.stackoverflow.com/amzn/click/com/B079NL1L9K" rel="nofollow noreferrer" rel="nofollow noreferrer">SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys (IT Mastery Book 12)</a>. Lucas, Michael W. Tilted Windmill Press; 2nd edition (February 6, 2018).</li>
<li><a href="https://rads.stackoverflow.com/amzn/click/com/B006H4GA0M" rel="nofollow noreferrer" rel="nofollow noreferrer">SSH, The Secure Shell: The Definitive Guide: The Definitive Guide Second Edition</a>. Barret, Daniel J. et al. O'Reilly Media; 2nd edition (May 10, 2005).</li>
</ul>
</li>
<li>Port-knocking tools and articles
<ul>
<li><a href="https://github.com/jvinet/knock#knock-a-port-knocking-implementation=" rel="nofollow noreferrer">knock: A port-knocking implementation</a></li>
<li><a href="https://github.com/mrash/fwknop#fwknop---single-packet-authorization=" rel="nofollow noreferrer">fwknop - Single Packet Authorization</a></li>
<li><a href="https://www.linuxjournal.com/article/9621" rel="nofollow noreferrer">&quot;Protecting SSH Servers with Single Packet Authorization&quot;</a></li>
</ul>
</li>
<li>OpenSSH
<ul>
<li><a href="https://man.openbsd.org/sshd_config" rel="nofollow noreferrer">sshd_config</a></li>
<li><a href="https://man.openbsd.org/ssh-keygen" rel="nofollow noreferrer">ssh-keygen</a></li>
<li><a href="https://man.openbsd.org/sshd" rel="nofollow noreferrer">sshd</a></li>
</ul>
</li>
</ul>

Did i misunderstand from this post?
<a href="https://security.stackexchange.com/a/26211/276794"> RequiredAuthentications2 | Usually this is done to require pubkey and 2-factor authentication token, not the user's password.</a>
<blockquote>
you can use RequiredAuthentications2 pubkey,password to require both pubkey and password authentication. Usually this is done to require pubkey and 2-factor authentication token, not the user's password.
</blockquote>
This mean you can login with a pubkey or with a password or do i need a pubkey with a password?
<blockquote>
<a href="https://man.openbsd.org/sshd_config.5#AuthenticationMethods" rel="noreferrer">AuthenticationMethods</a>
For example, &quot;publickey,password publickey,keyboard-interactive&quot; would require the user to complete public key authentication, followed by either password or keyboard interactive authentication. Only methods that are next in one or more lists are offered at each stage, so for this example it would not be possible to attempt password or keyboard-interactive authentication before public key.
</blockquote>
<code>AuthenticationMethods &quot;publickey,password&quot;</code>
<code>AuthenticationMethods &quot;publickey,password&quot; &quot;publickey,keyboard-interactive&quot;</code>
Is this the same like:
<pre><code>PubkeyAuthentication yes

PasswordAuthentication yes
</code></pre>
<blockquote>
For example, &quot;publickey,publickey&quot; requires successful authentication using two different public keys.
</blockquote>
This is an option too <code>&quot;publickey,publickey&quot;</code>
Instead of publickey and password required
publickey and publickey(2 publickey for login)
What's with <a href="https://man.openbsd.org/sshd_config.5#PubkeyAuthOptions" rel="noreferrer">PubkeyAuthOptions</a>
<blockquote>
The verify-required option requires a FIDO key signature attest that the user was verified, e.g. via a PIN.
</blockquote>
Is it possible in SSH to strict &quot;pubkey with a password&quot; required for login?

SSH strict "pubkey with a password" required for login?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我是不是从这篇文章中误解了？通常这样做是为了要求公开密钥和2因素身份验证令牌，而不是用户的密码。您可以使用RequiredAuthentications2公钥、密码同时要求公开密钥和密码身份验证。Usually这样做是为了要求公开密钥和2因素认证令牌，而不是用户的密码。这意味着您可以使用pubkey或密码登录，或者我需要密码的pubkey吗？例如，AuthenticationMethods，“公钥

问SSH严格的“带有密码的公钥”才能登录？
EN

回答 1

Security用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SSH严格的“带有密码的公钥”才能登录？EN