Displaying 20 results from an estimated 30000 matches similar to: "sshfp (ssh+dns) code updated"
2015 Jun 22
2
Small issue with DNSSEC / SSHFP
Hi,
I found a small issue with DNSSEC validation of SSHFP lookups. (For reference
I used OpenSSH 6.8p1 on FreeBSD 10.1).
The issues is that when DNSSEC valiation fails, ssh displays a confusing
message to the user. When DNSSEC validation of a SSHFP record fails, ssh
presents the user with
"Matching host key fingerprint found in DNS.
"Are you sure you want to continue connecting
2019 Feb 22
4
Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting.
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
2012 May 09
4
feature request: modify getrrsetbyname() to use libunbound
Dear OpenSSH Developers,
I'm a member of the Debian System Administration (DSA) team. [1] We
manage the Debian Projects computing infrastructure.
Recently, DSA had the opportunity to address a member's request that we
begin using certificates to authenticate Debian Project machines to ssh
clients. We provided a lengthy reply, the summary of which is "we
publish SSHFP records; use
2024 Jun 05
1
[Bug 3698] New: SSHFP validation fails when multiple keys of the same type are found in DNS
https://bugzilla.mindrot.org/show_bug.cgi?id=3698
Bug ID: 3698
Summary: SSHFP validation fails when multiple keys of the same
type are found in DNS
Product: Portable OpenSSH
Version: 8.7p1
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: ssh
2019 Feb 23
2
Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting.
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
2012 Jun 26
2
[Bug 2022] New: ssh segfaults when using ldns, SSHFP, a DNSSEC-enabled resolver and a CNAME
https://bugzilla.mindrot.org/show_bug.cgi?id=2022
Bug #: 2022
Summary: ssh segfaults when using ldns, SSHFP, a DNSSEC-enabled
resolver and a CNAME
Classification: Unclassified
Product: Portable OpenSSH
Version: 6.0p1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
2019 Feb 23
2
Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting.
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
2019 Feb 23
3
Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting.
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
2011 Jul 20
1
auto-accept keys matching DNSSEC-validated SSHFP records
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
2015 Nov 18
2
Missing SSHFP RRs / VerifyHostKeyDNS & StrictHostKeyChecking
Y'all,
Currently (OpenSSH_7.1p1) no distinction is made between when an SSHFP
RR is missing
from the result set (rather then being empty), which can lead to
confusing error messages,
(the "normal" warn_changed_key() blurb is emitted) e.g. when the
presented host key and
known hosts both match but there is no matching RR.
Further, if VerifyHostKeyDNS and StrictHostKeyChecking are
2012 Aug 31
9
[Bug 2040] New: Downgrade attack vulnerability when checking SSHFP records
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
2014 Oct 06
0
Announce: OpenSSH 6.7 released
OpenSSH 6.7 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.
Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches,
2018 Jan 10
4
sshfp/ldns still having issues in 7.6
I have been running openSSH 7.4p1 for a while now. When I upgraded to 7.5 a
year or so ago I ran into the problem listed in this bug report:
Bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218472
The release notes for 7.6 release notes indicate that the fix patch was
included: https://www.openssh.com/txt/release-7.6
I tried 7.6 and I still cannot connect without a prompt wondering
2012 Jan 04
0
ECDSA, SSHFP, and "Error calculating host key fingerprint."
When connecting to a host that provides an ECDSA host key and the
client has "VerifyHostKeyDNS" set to 'yes' or 'ask' SSH outputs a
mysterious and undocumented message "Error calculating host key
fingerprint." This error actually seems to be generated by
verify_host_key_dns(const char *hostname, struct sockaddr *address,
Key *hostkey, int *flags) in dns.c, but
2013 Jun 09
7
[Bug 2119] New: SSHFP with DNSSEC – no trust anchors given, validation always fails
https://bugzilla.mindrot.org/show_bug.cgi?id=2119
Bug ID: 2119
Summary: SSHFP with DNSSEC ? no trust anchors given, validation
always fails
Product: Portable OpenSSH
Version: 6.2p1
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P5
Component:
2013 May 22
0
SSHFP support for ssh-keyscan?
Greetings,
Has anyone looked at implementing SSHFP support for ssh-keyscan?
It should be a rather easy task, but I would like to make sure no one else is doing this before I start.
jakob
2023 Mar 15
0
Announce: OpenSSH 9.3 released
OpenSSH 9.3 has just been released. It will be available from the
mirrors listed at https://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support.
Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested
2012 Aug 31
1
[Bug 2041] New: Check for SSHFP when certificate is offered.
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
2008 Oct 17
1
Hostbased login based on SSHFP DNS records?
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
2007 May 21
1
[PATCH] Add support for ldns
Hi,
as discussed before, we're trying to make use of SSHFP records (RFC
4255) to publish host key fingerprints in the DNS.
However, some non-OpenBSD platforms don't support DNSSEC in the native
resolver (e.g. glibc), which renders the whole thing quite useless,
since openssh correctly requires the RRs to be signed and validated.
The following patch adds support for ldns, an external