similar to: ssh host keys on cloned virtual machines

On Fri, 24 Feb 2023, Keine Eile wrote: > does any one of you have a best practice on renewing ssh host keys on cloned > machines? Yes: not cloning machines. There?s too many things to take care of for these. The VM UUID in libvirt. The systemd machine ID. SSH hostkey and SSL private key. The RNG seed. The various places where the hostname is written to during software installation. The

On Sun, Feb 26, 2023 at 2:51?PM Thorsten Glaser <t.glaser at tarent.de> wrote: > > On Fri, 24 Feb 2023, Keine Eile wrote: > > > does any one of you have a best practice on renewing ssh host keys on cloned > > machines? > > Yes: not cloning machines. Good luck with *that*. Building VM's from media is a far, far too lengthy process for production deployment,

On Fri, Feb 24, 2023 at 10:01 AM Jochen Bern <Jochen.Bern at binect.de> wrote: > > On 24.02.23 12:58, Keine Eile wrote: > > does any one of you have a best practice on renewing ssh host keys on > > cloned machines? > > I have a customer who never thought about that, while cloning all VMs > > from one template. Now all machines have the exact same host key. >

On 2/25/23 07:50, Nico Kadel-Garcia wrote: > On Fri, Feb 24, 2023 at 10:01 AM Jochen Bern <Jochen.Bern at binect.de> wrote: >> >> On 24.02.23 12:58, Keine Eile wrote: >>> does any one of you have a best practice on renewing ssh host keys on >>> cloned machines? >>> I have a customer who never thought about that, while cloning all VMs >>>

On Sat, Feb 25, 2023 at 12:14?PM Demi Marie Obenour <demiobenour at gmail.com> wrote: > > On 2/25/23 07:50, Nico Kadel-Garcia wrote: > > On Fri, Feb 24, 2023 at 10:01 AM Jochen Bern <Jochen.Bern at binect.de> wrote: > >> > >> On 24.02.23 12:58, Keine Eile wrote: > >>> does any one of you have a best practice on renewing ssh host keys on >

I conjecture that only few of the existing use cases rely on remote expansion. In any case (no pun intended), IMHO it would be better to break a few of the current use cases but leave the majority functional - than kill scp for all. Regards, Uri > On Aug 3, 2020, at 02:50, Jakub Jelen <jjelen at redhat.com> wrote: > > ?On Sat, 2020-08-01 at 00:17 +0000, Blumenthal, Uri - 0553

On Tue, 2 Dec 2014, H. Peter Anvin wrote: > This is the default unless the "quiet" option is set. Hmm. tglaser at luna:/srv/tftp $ fgrep -ri quiet . Binary file ./hdt.c32 matches Binary file ./ldlinux.c32 matches Binary file ./vmlinuz matches Binary file ./linux.c32 matches Binary file ./debian-installer/jessie/amd64/linux matches Binary file ./debian-installer/jessie/i386/linux

On Mon, 27 Feb 2023, Nico Kadel-Garcia wrote: >> > does any one of you have a best practice on renewing ssh host keys on cloned >> > machines? >> >> Yes: not cloning machines. > >Good luck with *that*. Building VM's from media is a far, far too >lengthy process for production deployment, especially for auto-scaling >clusters. (It?s ?VMs?, no genitive

On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: > ssh(1) currently affords an argument-passing functionality, but as the manpage > states, all arguments are simply concatenated by space. How else would it do that? The arguments are processed by the shell first then passed as an array of NUL-terminated strings. > The modest proposal is that we put a giant CAVEATS section in the

On Sat, May 27, 2023 at 02:45:34AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote: > On Sat, 27 May 2023, raf wrote: > > >So, perhaps this could be added to the existing > >sentence/paragraph: > > > > "so any spaces in individual arguments must be > > Must they? No, a single space will do just fine. They do if you want the receiving shell

On Sat, 27 May 2023, raf wrote: >So, perhaps this could be added to the existing >sentence/paragraph: > > "so any spaces in individual arguments must be Must they? No, a single space will do just fine. > quoted using the syntax of the destination > user's login shell". ? keeping in mind the source shell?s quoting as well. >If an example were needed,

On Sat, May 27, 2023 at 12:08:43AM +0200, Thorsten Glaser <t.glaser at tarent.de> wrote: > On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: > > > ssh(1) currently affords an argument-passing functionality, but as the manpage > > states, all arguments are simply concatenated by space. > > How else would it do that? The arguments are processed by the > shell

On Wed, 29 Mar 2023, Thorsten Glaser wrote: > Hi Damien, > > >This is what I'm playing with at the moment: > > if you?re playing with this currently anyway, shouldn?t? > > >+ /* > >+ * Otherwise, use the RFC4344 s3.2 recommendation of 2**(L/4) blocks > >+ * before rekeying where L is the blocksize in bits. > >+ * Most other ciphers have a 128

On 27/05/2023 01:45, Thorsten Glaser wrote: >> ssh user at host "ls -l a\ b" > This one, incidentally, sends 'ls -l a b' to the remote shell. > ssh user at host "ls -l a\\ b" > has the effect you want; the first backslash is eaten by the > local shell. > Or is it? $ echo "ls -l a\ b" ls -l a\ b $ This is with bash 5.2.15. From the

Damien Miller wrote: > On Thu, 3 Aug 2023, Chris Rapier wrote: > >> Howdy all, >> >> So, one night over beers I was telling a friend how you could use the timing >> between key presses on a type writer to extract information. Basically, you >> make some assumptions about the person typing (touch typing at so many words >> per second and then fuzzing the

Hi, ssh(1) currently affords an argument-passing functionality, but as the manpage states, all arguments are simply concatenated by space. This behavior is non-obvious for those reading only the synopsis: one would expect something that takes argv input to somehow preserve the argument boundary and not, say, let a semicolon ruin all the fun. This is probably old news for all of you. I have

On 9/4/23 16:43, Joseph S. Testa II wrote: > I very often see IT personnel and developers simply use the default > options for ssh-keygen. They just don't care/don't know to care. > Switching the default to ED25519 would bring the equivalent security > up from 112-bits to 128-bits (as 2048-bit RSA is equivalent to 112-bits > of symmetric strength), which would be a nice

On 27.05.23 00:08, Thorsten Glaser wrote: > On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: >> The less modest one is we throw out the "[argument ...]" part altogether. It > > Absolutely not. This will break about all uses of ssh in existence. You are confusing "ssh(1) does (not) distinguish between 'command' and 'argument(s)'" with

Hi, I still have the question: when I have an environment that uses vesamenu, for example on PXE, how do I configure it so that, for some of the menu entries, it switches back to the text mode (03h) before handing off to the next bootloader / kernel? Thanks, //mirabilos -- tarent solutions GmbH Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/ Tel: +49 228 54881-393 ? Fax: +49 228

On Wed, 21 Jan 2015, Andreas Gruenbacher wrote: > Not really. As a security requirement, if this even really is anyone's > security requirement, this is pointless -- the ErrCode is set to 0 ("Not Still, requirements like this d?o? exist in the real world, dismissing them is a, I quote, stupid idea. I?d suggest to please wake up. bye, //mirabilos (not speaking for his employer