similar to: connecting to a virtual host: host key mismatch

On 2024-10-17 19:26, Nico Kadel-Garcia wrote: > > Thank you! Increasing the verbosity revealed a known_hosts entry linked > > to serverA's IP address (I had forgotten that I had connected to it by > > IP address at some point). Deleting this entry solved the problem; the > > new host key was stored in known_hosts when I connected to serverA > > again. > >

On Mon, Oct 14, 2024 at 5:33?AM Jan Eden via openssh-unix-dev <openssh-unix-dev at mindrot.org> wrote: redacted hostname and port ? sorry, should have mentioned that. > > > Anyway, in answer to your question. The "host key found matching a different > > name/address" is triggered when a key received from the server in an update > > already exists under a

On 03/15/2019 12:49 AM, Jeremy Lin wrote: > [...] connecting to hosts where the host key > changes frequently. I realize this is a fairly niche use case [...] Doesn't StrictHostKeyChecking=no do what is wanted?

Folks, I read the 5.7 release announcement and updated, to try out ECDSA. Most parts worked very smoothly. The inability to create SSHFP records is understandable, since IANA haven't allocated a code yet. One apparent bug: I think StrictHostKeyChecking=ask is broken for ECDSA. % ssh -o HostKeyAlgorithms=ecdsa-sha2-nistp256 localhost

https://bugzilla.mindrot.org/show_bug.cgi?id=2400 Bug ID: 2400 Summary: StrictHostKeyChecking=no behaviour on HOST_CHANGED is excessively insecure Product: Portable OpenSSH Version: 6.8p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component:

Hello, I just received thes odd messages from HP-UX Secure Shell A.03.50.000. (OpenSSH 3.5p1): # ssh-add id_rsa.pub 5215: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5215: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ 5215: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 5215: Permissions 0644 for 'id_rsa.pub' are too open. 5215: It is

https://bugzilla.mindrot.org/show_bug.cgi?id=3176 Bug ID: 3176 Summary: can't figure out how to test StrictHostKeyChecking accept-new Product: Portable OpenSSH Version: 8.3p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh

Hello, with OpenSSH_2.3.0p1 running in HP-UX 11.00 I noticed that the "SD commands" (like "swcopy") produce the following error when being logged in via SSH: ERROR: RPC exception: "Who are you failed (dce / rpc)" 11/29/00 11:20:18 MET Ideas? Regards, Ulrich P.S. Not subscribed to the list

The build bug: DESTDIR=$SOMEDIR does not work: mkdir ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/sbin/sshd -t -f ${HOME}/tools/openssh/openssh-5.0p1/_i/usr/local/etc/sshd_config Could not load host key: /usr/local/etc/ssh_host_rsa_key Could not load host key: /usr/local/etc/ssh_host_dsa_key Disabling protocol version 2. Could not load

Hello Jean-Marc, As an example, I am using the output of opus encoder to store the file as the following format and read back the same during decode process, without having much overhead. (Thought it would be useful to put a picture rather than running text) [image: Inline image 2] Regards Amit On Thu, May 12, 2016 at 10:47 AM, Amit Ashara <ashara.amit at gmail.com> wrote: > Hello

>>> Ralph Giles <giles at thaumas.net> schrieb am 21.12.2015 um 19:51 in Nachricht <CAEW_RkshUM55uwdvU6DsE17pLZki651Xvvu7d2Y6jObePXZwCQ at mail.gmail.com>: > On 21 December 2015 at 04:31, Ulrich Windl > <Ulrich.Windl at rz.uni-regensburg.de> wrote: > >> opusenc does not display the file name it processes. In Lunux when you use > some batch processing,

The last line of the example in droplevels' manual page seems to be incorrect to me. I think it should read: "table(droplevels(aq$Month))". Amazingly (I don't understand) both variants seem to produce the same result (R 3.3.3): --- > aq <- transform(airquality, Month = factor(Month, labels = month.abb[5:9])) > aq <- subset(aq, Month != "Jul") >

Hi! Sorry, I know the rules for comparing objective subjective listening impressions, but I'd like to know whether from the algorithmic or implementer's point of view the following personal impressions can be confirmed: Comparing MP3 with Vorbis at rather high bitrates, I had the impression the Vorbis sounded more crispy, while MP3 sounded somewhat softened. I preferred Vorbis for that

On 2024-10-14 14:48, Damien Miller wrote: > On Sun, 13 Oct 2024, Jan Eden via openssh-unix-dev wrote: > > When I connect to serverA (`ssh -v -o UpdateHostKeys=yes serverA`) > > afterwards, known_hosts on the client is not updated. The output of the > > ssh command contains this: > > > > debug1: Host '[serverA.domain.internal]:22' is known and matches the

Perfect, thanks. This winds up working for me (as far as I've tested so far.) Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'" StrictHostKeyChecking no UserKnownHostsFile none On Wed, Aug 26, 2015 at 11:47 PM, Bostjan Skufca <bostjan at a2o.si> wrote: > (+cc list) > > You could use something in the following manner: > > Match originalhost *

Hello & thanks for reading. I'm having a problem configuring known_hosts from scripts so an accept key yes/no prompt doesn't appear. I'm using this command to detect if the server is known and add it to known_hosts: if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null 2>&1; t hen ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi This works

Hi! I was just trying libopus0-1.1-3.2.x86_64 and opus-tools-0.1.9-3.2.x86_64 on openSUSE Leap, and I was wondering: opusenc does not display the file name it processes. In Lunux when you use some batch processing, it might be interesting! Example output for "for f in *.wav;do opusenc --bitrate 160 $f ${f%.wav}.opus; done": ---just on file--- Encoding using libopus 1.1 (audio)

Hi Ulrich, As Jean-mark recommended, we created "--enable-check-asm" config option to active OPUS_CHECK_ASM macros in the optimization, where the C function is called inside and the results of C and optimization functions are compared when encoding/decoding the real audio files. Thanks, Linfeng On Wed, Apr 19, 2017 at 11:46 PM, Ulrich Windl < Ulrich.Windl at

On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote: > On Sun, 2020-10-04 at 14:02 +1100, Damien Miller wrote: > > This is strictly no worse than continuing to use the old key, so I > > don't consider it a problem. > > Well but in reality it will lead to people never again replace their > key by proper means. Well, first I disagree that this method is improper. The

The overhead of Ogg (in file size) is pretty small and it's efficient enough for most applications (and uses far less CPU than the codec anyway). If anything, you might want to look at optimizing the existing Ogg implementation (e.g. like Tremor did in the context of Vorbis). Of course, you're always free to design a new container, but I doubt it's worth it and it's a lot of work