search for: continusec

https://bugzilla.mindrot.org/show_bug.cgi?id=2617 Bug ID: 2617 Summary: sign_and_send_pubkey: no separate private key for certificate Product: Portable OpenSSH Version: 7.3p1 Hardware: 68k OS: Mac OS X Status: NEW Severity: normal Priority: P5 Component: ssh

...mmand line tool which does SSO with Google Apps, then generates a new SSH key pair, and sends this off to an internal service which verifies the request and then issues a new short lived (24 hour) certificate (if interested the code for the server and client is open-sourced here: https://github.com/continusec/geecert), overwriting the previous certificate and private key. Some of our users like to use SSH agent forwarding, and while this generally works fine, when our users run their daily command to get a new certificate, their ssh-agent still holds the old one. Would it be reasonable to write a patc...

...me Product: Portable OpenSSH Version: 7.4p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh-add Assignee: unassigned-bugs at mindrot.org Reporter: adam at continusec.com Created attachment 2935 --> https://bugzilla.mindrot.org/attachment.cgi?id=2935&action=edit First cut of patch For users that regularly receive new short-lived certificates, it is useful to be able to add these to ssh-agent without the list of identities continually growing. Since s...

On Mon, May 15, 2017 at 11:39 AM, Peter Moody <mindrot at hda3.com> wrote: > my reading of the sshd manpage is that ssh is more permissive than it should be > > SSH_KNOWN_HOSTS FILE FORMAT : > ... > > A hostname or address may optionally be enclosed within `[' and `]' > brackets then followed by `:' and a non-standard port number. Hi Peter, I'm not

Hi all, Last week I noticed that the CertChecker in the Go implementation of x/crypto/ssh seems to be doing host principal validation incorrectly and filed the following bug: https://github.com/golang/go/issues/20273 By default they are looking for a principal named "host:port" inside of the certificate presented by the server, instead of just looking for the host as I believe OpenSSH

On Thu, Feb 2, 2017 at 1:16 AM, Peter Moody <mindrot at hda3.com> wrote: > why not add the certificate to the running ssh-agent with a timeout > that expires when the cert does? That's an excellent idea. I've modified our tooling to do exactly that (https://github.com/continusec/geecert/commit/dfeee14b278e28d15bf532bb6e6e8ffe530e6b11). Thank you for the suggestion. > I don't think ssh-agent exposes a "how long until this key expires" > api, but you can at least use this method to see if the cert/key are > *on* the agent and you can assume that if t...

> (Blargh is right (https://blog.habets.se/2011/07/OpenSSH-certificates.html <https://blog.habets.se/2011/07/OpenSSH-certificates.html>). Googling for this stuff is *hard*:) Does https://www.sweharris.org/post/2016-10-30-ssh-certs/ help at all? Stephen

Hi OpenSSH developers; Thank you for your amazing work. I?m emailing to see if any knowledgeable OpenSSH developer is willing to help us review / revamp some patches we have for OpenSSH, and provide advice on some of the more advanced uses of OpenSSH. This would be a for pay contract engagement. We are trying to be super respectful of the process, and are happy to be very creative ? we are

Damien Miller wrote: > On Thu, 2 Feb 2017, Adam Eijdenberg wrote: > >> On Thu, Feb 2, 2017 at 10:42 AM Damien Miller <djm at mindrot.org> wrote: >>> On Thu, 2 Feb 2017, Adam Eijdenberg wrote: >>>> I guess a case could be made for ssh-add to always set a timeout when >>>> adding a certificate with an expiry time, but I think for now I'm

On Thu, Feb 2, 2017 at 10:42 AM Damien Miller <djm at mindrot.org> wrote: > On Thu, 2 Feb 2017, Adam Eijdenberg wrote: > > I guess a case could be made for ssh-add to always set a timeout when > > adding a certificate with an expiry time, but I think for now I'm > > happy enough to do that on our end. > > That sounds like a fine idea. Damien, to clarify did

On Thu, Oct 11, 2018 at 10:41 AM Damien Miller <djm at mindrot.org> wrote: > On Wed, 10 Oct 2018, Adam Eijdenberg wrote: > > We see this error on the client side: > > > > debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> > > ... > > debug1: Offering public key: RSA-CERT SHA256:xxx /path/to/key > > debug1: send_pubkey_test: no

On Wed, May 17, 2017 at 2:46 AM, Damien Miller <djm at mindrot.org> wrote: > On Mon, 15 May 2017, Adam Eijdenberg wrote: >> https://github.com/golang/go/issues/20273 >> >> By default they are looking for a principal named "host:port" inside >> of the certificate presented by the server, instead of just looking >> for the host as I believe OpenSSH

Hi, One of our users who is running an OS (I think it's the latest beta macOS 10.14.1) with ssh version "OpenSSH_7.8p1, LibreSSL 2.7.3" is unable to use our user SSH RSA certificates to authenticate to our servers (which are running "OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017"). We see this error on the client side: debug1: kex_input_ext_info: