search for: yegor

That's not a very good source, since it's only available to one person. On Fri, May 25, 2018 at 7:12 AM, Peter Moody <mindrot at hda3.com> wrote: > On Thu, May 24, 2018 at 9:09 PM, Yegor Ievlev <koops1997 at gmail.com> wrote: >> How can I revoke one SSH certificate without having to replace the >> root certificate and all certificates signed by it? > > there is no chaining of ssh certificates. > >> Regarding the second statement, do you have sources...

e.g. can we make it throw warnings etc. rsa-sha2-256 and rsa-sha2-512 are fine, they use PSS. On Sun, Jan 20, 2019 at 1:55 AM Yegor Ievlev <koops1997 at gmail.com> wrote: > > Also can we do anything with ssh-rsa? It uses both SHA-1 and > deprecated PKCS#1 padding. If it's used to sign certificates, there's > no additional protection of SHA-2 hashing before SHA-1 signature, it > just signs the raw ce...

How can I revoke one SSH certificate without having to replace the root certificate and all certificates signed by it? Regarding the second statement, do you have sources? On Fri, May 25, 2018 at 6:58 AM, Peter Moody <mindrot at hda3.com> wrote: > On Thu, May 24, 2018 at 8:36 PM, Yegor Ievlev <koops1997 at gmail.com> wrote: > >> SSH certificates provide no >> way to revoke compromised certificates, > > this isn't true > >> and SSH certificates haven't seen significant adoption, > > this also isn't true. > > enterprises l...

Please tell me in technical details how current revocation support works, or give links. Then I will be able to give an answer. On Fri, May 25, 2018 at 7:16 AM, Damien Miller <djm at mindrot.org> wrote: > > > On Fri, 25 May 2018, Yegor Ievlev wrote: > >> Can you implement revocation support? > > What do you want that the existing revocation support lacks?

Zero matches in both. https://linux.die.net/man/5/sshd_config https://linux.die.net/man/5/ssh_config On Fri, May 25, 2018 at 7:48 AM, Damien Miller <djm at mindrot.org> wrote: > On Fri, 25 May 2018, Yegor Ievlev wrote: > >> Please tell me in technical details how current revocation support >> works, or give links. Then I will be able to give an answer. > > Please search for "revoke" in the ssh_config and sshd_config manual pages. >

there are more implications to changing key algorithms than KEX algorithms. If a change is made to the specification, then it might invalidate all the keys that are out there, this isn't the case with any other negotiated algorithm, On Sun, 27 May 2018, Yegor Ievlev wrote: > I don't think we should wait for a RFC in order to use stronger > crypto. We already prefer Curve25519 for key exchange without waiting > for it. So why wait for a RFC in this case? > > On Sun, May 27, 2018 at 5:09 AM, Damien Miller <djm at mindrot.org> wr...

On Mon, 28 May 2018, Yegor Ievlev wrote: > Can we prefer RSA to ECDSA? For example: > HostKeyAlgorithms > ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 not without a good reason

I don't think there is any point to generate so many moduli. Actually, 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice. On Fri, Feb 15, 2019 at 7:58 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 14:22, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I'm not nearly knowledgeable enough in crypto to fully understand your > > answer, but I will try. I wonder why moduli are not automatically > > generated the first time sshd is started though. That would make much > > mor...

Steps to reproduce: 1. Run a SSH server with default configuration and point a domain to it. 2. Add SSHFP record to the domain, but only for Ed25519 key. 3. Attempt to connect with VerifyHostKeyDNS set to yes, but the rest of settings set to defaults. 4. OpenSSH defaults to ECDSA instead of Ed25519 and refuses connection because there is no ECDSA fingerprint in SSHFP records. A stopgap solution

On Sat, 26 May 2018, Christian Weisgerber wrote: > On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote: > > > The defaults for HostKeyAlgorithms option are: [...] > > Why does OpenSSH prefer older and less secure > > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? > > I asked Markus and Damien about this in...

