similar to: SSH certificates - restricting to host groups

On Thu, Jan 30, 2020 at 7:11 AM Christian, Mark <mark.christian at intel.com> wrote: > > On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote: > > As a concrete example: I want Alice to be able to login as "alice" > > and > > "www" to machines in group "webserver" (only). Also, I want Bob to > > be > > able to login as

On 30/01/2020 15:02, Christian, Mark wrote: > On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote: >> As a concrete example: I want Alice to be able to login as "alice" >> and >> "www" to machines in group "webserver" (only). Also, I want Bob to >> be >> able to login as "bob" and "www" to machines in group

On 30/01/2020 12:53, Michael Str?der wrote: > On 1/30/20 1:27 PM, Brian Candler wrote: >> I am trying to work out the best way to issue SSH certificates in such >> way that they only allow access to specific usernames*and* only to >> specific groups of host. > I also thought about this for a while. The only idea I came up with is > to have separate CAs used as trust

https://bugzilla.mindrot.org/show_bug.cgi?id=2487 Bug ID: 2487 Summary: AuthorizedPrincipalsCommand should probably document whether it only applies to TrustedUserCAKeys CAs Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement

I know that there are some methods to use federated identities (e.g. OAuth2) with SSH authentication but, from what I've seen, they largely seem clunky and require users to interact with web browsers to get one time tokens. Which is sort of acceptable for occasional logins but doesn't work with automated/scripted actions. I'm just wondering if anyone has done any work on this or

On 1/30/20 5:48 PM, Christian, Mark wrote: > On Thu, 2020-01-30 at 16:37 +0000, Brian Candler wrote: >> I was hoping to avoid the dependency on configuration management by >> carrying the authorization in the certs themselves - if that is in >> the spirit of the SSH cert mechanism. > > Sign alice and bob's ssh cert with principal's alice,www and bob,www >

Hello: I am working to implement certificate-based authentication for some internal applications. It would be very helpful to be able to pass information server-side by specifying some custom options via the Extensions of the signed certificate, allowing the authenticity of the options to be verified readily. However, I have not been able to find too much for specifying behaviors, etc.

hi,all i've read the openssh5.6 new feature document about new option AuthorizedPrincipalsFile,and tried to config the sshd_config for a lot times,but still not succeed. maybe i am still ambiguously about the document's meaning. The main problem is i don't know what's the content(or file format) in the file that specifed by the AuthorizedPrincipalsFile option. could you give me a

On 18/09/18, Tim Jones (b631093f-779b-4d67-9ffe-5f6d5b1d3f8a at protonmail.ch) wrote: ... > So issue your users with Yubikeys. You can enforce the Yubikey so it > requires the user to enter a PIN *and* touch the Yubikey. This means > there's an incredibly high degree of confidence that it was the user > who performed the actiion (i.e. two-factor authentication of physical >

Hi, Users who are interested in certificate authentication might be interested in this change: > - djm at cvs.openbsd.org 2010/05/07 11:30:30 > [auth-options.c auth-options.h auth.c auth.h auth2-pubkey.c key.c] > [servconf.c servconf.h sshd.8 sshd_config.5] > add some optional indirection to matching of principal names listed > in certificates. Currently, a

https://bugzilla.mindrot.org/show_bug.cgi?id=2288 Bug ID: 2288 Summary: documentation of options defaulting to "none" Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: Documentation Assignee:

As background, I read: http://therowes.net/~greg/2011/03/23/ssh-trusted-ca-key/ http://www.ibm.com/developerworks/aix/library/au-sshsecurity/ http://bryanhinton.com/blog/openssh-security http://www.linuxhowtos.org/manpages/5/sshd_config.htm

On 31/01/2020 15:37, Michael Str?der wrote: > (BTW: yubikey is slow. So if you have admins accessing many machines in > one go you will get a notable latency during first SSH connection.) I meant using a single Yubikey as the CA sign the certificates. I'm thinking of an organization where the number of admins is in the low tens.? The end-game of having daily keys and certs loaded

Any caveats with using AuthorizedKeysCommand in this case? From: Damien Miller<mailto:djm at mindrot.org> Sent: Monday, May 20, 2019 6:37 PM To: Nickolas Klue<mailto:nickolas.klue at thoughtspot.com> Cc: openssh-unix-dev at mindrot.org<mailto:openssh-unix-dev at mindrot.org> Subject: Re: OpenSSH Certificate Extensions On Mon, 20 May 2019, Nickolas Klue wrote: > Hello: >

Hello, [if I'm not in the right mailing list, please advise it to me] I'm using ssh certificates for my servers and my users. I have questions about it: I can use the same CA in order to certify all my hosts. Every clients can use it, and it's a great setup. But, if I use the same CA for all my clients, it means that any clients can log in to any server because hosts trusts my

On 04/27/2016 12:30 AM, James Hogarth wrote: *snip* > > Unless you have a very specific requirement for a very bleeding edge > feature it's fundamentally a terrible idea to move away from the > distribution packages in something as exposed as a webserver ... I use to believe that. However I no longer. First of all, advancements in TLS happen too quickly. The RHEL philosophy of

I am trying to supplement and ultimately provide a patch for ''foreman'' which is an adjunct to puppet. Essentially, there is a Hosts class which belongs_to Hostgroup and Hostgroup class has a column called ''ancestry'' which is actually a Hostgroup (probably what is referred to as STI but I am not sure) and thus within Foreman, nesting Hostgroups is not uncommon.

HI! I'm looking at sshd(8), section AUTHORIZED_KEYS FILE FORMAT and description for CLI arg -O in ssh-keygen(1). It seems to me that there could be a 1:1 mapping between SSH cert extensions and authz key options by just adding prefix "permit-" to the key option. But the man pages differ regarding case of "permit-x11-forwarding" and "X11-forwarding". [1] also

https://bugzilla.mindrot.org/show_bug.cgi?id=3574 Bug ID: 3574 Summary: ssh ignores AuthorizedPrincipalsCommand if AuthorizedKeysCommand is also set Product: Portable OpenSSH Version: 9.3p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component:

Hello world: Has anyone used hex notation within R to represents integers? Cheers, Steve Vejcik