similar to: [Bug 2223] New: Ed25519 support in SSHFP DNS resource records

Hello. Subramanian Moonesamy has gotten the ball rolling to include Ed25519 in IANA's registry for SSHFP key types [1]. I've opened a bug report [2] that includes a patch that adds the needed support code and provisionally assigns Ed25519 a value of 4 (values 1,2,3 reserved for RSA, DSA, and ECDA, respectively) [3]. The enhancement request/bug is meant to keep the issue on the radar.

https://bugzilla.mindrot.org/show_bug.cgi?id=2197 Bug ID: 2197 Summary: Add ED25519 support to SSHFP dns record Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

The IANA has pre-allocated id 4 for ed25519. If waiting on the IANA were a reason to delay applying the SSHFP_KEY_ED25519 patch, it needn't be any longer. I've proposed un-reserving hash type 0 to be a "NULL hash", for those who'd rather publish the public key unhashed. Even if zero for unhashed fails to gain traction, I hope to see something allocated for that. But

https://bugzilla.mindrot.org/show_bug.cgi?id=2220 Bug ID: 2220 Summary: Add uuid-style identifier for use with ControlPath Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs

Hi, we're currently considering making use of RFC4255 SSHFP records, but are hitting a problem with a 4.4p1 client running on Tru64 5.1A: [...] debug3: verify_host_key_dns DNS lookup error: out of memory [...] No matching host key fingerprint found in DNS. A 4.3p2 linux client gives the following : [...] debug3: verify_host_key_dns debug1: found 1 insecure fingerprints in DNS debug1:

hi folks: it looks like ssh-keygen -r can''t export SSHFP records for ECDSA keys: 0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P '''' 0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub export_dns_rr: unsupported algorithm 0 dkg@pip:/tmp/cdtemp.oiRYAS$ the first number in my prompt is the return code of the last command; note that

Hi All, I've been working on a diff to get SSHFP support for ed25519 in OpenSSH. SM has been working through the IETF process to obtain the SSHFP RR Type number. Despite getting "rough consensus", we still haven't heard anything from the IETF Security Directors for the draft. SM sent a mail asking why it is taking so long, and it appears that his mail was ignored. Please see:

https://bugzilla.mindrot.org/show_bug.cgi?id=1972 Daniel Black <daniel.black at ovee.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.black at ovee.com.au Keywords| |openbsd, patch --- Comment #2

Have you seen this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513 --mancha

Hi. Last night on an irc openssh channel, a user brought up a use case involving cluster trees and very descriptive (i.e. long) hierarchical hostnames. To make a long story short, his ControlPath (~/.ssh/control-master /%r@%h:%p) was bumping up against UNIX_PATH_MAX. Attached patch adds a new percent-token (%H) that expands to the sha1 digest of the concatenation of host (%h) + port (%p) +

I read an article today about keyboard interactive auth allowing bruteforcing. I'm afraid I have minimal understanding of what keyboard-interactive really does. What does it do, and should I have my clients set it to off in sshd_config? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |

On Wed, May 27, 2015 at 05:08:25PM -0400, Daniel Kahn Gillmor wrote: > On Tue 2015-05-26 15:39:49 -0400, Mark D. Baushke wrote: > > Hi Folks, > > > > The generator value of 5 does not lead to a q-ordered subgroup which > > is needed to pass tests in > > > > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf > > I

https://bugzilla.mindrot.org/show_bug.cgi?id=2041 Priority: P5 Bug ID: 2041 Assignee: unassigned-bugs at mindrot.org Summary: Check for SSHFP when certificate is offered. Severity: enhancement Classification: Unclassified OS: All Reporter: ondrej at caletka.cz Hardware: All Status: NEW

Hi, I was sure I sent this to openssh at openssh.com, but cannot find that email now in my Sent mailbox, so I am sending it to the developers list. I took a liberty and wrote an I-D with accompanying patch (with contributions from Ondrej Caletka) to support ECDSA in the SSHFP DNS resource record. The I-D is here: https://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2 (and the source XML

Hi, is it possible to use SSHFP DNS records to enable password-free host-based login? What I already got working is to use SSHFP DNS records to verify the server host keys. debug1: found 2 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS But hostbased login does not work and I still need to supply a password to log in. (Or to configure a known_hosts file on the

The reason 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

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

Greetings. I've set up several sshfp records some time ago. Everything works great except the way openssh chooses the sshfp record. Now it looks liek the client asks for the name supplied on the command line. It might be a bit trouble some since there are at least three ways to set up some aliases and at leas one of them is secure. I propose an alternative way which even seems more robust

https://bugzilla.mindrot.org/show_bug.cgi?id=2040 Priority: P5 Bug ID: 2040 Assignee: unassigned-bugs at mindrot.org Summary: Downgrade attack vulnerability when checking SSHFP records Severity: minor Classification: Unclassified OS: All Reporter: ondrej at caletka.cz Hardware: All

Hi, I submitted a patch back in November of 2009 to add local validation of DNSSEC record to openssh. I recent updated the patch for 5.8, and figured I do a little marketing while I'm at it. :-) Someone had previously submitted a patch which simply trusted the AD bit in the response, which is susceptible to spoofing by anyone who can inject packets between the resolver and the client. Our