similar to: Hostbased login based on SSHFP DNS records?

Hi, is there any way to use hostbased authentication without the need to have the SSH host keys stored in a known_hosts file? We run a large cluster where we need to have passwordless remote login available. We currently do that with hostbased SSH authentication. But it is error-prone and a lot of work to keep the known_hosts file up to date on all hosts. (This is the same situation like DNS vs

Hi, I'm running rsync-3.0.4 on my UNIX system. I've just updated from rsync-2.6.9. I'm facing a general problem with the execution of files during a transfer process. The situation: 2 Directories (dir1 and dir2) on one machine with a some files in dir1 which shall be translated to dir2. rsync does not correctly recognize dir1 and dir2 as directories. It tries to transfer dir1 as a

Dear openssh-unix-dev list, in OpenSSH 5.1 you introduced CIDR address/masklen matching for "Match address" blocks in sshd_config as well as supporting CIDR matching in ~/.ssh/authorized_keys from="..." restrictions in sshd. I wonder whether CIDR address/masklen matching will be implemented for permitopen="host:port" restrictions in sshd as well, that would be quite

On Wed, 27 Aug 2008, Damien Miller wrote: > On Tue, 26 Aug 2008, Peter Stuge wrote: > > On Fri, Aug 22, 2008 at 11:22:34AM +0200, Bert Courtin wrote: > > > I wonder whether CIDR address/masklen matching will be implemented > > > for permitopen="host:port" restrictions in sshd as well, that would > > > be quite beneficially (at least for me, maybe

Hi, I'm new to rsync and currently installing rsync-3.0.3 to a OS/390 Unix System Services environment. The build process runs fine and does not produce errors. But if I test the program, it crashes everytime with a protection exception. rsync-2.6.9 was running fine! I can't figure out why exactly it crashes. I hope that someone on this list can give me a hint on that. This is the debug

Hi there, I'm attempting to use color2D.matplot(x,cellcolors=cellcol, do.hex=TRUE) from the plotrix package, but do not want to have borders around the hexagons. I've tried various approaches such as fg="white", col="white", lty=0, lwd=0 and border=NULL/FALSE/"white", but none of them works. I'd appreciate any ideas. Thanks, John -- GMX Kostenlose

Hello, I'm coming from Slackware and I'm searching for another distribution to run on my desktop and in near future also on a server. The *top priority* for me is security! I've test-installed CentOS on one of my test systems. So far anything went OK. After trying a bit, I would like to ask some questions: - What is the suggested way to get *secure and trusted* additional packages?

Hi everyone. I'm running icecast and ices2 on OpenSuse 10.2 (could upgrade to 11.0 in a breeze though). What I'm trying to achieve right now is to use this for a kind of "baby-phone" functionality. That means: 1. There is a microphone attached to the server which records sound in the room 2. I'm in another room, listening to the server on Winamp, so I can hear what goes on

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

In the current implementation, ssh always uses the hostname supplied by the user directly for the SSHFP DNS record lookup. This causes problems when using the domain search path, e.g. I have "search example.com" in my resolv.conf and then do a "ssh host", I will connect to host.example.com, but ssh will query the DNS for an SSHFP record of "host.", not

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

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

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.

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

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2223 Bug ID: 2223 Summary: Ed25519 support in SSHFP DNS resource records Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

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

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