I'm not sure if collision resistance is required for DH key derivation, but generally, SHA-1 is on its way out. If it's possible (if there's not a very large percentage of servers that do not support anything newer), it should be disabled.

I suggest deprecating proprietary SSH certificates and move to X.509 certificates. The reasons why I suggest this change are: X.509 certificates are the standard on the web, SSH certificates provide no way to revoke compromised certificates, and SSH certificates haven't seen significant adoption, It's also a bad idea to roll your own crypto, and own certificate format seems like an example

...N.1 parsing would have brought. > > If you really want X.509 certificates, then I'd recommend Roumen > Petrov's patches: https://roumenpetrov.info/secsh/ -- he's done a > fine job of maintaing these over an extended period of time. > > -d > > On Fri, 25 May 2018, Yegor Ievlev wrote: > >> I suggest deprecating proprietary SSH certificates and move to X.509 >> certificates. The reasons why I suggest this change are: X.509 >> certificates are the standard on the web, SSH certificates provide no >> way to revoke compromised certificates, an...

Compressing data before encryption may be dangerous, for example CRIME, BREACH and VORACLE. Can compression be disabled by default in OpenSSH, only being enabled if user requests it? Another scenario when SSH compression may be bad is use of commands like tar cz | ssh root at remote "tar xz", which seem pretty common. If SSH compression is enabled, data will be (wastefully) compressed

Well, SSHFP is supposed to only be used on DNSSEC-enabled domains. On Sat, Feb 23, 2019 at 9:59 PM Peter Stuge <peter at stuge.se> wrote: > > Yegor Ievlev wrote: > > It would make more sense to treat SSHFP records in the same way as > > known_hosts > > I disagree with that - known_hosts is nominally a client-local configuration. > > I think it's a very bad idea to have the client start treating foreign network >...

...why this is a bug is, for example, that if the server was updated and it re-generated the ECDSA key you deleted, you would have to do some non-obvious steps for your client to ignore it. On Sat, Feb 23, 2019 at 11:49 AM Damien Miller <djm at mindrot.org> wrote: > > On Fri, 22 Feb 2019, Yegor Ievlev wrote: > > > Steps to reproduce: > > 1. Run a SSH server with default configuration and point a domain to it. > > 2. Add SSHFP record to the domain, but only for Ed25519 key. > > 3. Attempt to connect with VerifyHostKeyDNS set to yes, but the rest > > of sett...

That doesn't seem to be the case. See https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf (5.6.1 Comparable Algorithm Strengths) On Fri, Feb 15, 2019 at 8:28 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 16:00, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I don't think there is any point to generate so many moduli. Actually, > > 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice. > > NIST SP 800-57 Part 1, on which the current group size selection code > is based, p...

Well, known_hosts isn't exactly trusted input, since it's usually composed of the keys you first encounter, without any additional checking, as opposed to (hopefully) correctly signed SSHFP records. On Sat, Feb 23, 2019 at 10:22 PM Peter Stuge <peter at stuge.se> wrote: > > Yegor Ievlev wrote: > > > I think it's a very bad idea to have the client start treating foreign > > > network input as equivalent to local configuration. > > > > Well, SSHFP is supposed to only be used on DNSSEC-enabled domains. > > To the client it's still fo...

The defaults for HostKeyAlgorithms option are: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com, ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519,ssh-rsa Why does OpenSSH prefer older and less secure

...n-group-exchange-sha1/sha256 chosen? Are they chosen randomly by developers or are they chosen for security properties? If they are random, why not use moduli from RFC 7919 instead, like Mozilla recommends? On Fri, Feb 15, 2019 at 3:48 AM Mark D. Baushke <mdb at juniper.net> wrote: > > Yegor Ievlev <koops1997 at gmail.com> writes: > > > Can we disable diffie-hellman-group14-sha1 too? > > It is possible to disable the diffie-hellman-group14-sha1 key exchange, > but I personally recommend you just put it at the end of the list, so it > is not normally used for...