Re: seeding dev/random in 5.5
--- fwaggle <[EMAIL PROTECTED]> wrote: > i have a question. perhaps i'm misunderstanding something with how SSH > works, but how would having a "standard freebsd private key" benefit > anyone? if you wanted to impersonate a newly installed freebsd machine, > then all you'd need is that freely-available private key. plus you'd get > a bunch of clueless admins who had their machines installed by a > dedicated server provider, and who'd never change their host key, which > would effectively ruin SSH for their purposes. > Hmm... I was refering to the special problem of the beginner of this thread... As far as I understood him, he creates very special CDs, that are copied to the to-be-updated-box, that is buried very deeply in a computing centre. Those CDs may contain his special install-host-key without the problems u describe... > unless i've seriously missed the boat somewhere (it's happened before!) > i think a better solution would still be random key generation with a > nice little option to email the key signature somewhere that the new > admin could pick it up. it's still fraught with impersonation danger for > the paranoid, but imo it's a better idea than having a not-so-private > key on install. > Hmm... But then he would have the problem with a more complicated operation procedure, which has to be translated into hollandish-language (which is astonishingly quite similar to Africaans)... -Arne __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
--- Brooks Davis <[EMAIL PROTECTED]> wrote: > On Wed, Aug 09, 2006 at 12:17:35AM -0700, R. B. Riddick wrote: > These are valid if probably overly paranoid points. :) > Hmm... Oki Doke... But why use ssh, if u do not really care, if u connect to the right host? Maybe the postmen know telecom-men? ;-) > > * But what if the postman (see first point) know already the host-key from > > reading the CD? Then he could log in to ur boxes... > > This isn't true. The host key lets you impersonate the host. It > does not do anything related to log in (unless you use host based > auth). > Ooch! I wrote something wrong. :-) Most likely I meant: If the postman knows the secret part of the host-key, his host could still pretend to be the real host... -Arne __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
On Wed, Aug 09, 2006 at 09:29:44AM -0400, fwaggle wrote: > Brooks Davis wrote: > >On Wed, Aug 09, 2006 at 12:17:35AM -0700, R. B. Riddick wrote: > >>--- Doug Barton <[EMAIL PROTECTED]> wrote: > [snip] > >>* I received a private communication yesterday about this matter. But the > >>list > >>did not. I will cite (not litterally) a little bit out of that message: > >>Since > >>you do not know anything about the remotely created host-key, u cannot > >>connect > >>safely to the freshly installed box, because: You do not even know the > >>signature of the new host-key, so that if u connect to the wrong box u > >>would > >>not even known. Workaround: You could give all hosts the same well-known > >>host-key (via your install-image-CD) and then u could change the host-key > >>in a > >>remotely controlled way individually and note down the signature? Maybe my > >>secret informer (lets call him Rasmus or RK) wants to come public... :-) > > > >These are valid if probably overly paranoid points. :) > [/snip] > > i have a question. perhaps i'm misunderstanding something with how SSH > works, but how would having a "standard freebsd private key" benefit > anyone? if you wanted to impersonate a newly installed freebsd machine, > then all you'd need is that freely-available private key. plus you'd get > a bunch of clueless admins who had their machines installed by a > dedicated server provider, and who'd never change their host key, which > would effectively ruin SSH for their purposes. > > unless i've seriously missed the boat somewhere (it's happened before!) > i think a better solution would still be random key generation with a > nice little option to email the key signature somewhere that the new > admin could pick it up. it's still fraught with impersonation danger for > the paranoid, but imo it's a better idea than having a not-so-private > key on install. I interpreted the suggestion is something to be done via custom install media. There's no chance in hell the freebsd project would install a default key since it's such an obviously bad idea. -- Brooks pgp3xI6AdnxkQ.pgp Description: PGP signature
Re: seeding dev/random in 5.5
Brooks Davis wrote: On Wed, Aug 09, 2006 at 12:17:35AM -0700, R. B. Riddick wrote: --- Doug Barton <[EMAIL PROTECTED]> wrote: [snip] * I received a private communication yesterday about this matter. But the list did not. I will cite (not litterally) a little bit out of that message: Since you do not know anything about the remotely created host-key, u cannot connect safely to the freshly installed box, because: You do not even know the signature of the new host-key, so that if u connect to the wrong box u would not even known. Workaround: You could give all hosts the same well-known host-key (via your install-image-CD) and then u could change the host-key in a remotely controlled way individually and note down the signature? Maybe my secret informer (lets call him Rasmus or RK) wants to come public... :-) These are valid if probably overly paranoid points. :) [/snip] i have a question. perhaps i'm misunderstanding something with how SSH works, but how would having a "standard freebsd private key" benefit anyone? if you wanted to impersonate a newly installed freebsd machine, then all you'd need is that freely-available private key. plus you'd get a bunch of clueless admins who had their machines installed by a dedicated server provider, and who'd never change their host key, which would effectively ruin SSH for their purposes. unless i've seriously missed the boat somewhere (it's happened before!) i think a better solution would still be random key generation with a nice little option to email the key signature somewhere that the new admin could pick it up. it's still fraught with impersonation danger for the paranoid, but imo it's a better idea than having a not-so-private key on install. -- fwaggle ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
On Wed, Aug 09, 2006 at 12:17:35AM -0700, R. B. Riddick wrote: > --- Doug Barton <[EMAIL PROTECTED]> wrote: > > The patches you sent to implement this option didn't come through to the > > mailing list, could you resend them please? :) > > > > Seriously though, a lot of people looked at this problem when yarrow was > > introduced, and no solution became immediately apparent. So, if someone > > wants to take a crack at implementing something, knock yourself out. > > > Since this is the security mailing list, I would like to direct the attention > on the following points: > > * I see in the CD-procedure the problem, that a postman, who is more > sophisticated than in Leslie Nielsen's "Naked Gun 33 1/3" movie, might > exchange > the media, so that u let ur Netherlandish install something u dont know and/or > like. Workaround: Do you use a checksum over the media (`md5 < /dev/acd0`) and > transmit those checksum on a different way (maybe email)? > > * I received a private communication yesterday about this matter. But the list > did not. I will cite (not litterally) a little bit out of that message: Since > you do not know anything about the remotely created host-key, u cannot connect > safely to the freshly installed box, because: You do not even know the > signature of the new host-key, so that if u connect to the wrong box u would > not even known. Workaround: You could give all hosts the same well-known > host-key (via your install-image-CD) and then u could change the host-key in a > remotely controlled way individually and note down the signature? Maybe my > secret informer (lets call him Rasmus or RK) wants to come public... :-) These are valid if probably overly paranoid points. :) > * But what if the postman (see first point) know already the host-key from > reading the CD? Then he could log in to ur boxes... This isn't true. The host key lets you impersonate the host. It does not do anything related to log in (unless you use host based auth). -- Brooks pgpZQ6Hj9Rr6C.pgp Description: PGP signature
Re: seeding dev/random in 5.5
--- Doug Barton <[EMAIL PROTECTED]> wrote: > The patches you sent to implement this option didn't come through to the > mailing list, could you resend them please? :) > > Seriously though, a lot of people looked at this problem when yarrow was > introduced, and no solution became immediately apparent. So, if someone > wants to take a crack at implementing something, knock yourself out. > Since this is the security mailing list, I would like to direct the attention on the following points: * I see in the CD-procedure the problem, that a postman, who is more sophisticated than in Leslie Nielsen's "Naked Gun 33 1/3" movie, might exchange the media, so that u let ur Netherlandish install something u dont know and/or like. Workaround: Do you use a checksum over the media (`md5 < /dev/acd0`) and transmit those checksum on a different way (maybe email)? * I received a private communication yesterday about this matter. But the list did not. I will cite (not litterally) a little bit out of that message: Since you do not know anything about the remotely created host-key, u cannot connect safely to the freshly installed box, because: You do not even know the signature of the new host-key, so that if u connect to the wrong box u would not even known. Workaround: You could give all hosts the same well-known host-key (via your install-image-CD) and then u could change the host-key in a remotely controlled way individually and note down the signature? Maybe my secret informer (lets call him Rasmus or RK) wants to come public... :-) * But what if the postman (see first point) know already the host-key from reading the CD? Then he could log in to ur boxes... -Arne __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
Kevin Day wrote: > Maybe sysinstall could be collecting entropy during the installation and > use that for an initial seed if the timeout happens? It wouldn't be > perfect, but it'd be better than killing ssh. The patches you sent to implement this option didn't come through to the mailing list, could you resend them please? :) Seriously though, a lot of people looked at this problem when yarrow was introduced, and no solution became immediately apparent. So, if someone wants to take a crack at implementing something, knock yourself out. Doug -- This .signature sanitized for your protection ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: seeding dev/random in 5.5
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Day > Sent: Tuesday, August 08, 2006 4:59 PM > To: Doug Barton > Cc: freebsd-security@freebsd.org > Subject: Re: seeding dev/random in 5.5 > Yes, the install I had to do in amsterdam, translating dutch to english and back is the one I was concerned abot. > > Maybe sysinstall could be collecting entropy during the installation > and use that for an initial seed if the timeout happens? It wouldn't > be perfect, but it'd be better than killing ssh. > Or use my idea of collecting 5 to 10 packets using tcpdump! ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
On Aug 8, 2006, at 12:34 PM, Doug Barton wrote: (if doing this from an unattended bootup, expecting the 300 second timeout, I find that sshd does not start!) I cannot imagine a scenario where a competent system administrator would do a clean install on a machine, reboot it, and then just walk away without first testing to see that all expected services (especially sshd) were working according to plan. If you can envision such a situation, please describe it in more detail. This actually bit us too once. We were doing an unattended diskless (PXE boot) install to 50 servers at a time. These systems were for internal use only, we didn't care at all that the key generation for sshd was done in any secure way, but it meant that we either had to manually go through each server and kickstart the random number generator so sshd would work or hack the rc scripts to do what we really wanted. We got the unattended install down to do exactly what we wanted, so there was no need really to do anything locally on each server after the install. Except this. :) This came up a second time when we had a server on another continent lose its boot drive and we needed some "remote hands" to reinstall the OS for us. We shipped a replacement drive and an install CD configured to do an unattended/automated install. The idea was to give them a replacement hot-swap drive, and a bootable CD that did an automated install. After it was done, all they had to do was remove the CD and power cycle the server. (The people on the other end weren't very technical, so we had to make this extremely easy.) They followed the instructions, and from what we could tell by having them read the text on the screen it looked like it worked. We could ping the server, but not ssh, even though we were certain we had enabled sshd in the install.cfg file. We burned another copy of the CD image and tried it on a system locally to troubleshoot. Except, that since we were watching it, we didn't let the 300 second timeout happen because we were impatient, so it worked for us. It was only after many many hours of debugging that we realized that letting the timeout happen was breaking sshd. So, there are a few reasons for wanting to be able to do an install that just works right off the bat after sysinstall that don't conflict with good sysadmin practices. Maybe sysinstall could be collecting entropy during the installation and use that for an initial seed if the timeout happens? It wouldn't be perfect, but it'd be better than killing ssh. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
Please note that in spite of my @freebsd.org address, I do not purport to
speak for the project here. That said, this isn't really a security@ issue,
it's more of a freebsd-stable@ issue, for future reference. And FYI, I'm
also combining two of your posts so that hopefully we can put this issue to
rest.
Michael Scheidell wrote:
> I was doing some regression testing in 5.5:
Not sure what your purpose is here. The 5.x branch is likely to die with
5.5, so if you're looking for a branch for your enterprise to use going
forward, you're better off testing in 6.x. If you have other intentions for
doing this testing, it would be useful to know them so that we can better
answer your questions.
> Specifically testing booting up a 'virgin' hard disk from a clean install.
>
> I was testing what happened if the 300 second timeout happened vs
> hitting for 'fast+insecure' startup and punching in a bunch of
> random garbage.
>
> I found that for some reason, on a 2.4Ghz Celeron, the 'sysctl -a' and
> 'date' seeding for 'fast+insecure' seemed to do nothing unless I typed
> in at least 3 lines of random keystrokes.
That's more or less the expected behavior.
> ie: /etc/rc.d/sshd start WONT, it doesn't generate ssh keys in /etc/ssh
> and ssh won't start.
Also expected.
> Is there something in /dev/random that won't init if it isn't random enough?
Yes. When the Yarrow PRNG was introduced back in the 5-CURRENT days, there
were extensive references posted to the design docs. You might want to read
the random(4) man page as well.
> (if doing this from an unattended bootup, expecting the 300 second
> timeout, I find that sshd does not start!)
I cannot imagine a scenario where a competent system administrator would do
a clean install on a machine, reboot it, and then just walk away without
first testing to see that all expected services (especially sshd) were
working according to plan. If you can envision such a situation, please
describe it in more detail.
> In a remote location, with no head, no monitor, its hard trying to
> figure out just WHY 'system won't boot'.
> (it booted, but sshd didn't start!)
This is what serial consoles and KVMs are for.
> it might feed it LATER, saving to /var/db/entropy,
I _think_ you understand how this works, but just to be clear, the "random"
data in /var/db/entropy is output from /dev/random after it has already been
seeded. This stuff is then fed back into /dev/random at boot time in order
to speed up the process of initializing the PRNG.
> Not sure why the reluctance to even acknowledge that there could be a
> minor fix/patch that could prevent dead box and a ${miles=hundreds) trek
> to bring it back.
I don't think anyone is saying "there cannot be a problem," I think that
we're waiting for you to describe what FreeBSD problem you'd like us to fix,
and/or what fix you're proposing. The confusion is understandable if you did
not previously know how things were supposed to work, but hopefully this
post clears that up for you.
> Only two workarounds that I know of:
> #1, put in more than 3 lines of garbage on console.
That works, and is in fact (as you surmised) the intended workaround to the
problem you describe. Why is this not sufficient for you?
> #2, put in more than 5 packets of garbage from ethernet
> (which, acknowledged: if hacker is trying to seed known data to this
> box, he could feed it known data)
Well, the bits of entropy gathered from the system are not fed directly into
the PRNG, they are massaged a bit first. So it would not be quite that easy
for an attacker to manipulate things. You might want to read up on how
Yarrow works.
hope this helps,
Doug
--
This .signature sanitized for your protection
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
--- Michael Scheidell <[EMAIL PROTECTED]> wrote: > This would affect the generic stock 5.5 install disk as well (it doesn't > create new keys when it builds a virgin hard disk) > If a user just hits return, there is no error message, no indication > that /dev/random wasn't seeded. > > We have a bootable CD rom, has a generic boot/network/vpn/ and dumpfiles > for virgin install. > cd rom uses restore to make new HD. > Id rather like to have different keys on different boxes. ssh client > complains when it sees the same keys for several different ip addresses. > Oh. I see... So u just copy a CD to ur HD without any further install scripts... I do it different on my remote boxes: 1. I log in to the systems via sshd of the old system 2. Then I turn of one half of the mirror of the root file system 3. Then I un-tar the new base system to that currently unused disk. 4. Then I use bsdlabel and fdisk to make the box boot from the new disk... 5. Then I would create the ssh-host-keys... 6. Then I setup certain files/services like pf, ipfw, user-accounts, passwords, interfaces, ... 7. Then I would reboot to the freshly installed system (which does not work on some boxes sometimes, because the BIOS is quite old and does not understand the boot0cfg settings (-s5 and such)... *sigh*)... ... Your procedure seems to need operator interaction at the box itself anyway... So I do not see ur problem... Is it that just pressing [ENTER] (in spite of the warning) is not enough in ur case (in contradiction to the instructions)? That would be merely a documentation problem but not a security problem... -Arne __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
R. B. Riddick wrote: > --- Michael Scheidell <[EMAIL PROTECTED]> wrote: > >> R. B. Riddick wrote: >> >>> Why do u believe, that /dev/random isnt seeded by networking? >>> >>> >>> >> because it isn't. >> and pings arn' going to produce much random data. >> >> > Hmm... Interesting... > > >> it might feed it LATER, saving to /var/db/entropy, but when the system >> is booted, and there are no keys in /etc/ssh and rc.d/sshd tried to >> generate enough to feed to /dev/random, it doesn't >> >> > Hopefully... I was under the impression, that new "random" events are gathered > continuously in order to create an always good source of random ... > > yes, maybe, AFTER it boots, and during the day. >> I can reproduce it 100% of the time, every time, all day long. >> >> > OK... But I still dont understand why that is... Does it have an ethernet NIC? > Is that sysctl (kern.random.sys.harvest.ethernet) set to 1 before rc.d/sshd > starts? > > yes, has nic card (how else would I be able to ssh into it later ;-) no, rc.d/sshd doesn't touch that sysctl. >> Only two workarounds that I know of: >> #1, put in more than 3 lines of garbage on console. >> #2, put in more than 5 packets of garbage from ethernet >> (which, acknowledged: if hacker is trying to seed known data to this >> box, he could feed it known data) >> >> > If I may add: > I know another workaround: Create the key files during the install process, > which has to be done quite handish anyway, if u do it on a far away deeply > buried box... Or not? > > This would affect the generic stock 5.5 install disk as well (it doesn't create new keys when it builds a virgin hard disk) If a user just hits return, there is no error message, no indication that /dev/random wasn't seeded. We have a bootable CD rom, has a generic boot/network/vpn/ and dumpfiles for virgin install. cd rom uses restore to make new HD. Id rather like to have different keys on different boxes. ssh client complains when it sees the same keys for several different ip addresses. > -Arne > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
--- Michael Scheidell <[EMAIL PROTECTED]> wrote: > R. B. Riddick wrote: > > Why do u believe, that /dev/random isnt seeded by networking? > > > > > because it isn't. > and pings arn' going to produce much random data. > Hmm... Interesting... > it might feed it LATER, saving to /var/db/entropy, but when the system > is booted, and there are no keys in /etc/ssh and rc.d/sshd tried to > generate enough to feed to /dev/random, it doesn't > Hopefully... I was under the impression, that new "random" events are gathered continuously in order to create an always good source of random ... > I can reproduce it 100% of the time, every time, all day long. > OK... But I still dont understand why that is... Does it have an ethernet NIC? Is that sysctl (kern.random.sys.harvest.ethernet) set to 1 before rc.d/sshd starts? > Only two workarounds that I know of: > #1, put in more than 3 lines of garbage on console. > #2, put in more than 5 packets of garbage from ethernet > (which, acknowledged: if hacker is trying to seed known data to this > box, he could feed it known data) > If I may add: I know another workaround: Create the key files during the install process, which has to be done quite handish anyway, if u do it on a far away deeply buried box... Or not? -Arne __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
R. B. Riddick wrote:
>>
> I was under the impression, that
> kern.random.sys.harvest.ethernet
> is
> 1
> by default.
>
> That would mean, that ethernet traffic to that deeply buried box should feed
> that /dev/random until it is fat and round...
>
> Why do u believe, that /dev/random isnt seeded by networking?
>
>
because it isn't.
and pings arn' going to produce much random data.
it might feed it LATER, saving to /var/db/entropy, but when the system
is booted, and there are no keys in /etc/ssh and rc.d/sshd tried to
generate enough to feed to /dev/random, it doesn't
At least in this case, this box, this os, this chipset. Only one I have
see like this.
Its a showstopper. Box won't start remote sshd, can only get at it via
console.
Not sure why the reluctance to even acknowledge that there could be a
minor fix/patch that could prevent dead box and a ${miles=hundreds) trek
to bring it back.
if its never happened to you, then you may not have the exact
combination I have.
I can reproduce it 100% of the time, every time, all day long.
Only two workarounds that I know of:
#1, put in more than 3 lines of garbage on console.
#2, put in more than 5 packets of garbage from ethernet
(which, acknowledged: if hacker is trying to seed known data to this
box, he could feed it known data)
--
Michael Scheidell, CTO
SECNAP Network Security / www.secnap.com
[EMAIL PROTECTED] / 1+561-999-5000, x 1131
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
--- Michael Scheidell <[EMAIL PROTECTED]> wrote: > R. B. Riddick wrote: > > --- Michael Scheidell <[EMAIL PROTECTED]> wrote: > > > >>> I think that during the first reboot after a fresh install > >>> the kern.random.sys sysctl settings are already orderly > >>> before rc.d/sshd is called... > >>> > >>> If yes, then sending some pings should do the trick... Or > >>> not? I mean: NETWORKING should already be provided at that point... > >>> > >> I am not sure I understand what you are saying in the context of my > >> question. > >> > >> > > I mean: > > Instead of changing a rc.d script u or ur friend could just send some pings > to > > the deeply buried box... > > > > > why would that help? > > if (without changing rc file) /dev/random isn't seeded by networking, > why wold a ping help? > I was under the impression, that kern.random.sys.harvest.ethernet is 1 by default. That would mean, that ethernet traffic to that deeply buried box should feed that /dev/random until it is fat and round... Why do u believe, that /dev/random isnt seeded by networking? -Arne __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
R. B. Riddick wrote: > --- Michael Scheidell <[EMAIL PROTECTED]> wrote: > >>> I think that during the first reboot after a fresh install >>> the kern.random.sys sysctl settings are already orderly >>> before rc.d/sshd is called... >>> >>> If yes, then sending some pings should do the trick... Or >>> not? I mean: NETWORKING should already be provided at that point... >>> >> I am not sure I understand what you are saying in the context of my >> question. >> >> > I mean: > Instead of changing a rc.d script u or ur friend could just send some pings to > the deeply buried box... > > why would that help? if (without changing rc file) /dev/random isn't seeded by networking, why wold a ping help? -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: seeding dev/random in 5.5
--- Michael Scheidell <[EMAIL PROTECTED]> wrote: > > I think that during the first reboot after a fresh install > > the kern.random.sys sysctl settings are already orderly > > before rc.d/sshd is called... > > > > If yes, then sending some pings should do the trick... Or > > not? I mean: NETWORKING should already be provided at that point... > > I am not sure I understand what you are saying in the context of my > question. > I mean: Instead of changing a rc.d script u or ur friend could just send some pings to the deeply buried box... -Arne __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: seeding dev/random in 5.5
> -Original Message- > From: R. B. Riddick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 08, 2006 4:12 AM > To: Michael Scheidell; freebsd-security@freebsd.org > Subject: Re: seeding dev/random in 5.5 > > I think that during the first reboot after a fresh install > the kern.random.sys sysctl settings are already orderly > before rc.d/sshd is called... > > If yes, then sending some pings should do the trick... Or > not? I mean: NETWORKING should already be provided at that point... I am not sure I understand what you are saying in the context of my question. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: seeding dev/random in 5.5
--- Michael Scheidell <[EMAIL PROTECTED]> wrote:
> I was doing some regression testing in 5.5: Specifically testing booting
> up a 'virgin' hard disk from a clean install.
>
> I was testing what happened if the 300 second timeout happened vs
> hitting for 'fast+insecure' startup and punching in a bunch of
> random garbage.
>
> I found that for some reason, on a 2.4Ghz Celeron, the 'sysctl -a' and
> 'date' seeding for 'fast+insecure' seemed to do nothing unless I typed
> in at least 3 lines of random keystrokes.
>
> ie: /etc/rc.d/sshd start WONT, it doesn't generate ssh keys in /etc/ssh
> and ssh won't start.
>
> Is there something in /dev/random that won't init if it isn't random enough?
>
> (if doing this from an unattended bootup, expecting the 300 second
> timeout, I find that sshd does not start!)
>
> After doing some testing, it appears that (at least with the combination
> of a 2.4Ghz Celeron and 5.5) that it takes at least three lines of
> random data, added to the output of sysctl -a and date to seed /dev/random.
>
> (as per this in /etc/rc.d/sshd:
>read -t ${timeout} junk
> echo "${junk}" `sysctl -a` `date` > /dev/random
>
> I can find no other explanation to the results of my tests:
>
> This removes keys:
> /etc/rc.d/sshd stop
> rm /etc/ssh/*key*
> /etc/rc.d/sshd start
>
> tests:
>
> #1, allow 300 second timeout:
> remove keys, restart sshd: /etc/rc.d/sshd start
> let it sit for 300 seconds.
> No error messages, but sshd doesn't start, and there are no keys in /etc/ssh
>
> #2, one line of random test
> (same results as above)
> #3, two lines, etc
>
> #4, three lines.
> Now, I get the messages telling me that ssh_keygen has created keys, and
> there are keys in /etc/ssh
>
> I also find that by adding this to the random seeding that it will work
> with or 300 second timeout:
>
>read -t ${timeout} junk
> echo "${junk}" `sysctl -a` `date` `tcpdump -xs1500 -c
> 5` > /dev/random
>
> Yes, I know, but even ;lj;lkj;lj;ljjl on the keyboard isn't all that
> random, but my issue is not being able to remotely access a virgin
> system with ssh. Sometimes these are headless pizza boxes, buried deep
> in the bowels of some data center.
>
> Has anyone else run tests like this?
>
> (I suppose the -c value in tcpdump could be random as well '-=) using:
>
> count = `date "+%S"`
>
> In a remote location, with no head, no monitor, its hard trying to
> figure out just WHY 'system won't boot'.
> (it booted, but sshd didn't start!)
>
> There is enough random[pun intended] things that can happen when you
> install a new system, that I would like to try to eliminate one of them.
>
I think that during the first reboot after a fresh install the kern.random.sys
sysctl settings are already orderly before rc.d/sshd is called...
If yes, then sending some pings should do the trick... Or not?
I mean: NETWORKING should already be provided at that point...
Btw.:
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
