Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #12254 > unrolled thread

fedora 20 disabling ssh by default

Back to article view | Back to comp.os.linux.misc

Contents

  fedora 20 disabling ssh by default "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-09 19:23 -0400
    Re: fedora 20 disabling ssh by default Bit Twister <BitTwister@mouse-potato.com> - 2014-10-09 23:35 +0000
      Re: fedora 20 disabling ssh by default Baho Utot <baho-utot@columbus.rr.com> - 2014-10-09 20:25 -0400
        Re: fedora 20 disabling ssh by default Bit Twister <BitTwister@mouse-potato.com> - 2014-10-10 01:11 +0000
        Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-10 15:32 +0000
          Re: fedora 20 disabling ssh by default Baho Utot <baho-utot@columbus.rr.com> - 2014-10-10 17:59 -0400
      Re: fedora 20 disabling ssh by default "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-09 23:13 -0400
        Re: fedora 20 disabling ssh by default Rich <rich@example.invalid> - 2014-10-10 08:50 +0000
          Re: fedora 20 disabling ssh by default Bit Twister <BitTwister@mouse-potato.com> - 2014-10-10 09:10 +0000
            Re: fedora 20 disabling ssh by default The Natural Philosopher <tnp@invalid.invalid> - 2014-10-10 10:16 +0100
              Re: fedora 20 disabling ssh by default "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-10 20:05 -0400
                Re: fedora 20 disabling ssh by default The Natural Philosopher <tnp@invalid.invalid> - 2014-10-11 07:47 +0100
            Re: fedora 20 disabling ssh by default Rich <rich@example.invalid> - 2014-10-10 09:26 +0000
              Re: fedora 20 disabling ssh by default The Natural Philosopher <tnp@invalid.invalid> - 2014-10-10 11:00 +0100
              Re: fedora 20 disabling ssh by default Bit Twister <BitTwister@mouse-potato.com> - 2014-10-10 10:14 +0000
                Re: fedora 20 disabling ssh by default Rich <rich@example.invalid> - 2014-10-10 10:29 +0000
              Re: fedora 20 disabling ssh by default "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-10 16:27 -0400
            Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-10 15:41 +0000
              Re: fedora 20 disabling ssh by default "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-10 20:03 -0400
                Re: fedora 20 disabling ssh by default John Hasler <jhasler@newsguy.com> - 2014-10-10 20:28 -0500
                Re: fedora 20 disabling ssh by default Robert Riches <spamtrap42@jacob21819.net> - 2014-10-11 02:52 +0000
                  Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-11 17:03 +0000
                    Re: fedora 20 disabling ssh by default "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-11 14:38 -0400
                      Re: fedora 20 disabling ssh by default Wayne <nospam@all.invalid> - 2014-10-11 18:05 -0400
                        Re: fedora 20 disabling ssh by default Richard Kettlewell <rjk@greenend.org.uk> - 2014-10-11 23:18 +0100
                        Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-11 23:43 +0000
                      Re: fedora 20 disabling ssh by default Rich <rich@example.invalid> - 2014-10-11 22:34 +0000
                        Re: fedora 20 disabling ssh by default Wayne <nospam@all.invalid> - 2014-10-11 19:13 -0400
                          Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-12 00:30 +0000
                            Re: fedora 20 disabling ssh by default Wayne <nospam@all.invalid> - 2014-10-11 21:27 -0400
                              Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-12 02:14 +0000
                Re: fedora 20 disabling ssh by default Rich <rich@example.invalid> - 2014-10-11 03:59 +0000
        Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-10 15:34 +0000
    Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-10 15:31 +0000
    Re: fedora 20 disabling ssh by default Andreas Kohlbach <oct14.5.ankman@spamgourmet.com> - 2014-10-10 16:06 -0400
      Re: fedora 20 disabling ssh by default "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-10 20:00 -0400
        Re: fedora 20 disabling ssh by default William Unruh <unruh@invalid.ca> - 2014-10-11 17:02 +0000
        Re: fedora 20 disabling ssh by default Andreas Kohlbach <oct14.5.ankman@spamgourmet.com> - 2014-10-11 16:35 -0400
    Re: fedora 20 disabling ssh by default HakTar <FiteWinTel@gmail.com> - 2014-10-30 07:34 +0000

Page 2 of 2 — ← Prev page 1 [2]

#12283

On 2014-10-11, Bill Cunningham <nospam@nspam.invalid> wrote:
>
> "William Unruh" <unruh@invalid.ca> wrote in message 
> news:m18un5$la4$4@dont-email.me...
>> On 2014-10-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>> On Fri, 10 Oct 2014 08:50:32 +0000 (UTC), Rich wrote:
>>>>
>>>> That is most likely a brute force password attempt.  If you shutdown
>>>> ssh, you'll block the attempts, but also prevent yourself from logging
>>>> in via ssh.  So if you log in via ssh, you'll end up shutting yourself
>>>> out as well.
>>>
>>> Just tell your firewall what ip addresses are allowed to connect to sshd.
>>> Tell sshd that root is not allowed to use a password login.
>>> Tell sshd to listen on a different port.
>>>
>>>
>>>> However, if your password is properly random, you have little to worry
>>>> about other than extra entries in your log files.
>>>
>>> Random passwords are easier to crack. Use a funky phrase like
>>> my dog eats concrete.
>>> Feel free to sprinkle in numbers and !@#$%^&*()_+= characters.
>>
>> He did say "properly random". I am sure by properly he did not mean 4
>> random characters. A long enough password with random characters is
>> certainly better than your example which really is not terribly random.
>
>     Something generated by uuid would I think be pretty good. Or better yet 
> if you could direct something from dev/urandom as text; but I don't know if 
> you could do that.
>
> Bill

This works for me:

    head -c 16 /dev/random | base64

That gives about 24 characters, including a couple of symbols.
For website passwords, I prefer to copy-paste the password into
the browser, so take a few over a dozen alphanumeric characters
from the above command.  In theory, /dev/random could block, but
even if it does, I could just spin the trackball mouse for a few
seconds.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

[toc] | [prev] | [next] | [standalone]

#12287

On 2014-10-11, Robert Riches <spamtrap42@jacob21819.net> wrote:
> On 2014-10-11, Bill Cunningham <nospam@nspam.invalid> wrote:
>>
>> "William Unruh" <unruh@invalid.ca> wrote in message 
>> news:m18un5$la4$4@dont-email.me...
>>> On 2014-10-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>>> On Fri, 10 Oct 2014 08:50:32 +0000 (UTC), Rich wrote:
>>>>>
>>>>> That is most likely a brute force password attempt.  If you shutdown
>>>>> ssh, you'll block the attempts, but also prevent yourself from logging
>>>>> in via ssh.  So if you log in via ssh, you'll end up shutting yourself
>>>>> out as well.
>>>>
>>>> Just tell your firewall what ip addresses are allowed to connect to sshd.
>>>> Tell sshd that root is not allowed to use a password login.
>>>> Tell sshd to listen on a different port.
>>>>
>>>>
>>>>> However, if your password is properly random, you have little to worry
>>>>> about other than extra entries in your log files.
>>>>
>>>> Random passwords are easier to crack. Use a funky phrase like
>>>> my dog eats concrete.
>>>> Feel free to sprinkle in numbers and !@#$%^&*()_+= characters.
>>>
>>> He did say "properly random". I am sure by properly he did not mean 4
>>> random characters. A long enough password with random characters is
>>> certainly better than your example which really is not terribly random.
>>
>>     Something generated by uuid would I think be pretty good. Or better yet 
>> if you could direct something from dev/urandom as text; but I don't know if 
>> you could do that.
>>
>> Bill
>
> This works for me:
>
>     head -c 16 /dev/random | base64
>
> That gives about 24 characters, including a couple of symbols.
> For website passwords, I prefer to copy-paste the password into
> the browser, so take a few over a dozen alphanumeric characters
> from the above command.  In theory, /dev/random could block, but
> even if it does, I could just spin the trackball mouse for a few
> seconds.

So why do you not use /dev/urandom? Using /dev/random is silly.

>

[toc] | [prev] | [next] | [standalone]

#12288

"William Unruh" <unruh@invalid.ca> wrote in message 
news:m1bnsj$eut$2@dont-email.me...
> On 2014-10-11, Robert Riches <spamtrap42@jacob21819.net> wrote:
>> On 2014-10-11, Bill Cunningham <nospam@nspam.invalid> wrote:
>>>
>>> "William Unruh" <unruh@invalid.ca> wrote in message
>>> news:m18un5$la4$4@dont-email.me...
>>>> On 2014-10-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>>>> On Fri, 10 Oct 2014 08:50:32 +0000 (UTC), Rich wrote:
>>>>>>
>>>>>> That is most likely a brute force password attempt.  If you shutdown
>>>>>> ssh, you'll block the attempts, but also prevent yourself from 
>>>>>> logging
>>>>>> in via ssh.  So if you log in via ssh, you'll end up shutting 
>>>>>> yourself
>>>>>> out as well.
>>>>>
>>>>> Just tell your firewall what ip addresses are allowed to connect to 
>>>>> sshd.
>>>>> Tell sshd that root is not allowed to use a password login.
>>>>> Tell sshd to listen on a different port.
>>>>>
>>>>>
>>>>>> However, if your password is properly random, you have little to 
>>>>>> worry
>>>>>> about other than extra entries in your log files.
>>>>>
>>>>> Random passwords are easier to crack. Use a funky phrase like
>>>>> my dog eats concrete.
>>>>> Feel free to sprinkle in numbers and !@#$%^&*()_+= characters.
>>>>
>>>> He did say "properly random". I am sure by properly he did not mean 4
>>>> random characters. A long enough password with random characters is
>>>> certainly better than your example which really is not terribly random.
>>>
>>>     Something generated by uuid would I think be pretty good. Or better 
>>> yet
>>> if you could direct something from dev/urandom as text; but I don't know 
>>> if
>>> you could do that.
>>>
>>> Bill
>>
>> This works for me:
>>
>>     head -c 16 /dev/random | base64
>>
>> That gives about 24 characters, including a couple of symbols.
>> For website passwords, I prefer to copy-paste the password into
>> the browser, so take a few over a dozen alphanumeric characters
>> from the above command.  In theory, /dev/random could block, but
>> even if it does, I could just spin the trackball mouse for a few
>> seconds.
>
> So why do you not use /dev/urandom? Using /dev/random is silly.

    I think there would be more entropy in urandom.

Bill

[toc] | [prev] | [next] | [standalone]

#12291

On 10/11/2014 2:38 PM, Bill Cunningham wrote:
> "William Unruh" <unruh@invalid.ca> wrote in message 
>>>>     Something generated by uuid would I think be pretty good. Or better 
>>>> yet
>>>> if you could direct something from dev/urandom as text; but I don't know 
>>>> if
>>>> you could do that.
>>>>
>>>> Bill
>>>
>>> This works for me:
>>>
>>>     head -c 16 /dev/random | base64
>>>
>>> That gives about 24 characters, including a couple of symbols.
>>> For website passwords, I prefer to copy-paste the password into
>>> the browser, so take a few over a dozen alphanumeric characters
>>> from the above command.  In theory, /dev/random could block, but
>>> even if it does, I could just spin the trackball mouse for a few
>>> seconds.
>>
>> So why do you not use /dev/urandom? Using /dev/random is silly.
> 
>     I think there would be more entropy in urandom.
> 
> Bill
> 
> 

No, on Linux there is one entropy pool, which you can
view with cat /proc/sys/kernel/random/entropy_avail.
The difference between the two is that if the available
entropy falls below a threshold, /dev/random will block
and /dev/urandom won't; it simply outputs lower-quality
random numbers.

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#12292

Wayne <nospam@all.invalid> writes:
> On 10/11/2014 2:38 PM, Bill Cunningham wrote:
>> "William Unruh" <unruh@invalid.ca> wrote in message 
>>> So why do you not use /dev/urandom? Using /dev/random is silly.
>> 
>>     I think there would be more entropy in urandom.
>
> No, on Linux there is one entropy pool, which you can
> view with cat /proc/sys/kernel/random/entropy_avail.
> The difference between the two is that if the available
> entropy falls below a threshold, /dev/random will block
> and /dev/urandom won't; it simply outputs lower-quality
> random numbers.

The “quality” argument is essentially a myth.  Provided the RNG is
seeded before use (something that is really only ever in question during
system startup), /dev/urandom is perfectly adequate for cryptographic
purposes.

See http://www.2uo.de/myths-about-urandom/ for more on this point.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#12295

On 2014-10-11, Wayne <nospam@all.invalid> wrote:
> On 10/11/2014 2:38 PM, Bill Cunningham wrote:
>> "William Unruh" <unruh@invalid.ca> wrote in message 
>>>>>     Something generated by uuid would I think be pretty good. Or better 
>>>>> yet
>>>>> if you could direct something from dev/urandom as text; but I don't know 
>>>>> if
>>>>> you could do that.
>>>>>
>>>>> Bill
>>>>
>>>> This works for me:
>>>>
>>>>     head -c 16 /dev/random | base64
>>>>
>>>> That gives about 24 characters, including a couple of symbols.
>>>> For website passwords, I prefer to copy-paste the password into
>>>> the browser, so take a few over a dozen alphanumeric characters
>>>> from the above command.  In theory, /dev/random could block, but
>>>> even if it does, I could just spin the trackball mouse for a few
>>>> seconds.
>>>
>>> So why do you not use /dev/urandom? Using /dev/random is silly.
>> 
>>     I think there would be more entropy in urandom.
>> 
>> Bill
>> 
>> 
>
> No, on Linux there is one entropy pool, which you can
> view with cat /proc/sys/kernel/random/entropy_avail.

You mean, you can view the number of bytes in that pool with that
command.


If I do 
cat /dev/urandom>/tmp/u
after a few seconds I had 1/4GB of bytes in /tmp/u
and cat proc/sys/kernel/random/entropy_avail changed little. 

When I did 
cat /dev/random>/tmp/u
after a similar few seconds I had 64 bytes there, and the entropy pool
was around single digits in size the whole time. 


> The difference between the two is that if the available
> entropy falls below a threshold, /dev/random will block
> and /dev/urandom won't; it simply outputs lower-quality
> random numbers.

Well, no. "lower quality" is a pretty weird term for what it does. 
/dev/urandom is essentially a high quality prng which is continually
being reseeded with "randomness" from the various sources of randomness
that the operating system can supply. Being a prng one could call it
lower quality, or could also call it higher quality as it further
insulates the output from the biases etc that are always present in any
physical source of randomness. Noone has ever given even the faintest
clue of any "break" in the prng that is used for urandom, and the
continuous reseeding makes inverting it exceedingly difficult-- even
more difficult than the PRNG might be if it were never reseeded.

Unless you really really really know what you are doing, use urandom.



>

[toc] | [prev] | [next] | [standalone]

#12293

Bill Cunningham <nospam@nspam.invalid> wrote:

> "William Unruh" <unruh@invalid.ca> wrote in message 
> news:m1bnsj$eut$2@dont-email.me...
> > On 2014-10-11, Robert Riches <spamtrap42@jacob21819.net> wrote:
> >> On 2014-10-11, Bill Cunningham <nospam@nspam.invalid> wrote:
> >>>
> >>> "William Unruh" <unruh@invalid.ca> wrote in message
> >>> news:m18un5$la4$4@dont-email.me...
> >>>> On 2014-10-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
> >>>>> On Fri, 10 Oct 2014 08:50:32 +0000 (UTC), Rich wrote:
> >>>>>>
> >>>>>> That is most likely a brute force password attempt.  If you shutdown
> >>>>>> ssh, you'll block the attempts, but also prevent yourself from 
> >>>>>> logging
> >>>>>> in via ssh.  So if you log in via ssh, you'll end up shutting 
> >>>>>> yourself
> >>>>>> out as well.
> >>>>>
> >>>>> Just tell your firewall what ip addresses are allowed to connect to 
> >>>>> sshd.
> >>>>> Tell sshd that root is not allowed to use a password login.
> >>>>> Tell sshd to listen on a different port.
> >>>>>
> >>>>>
> >>>>>> However, if your password is properly random, you have little to 
> >>>>>> worry
> >>>>>> about other than extra entries in your log files.
> >>>>>
> >>>>> Random passwords are easier to crack. Use a funky phrase like
> >>>>> my dog eats concrete.
> >>>>> Feel free to sprinkle in numbers and !@#$%^&*()_+= characters.
> >>>>
> >>>> He did say "properly random". I am sure by properly he did not mean 4
> >>>> random characters. A long enough password with random characters is
> >>>> certainly better than your example which really is not terribly random.
> >>>
> >>>     Something generated by uuid would I think be pretty good. Or better 
> >>> yet
> >>> if you could direct something from dev/urandom as text; but I don't know 
> >>> if
> >>> you could do that.
> >>>
> >>> Bill
> >>
> >> This works for me:
> >>
> >>     head -c 16 /dev/random | base64
> >>
> >> That gives about 24 characters, including a couple of symbols.
> >> For website passwords, I prefer to copy-paste the password into
> >> the browser, so take a few over a dozen alphanumeric characters
> >> from the above command.  In theory, /dev/random could block, but
> >> even if it does, I could just spin the trackball mouse for a few
> >> seconds.
> >
> > So why do you not use /dev/urandom? Using /dev/random is silly.

>     I think there would be more entropy in urandom.

The "entropy" is the same for both.  The difference is random blocks
when the entropy drops to a low water mark, and urandom just continues
to provide randomness:

http://www.2uo.de/myths-about-urandom/

[toc] | [prev] | [next] | [standalone]

#12294

On 10/11/2014 6:34 PM, Rich wrote:
> Bill Cunningham <nospam@nspam.invalid> wrote:
> 
>> "William Unruh" <unruh@invalid.ca> wrote in message 
>> news:m1bnsj$eut$2@dont-email.me...
>>> On 2014-10-11, Robert Riches <spamtrap42@jacob21819.net> wrote:
>>>> On 2014-10-11, Bill Cunningham <nospam@nspam.invalid> wrote:
>>>>>
>>>>> "William Unruh" <unruh@invalid.ca> wrote in message
>>>>> news:m18un5$la4$4@dont-email.me...
>>>>>> On 2014-10-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>>>>>> On Fri, 10 Oct 2014 08:50:32 +0000 (UTC), Rich wrote:
>>>>>>>>
>>>>>>>> That is most likely a brute force password attempt.  If you shutdown
>>>>>>>> ssh, you'll block the attempts, but also prevent yourself from 
>>>>>>>> logging
>>>>>>>> in via ssh.  So if you log in via ssh, you'll end up shutting 
>>>>>>>> yourself
>>>>>>>> out as well.
>>>>>>>
>>>>>>> Just tell your firewall what ip addresses are allowed to connect to 
>>>>>>> sshd.
>>>>>>> Tell sshd that root is not allowed to use a password login.
>>>>>>> Tell sshd to listen on a different port.
>>>>>>>
>>>>>>>
>>>>>>>> However, if your password is properly random, you have little to 
>>>>>>>> worry
>>>>>>>> about other than extra entries in your log files.
>>>>>>>
>>>>>>> Random passwords are easier to crack. Use a funky phrase like
>>>>>>> my dog eats concrete.
>>>>>>> Feel free to sprinkle in numbers and !@#$%^&*()_+= characters.
>>>>>>
>>>>>> He did say "properly random". I am sure by properly he did not mean 4
>>>>>> random characters. A long enough password with random characters is
>>>>>> certainly better than your example which really is not terribly random.
>>>>>
>>>>>     Something generated by uuid would I think be pretty good. Or better 
>>>>> yet
>>>>> if you could direct something from dev/urandom as text; but I don't know 
>>>>> if
>>>>> you could do that.
>>>>>
>>>>> Bill
>>>>
>>>> This works for me:
>>>>
>>>>     head -c 16 /dev/random | base64
>>>>
>>>> That gives about 24 characters, including a couple of symbols.
>>>> For website passwords, I prefer to copy-paste the password into
>>>> the browser, so take a few over a dozen alphanumeric characters
>>>> from the above command.  In theory, /dev/random could block, but
>>>> even if it does, I could just spin the trackball mouse for a few
>>>> seconds.
>>>
>>> So why do you not use /dev/urandom? Using /dev/random is silly.
> 
>>     I think there would be more entropy in urandom.
> 
> The "entropy" is the same for both.  The difference is random blocks
> when the entropy drops to a low water mark, and urandom just continues
> to provide randomness:
> 
> http://www.2uo.de/myths-about-urandom/

Everything to do with random numbers and security is more
complicated than it seems.  I took a look at that page, but
it looks wrong to me.  Try this one instead:

<http://eprint.iacr.org/2012/251.pdf>

The idea is /dev/random is for small amounts of high quality
random numbers, such as when using them as seed values for
PRNGs.  The analysis clearly states that /dev/urandom, when
when the entropy is exhausted, results in theoretically
easier to guess random numbers, but you're right in that
/dev/urandom was designed to provide lots of high-quality
random bytes.  Thus for most uses, one should prefer that.

As a practical matter, modern hardware (the last couple of
generations of Intel, for example) include a hardware random
number generator.  While the Linux maintainers don't trust
it sufficiently to expose it as /dev/hw_random, it is used
as an entropy source.  The practical result is, it is almost
impossible to block using /dev/random (I've tried on a new
Dell running Fedora 20 to make it block, but couldn't.)
So in the end, it is probably moot which one you use any
more.

(I read the details of an interesting attack, where the
attacker read from /dev/random continuously, and measured
the time between outputs.  On older hardware running virtual
machines, the main source of random noise is keystroke
timings.  The attacker was able to determine what another
user was typing using this method!)

An aside:  pwgen uses /dev/urandom, while apg uses /dev/random.
So try this simple experiment:
 while :; do apg; done
to see if your system will ever block reading from /dev/random.

For generating 10+ random characters for use as a password,
probably /dev/urandom is the technically correct choice.

Note that some studies suggest that passphrases are harder
to crack than passwords: you generate 5+ randomly selected
English words, and string them together with randomly
selected symbols.  While too small to be very secure, you
could select the words using the standard dictd word
list:

 shuf /usr/share/dict/words | head -n 8

(Generating seven random symbols to use to separate the
eight words is left as an exercise to the reader.)

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#12296

On 2014-10-11, Wayne <nospam@all.invalid> wrote:
> On 10/11/2014 6:34 PM, Rich wrote:
>> Bill Cunningham <nospam@nspam.invalid> wrote:
>> 
>>> "William Unruh" <unruh@invalid.ca> wrote in message 
>>> news:m1bnsj$eut$2@dont-email.me...
>>>> On 2014-10-11, Robert Riches <spamtrap42@jacob21819.net> wrote:
>>>>> On 2014-10-11, Bill Cunningham <nospam@nspam.invalid> wrote:
>>>>>>
>>>>>> "William Unruh" <unruh@invalid.ca> wrote in message
>>>>>> news:m18un5$la4$4@dont-email.me...
>>>>>>> On 2014-10-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>>>>>>> On Fri, 10 Oct 2014 08:50:32 +0000 (UTC), Rich wrote:
>>>>>>>>>
>>>>>>>>> That is most likely a brute force password attempt.  If you shutdown
>>>>>>>>> ssh, you'll block the attempts, but also prevent yourself from 
>>>>>>>>> logging
>>>>>>>>> in via ssh.  So if you log in via ssh, you'll end up shutting 
>>>>>>>>> yourself
>>>>>>>>> out as well.
>>>>>>>>
>>>>>>>> Just tell your firewall what ip addresses are allowed to connect to 
>>>>>>>> sshd.
>>>>>>>> Tell sshd that root is not allowed to use a password login.
>>>>>>>> Tell sshd to listen on a different port.
>>>>>>>>
>>>>>>>>
>>>>>>>>> However, if your password is properly random, you have little to 
>>>>>>>>> worry
>>>>>>>>> about other than extra entries in your log files.
>>>>>>>>
>>>>>>>> Random passwords are easier to crack. Use a funky phrase like
>>>>>>>> my dog eats concrete.
>>>>>>>> Feel free to sprinkle in numbers and !@#$%^&*()_+= characters.
>>>>>>>
>>>>>>> He did say "properly random". I am sure by properly he did not mean 4
>>>>>>> random characters. A long enough password with random characters is
>>>>>>> certainly better than your example which really is not terribly random.
>>>>>>
>>>>>>     Something generated by uuid would I think be pretty good. Or better 
>>>>>> yet
>>>>>> if you could direct something from dev/urandom as text; but I don't know 
>>>>>> if
>>>>>> you could do that.
>>>>>>
>>>>>> Bill
>>>>>
>>>>> This works for me:
>>>>>
>>>>>     head -c 16 /dev/random | base64
>>>>>
>>>>> That gives about 24 characters, including a couple of symbols.
>>>>> For website passwords, I prefer to copy-paste the password into
>>>>> the browser, so take a few over a dozen alphanumeric characters
>>>>> from the above command.  In theory, /dev/random could block, but
>>>>> even if it does, I could just spin the trackball mouse for a few
>>>>> seconds.
>>>>
>>>> So why do you not use /dev/urandom? Using /dev/random is silly.
>> 
>>>     I think there would be more entropy in urandom.
>> 
>> The "entropy" is the same for both.  The difference is random blocks
>> when the entropy drops to a low water mark, and urandom just continues
>> to provide randomness:
>> 
>> http://www.2uo.de/myths-about-urandom/
>
> Everything to do with random numbers and security is more
> complicated than it seems.  I took a look at that page, but
> it looks wrong to me.  Try this one instead:

It looks wrong to you? Exactly who are "you" that your impressions
should be listened to? And why does it "look wrong"


>
><http://eprint.iacr.org/2012/251.pdf>
>
> The idea is /dev/random is for small amounts of high quality

IF you are going to need it for such "high qulaity" ( what does that
mean-- it taes 10^500 ages of the universe to break rather than 10^499?)
then do not use /dev/random OR /dev/urandom. Both are bad. As as stated,
/dev/random is far worse.

> random numbers, such as when using them as seed values for
> PRNGs.  The analysis clearly states that /dev/urandom, when
> when the entropy is exhausted, results in theoretically
> easier to guess random numbers, but you're right in that
> /dev/urandom was designed to provide lots of high-quality
> random bytes.  Thus for most uses, one should prefer that.
>
> As a practical matter, modern hardware (the last couple of
> generations of Intel, for example) include a hardware random

As pointed out, my /dev/random certainly blocks. After 10 sec I got all
of 64 bytes our of it, while /dev/urandom gave 1/4 GB. 
My kernel is 3.10.48. My processor is
processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
stepping        : 10
microcode       : 0xa0b
cpu MHz         : 1596.000
cache size      : 3072 KB


I believe that they already had the onboard rng. And writing any program
so it will block on commonly used equipment is simply irresponsible. 

And note that you said that the intel cpu random number generator is not
trusted, but ALL of your randomness in your non-blocking /dev/random is
coming from that source. Ie, its randomness is no better than the
randomness of that source, even if the randomness estimater in the
kernel might estimate more. For example if the on board generator simply
does a 10 bit hash on consecutive integers, the randomness is zero, but
the linux estimator would say that is far far more than that. 

It is simply stupid to use /dev/random


> number generator.  While the Linux maintainers don't trust
> it sufficiently to expose it as /dev/hw_random, it is used
> as an entropy source.  The practical result is, it is almost
> impossible to block using /dev/random (I've tried on a new
> Dell running Fedora 20 to make it block, but couldn't.)
> So in the end, it is probably moot which one you use any
> more.

If you do not trust /dev/urandom on the intel generator,
you sure should not trust /dev/random either. 

>
> (I read the details of an interesting attack, where the
> attacker read from /dev/random continuously, and measured
> the time between outputs.  On older hardware running virtual
> machines, the main source of random noise is keystroke
> timings.  The attacker was able to determine what another
> user was typing using this method!)

And you are advocating /dev/random? Sheesh.

>
> An aside:  pwgen uses /dev/urandom, while apg uses /dev/random.

And if it does it is simply irresponsible. 
And it uses an internal PRNG which is undoubtedly much worse than the
one used by /dev/urandom, to generate the output from a seed supplied by
/dev/random. This is to put it mildly, insane. 


> So try this simple experiment:
>  while :; do apg; done
> to see if your system will ever block reading from /dev/random.
>
> For generating 10+ random characters for use as a password,
> probably /dev/urandom is the technically correct choice.

weasle word-- probably. Could you pls give us an estimate as to how much
the use of /dev/urandom would decrease the search time for that password
over /dev/random?

>
> Note that some studies suggest that passphrases are harder
> to crack than passwords: you generate 5+ randomly selected
> English words, and string them together with randomly
> selected symbols.  While too small to be very secure, you
> could select the words using the standard dictd word
> list:
>
>  shuf /usr/share/dict/words | head -n 8
>
> (Generating seven random symbols to use to separate the
> eight words is left as an exercise to the reader.)
>

[toc] | [prev] | [next] | [standalone]

#12297

On 10/11/2014 8:30 PM, William Unruh wrote:
> On 2014-10-11, Wayne <nospam@all.invalid> wrote:
>> On 10/11/2014 6:34 PM, Rich wrote:
>>> Bill Cunningham <nospam@nspam.invalid> wrote:
>>>
>>>> "William Unruh" <unruh@invalid.ca> wrote in message 
>>>> news:m1bnsj$eut$2@dont-email.me...
>>>>> On 2014-10-11, Robert Riches <spamtrap42@jacob21819.net> wrote:
>>>>>> On 2014-10-11, Bill Cunningham <nospam@nspam.invalid> wrote:
>>>>>>>
>>>>>>> "William Unruh" <unruh@invalid.ca> wrote in message
>>>>>>> news:m18un5$la4$4@dont-email.me...
>>>>>>>> On 2014-10-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
>>>>>>>>> On Fri, 10 Oct 2014 08:50:32 +0000 (UTC), Rich wrote:
>>>>>>>>>>
>>>>>>>>>> That is most likely a brute force password attempt.  If you shutdown
>>>>>>>>>> ssh, you'll block the attempts, but also prevent yourself from 
>>>>>>>>>> logging
>>>>>>>>>> in via ssh.  So if you log in via ssh, you'll end up shutting 
>>>>>>>>>> yourself
>>>>>>>>>> out as well.
>>>>>>>>>
>>>>>>>>> Just tell your firewall what ip addresses are allowed to connect to 
>>>>>>>>> sshd.
>>>>>>>>> Tell sshd that root is not allowed to use a password login.
>>>>>>>>> Tell sshd to listen on a different port.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> However, if your password is properly random, you have little to 
>>>>>>>>>> worry
>>>>>>>>>> about other than extra entries in your log files.
>>>>>>>>>
>>>>>>>>> Random passwords are easier to crack. Use a funky phrase like
>>>>>>>>> my dog eats concrete.
>>>>>>>>> Feel free to sprinkle in numbers and !@#$%^&*()_+= characters.
>>>>>>>>
>>>>>>>> He did say "properly random". I am sure by properly he did not mean 4
>>>>>>>> random characters. A long enough password with random characters is
>>>>>>>> certainly better than your example which really is not terribly random.
>>>>>>>
>>>>>>>     Something generated by uuid would I think be pretty good. Or better 
>>>>>>> yet
>>>>>>> if you could direct something from dev/urandom as text; but I don't know 
>>>>>>> if
>>>>>>> you could do that.
>>>>>>>
>>>>>>> Bill
>>>>>>
>>>>>> This works for me:
>>>>>>
>>>>>>     head -c 16 /dev/random | base64
>>>>>>
>>>>>> That gives about 24 characters, including a couple of symbols.
>>>>>> For website passwords, I prefer to copy-paste the password into
>>>>>> the browser, so take a few over a dozen alphanumeric characters
>>>>>> from the above command.  In theory, /dev/random could block, but
>>>>>> even if it does, I could just spin the trackball mouse for a few
>>>>>> seconds.
>>>>>
>>>>> So why do you not use /dev/urandom? Using /dev/random is silly.
>>>
>>>>     I think there would be more entropy in urandom.
>>>
>>> The "entropy" is the same for both.  The difference is random blocks
>>> when the entropy drops to a low water mark, and urandom just continues
>>> to provide randomness:
>>>
>>> http://www.2uo.de/myths-about-urandom/
>>
>> Everything to do with random numbers and security is more
>> complicated than it seems.  I took a look at that page, but
>> it looks wrong to me.  Try this one instead:
> 
> It looks wrong to you? Exactly who are "you" that your impressions
> should be listened to? And why does it "look wrong"
> 

I'm nobody.  I am neither a mathematician nor a security
expert.  If you don't agree with me, and you have some
knowledge of your own, you would be wise not to listen
to my opinions.

It looks wrong because I know there are two entropy pools in
the kernel, and the picture drawn, admittedly a simplification,
shows only one.  I prefer to trust what I've read from the
detailed analysis I showed you, and comments from Ted T'so's
blog.

> 
>>
>> <http://eprint.iacr.org/2012/251.pdf>
>>
>> The idea is /dev/random is for small amounts of high quality
> 
> IF you are going to need it for such "high qulaity" ( what does that
> mean-- it taes 10^500 ages of the universe to break rather than 10^499?)
> then do not use /dev/random OR /dev/urandom. Both are bad. As as stated,
> /dev/random is far worse.

On Liunux systems without a trusted hardware random number generator,
you can't do better than using /dev/random.  In most cases,
/dev/urandom is equally good, but as the paper I should you stated,
and it seems logical to me, the quality of the numbers from /dev/urandom
could be more predictable once the entropy pool is exhausted.  I don't
really see how it could possibly be "far worse".

> 
>> random numbers, such as when using them as seed values for
>> PRNGs.  The analysis clearly states that /dev/urandom, when
>> when the entropy is exhausted, results in theoretically
>> easier to guess random numbers, but you're right in that
>> /dev/urandom was designed to provide lots of high-quality
>> random bytes.  Thus for most uses, one should prefer that.
>>
>> As a practical matter, modern hardware (the last couple of
>> generations of Intel, for example) include a hardware random
> 
> As pointed out, my /dev/random certainly blocks. After 10 sec I got all
> of 64 bytes our of it, while /dev/urandom gave 1/4 GB. 
> My kernel is 3.10.48. My processor is
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 23
> model name      : Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
> stepping        : 10
> microcode       : 0xa0b
> cpu MHz         : 1596.000
> cache size      : 3072 KB


Yep, that's older hardware.  Try it on an Intel i7 CPU.

> I believe that they already had the onboard rng. And writing any program
> so it will block on commonly used equipment is simply irresponsible. 

Perhaps so, but it is common nonetheless.  As your article points out,
it is a common belief.

> 
> And note that you said that the intel cpu random number generator is not
> trusted, but ALL of your randomness in your non-blocking /dev/random is
> coming from that source. Ie, its randomness is no better than the
> randomness of that source, even if the randomness estimater in the
> kernel might estimate more. For example if the on board generator simply
> does a 10 bit hash on consecutive integers, the randomness is zero, but
> the linux estimator would say that is far far more than that. 

It is never the sole source of randomness, if there are other
sources.  And mixing non-random numbers into the input pool
doesn't not decrease the randomness of the numbers in
the entropy pool.  In other words, it may not help, but it
can never hurt.  This is why /dev/random is writable; any
process is allowed to add data to the pool.  Doing so does
not affect the entropy measure however; only data added by
root is so trusted.

> 
> It is simply stupid to use /dev/random

Maybe so.  In any case, you are entitled to use /dev/urandom
if you prefer in your applications.

> 
> 
>> number generator.  While the Linux maintainers don't trust
>> it sufficiently to expose it as /dev/hw_random, it is used
>> as an entropy source.  The practical result is, it is almost
>> impossible to block using /dev/random (I've tried on a new
>> Dell running Fedora 20 to make it block, but couldn't.)
>> So in the end, it is probably moot which one you use any
>> more.
> 
> If you do not trust /dev/urandom on the intel generator,
> you sure should not trust /dev/random either. 

That's true, but nobody said they don't trust either.  The
Linux maintainers decided not to trust Intel's hardware RNG
sufficient to expose it as /dev/hw_random, which, if used,
would make the Intel HW the sole source of random numbers.
But they do trust it sufficient to use it as one of the
inputs to the input pool, from which the entropy pool
is derived.

For the more trusting among us, there is also
<http://www.nist.gov/itl/csd/ct/nist_beacon.cfm>,
the U.S. Gov. public random number source.

> 
>>
>> (I read the details of an interesting attack, where the
>> attacker read from /dev/random continuously, and measured
>> the time between outputs.  On older hardware running virtual
>> machines, the main source of random noise is keystroke
>> timings.  The attacker was able to determine what another
>> user was typing using this method!)
> 
> And you are advocating /dev/random? Sheesh.

I never said anything like that.  Sheesh, indeed!

> 
>>
>> An aside:  pwgen uses /dev/urandom, while apg uses /dev/random.
> 
> And if it does it is simply irresponsible. 

And yet apg is commonly used.

> And it uses an internal PRNG which is undoubtedly much worse than the
> one used by /dev/urandom, to generate the output from a seed supplied by
> /dev/random. This is to put it mildly, insane. 

I believe the code for the FLOSS apg is derived from
U.S. FIPS-181, although the appendix containing the source code
is not available on-line.  In any case, it's hardly
irresponsible or insane to use /dev/random on Linux, if your
application can tolerate the occasionally blockage.

> 
>> So try this simple experiment:
>>  while :; do apg; done
>> to see if your system will ever block reading from /dev/random.
>>
>> For generating 10+ random characters for use as a password,
>> probably /dev/urandom is the technically correct choice.
> 
> weasle word-- probably. Could you pls give us an estimate as to how much
> the use of /dev/urandom would decrease the search time for that password
> over /dev/random?

It would take a lot more math chops than I possess to determine
that.  Maybe you could do some research on it, you seem to be
implying you do have the know-how for such an analysis.

>>
>> Note that some studies suggest that passphrases are harder
>> to crack than passwords: you generate 5+ randomly selected
>> English words, and string them together with randomly
>> selected symbols.  While too small to be very secure, you
>> could select the words using the standard dictd word
>> list:
>>
>>  shuf /usr/share/dict/words | head -n 8
>>
>> (Generating seven random symbols to use to separate the
>> eight words is left as an exercise to the reader.)
>>

(William, why so angry?  I only pointed out to the OP that
/dev/urandom doesn't contain more entropy than /dev/random,
and later added some hopefully interesting info.  Just who
the heck are you, that you can afford to be so opinionated,
and call any disagreement "insane", "irresponsible", etc?
If I'm wrong, would I be the first to post incorrect
information on the Internet?  Is that really a good reason
to be so upset?  Maybe you should switch to decaffeinated
before any more posting!)

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#12298

On 2014-10-12, Wayne <nospam@all.invalid> wrote:
> On 10/11/2014 8:30 PM, William Unruh wrote:
>> On 2014-10-11, Wayne <nospam@all.invalid> wrote:
>>> On 10/11/2014 6:34 PM, Rich wrote:
>>>> Bill Cunningham <nospam@nspam.invalid> wrote:
>>>>
....
>>>>
>>>> http://www.2uo.de/myths-about-urandom/
>>>
>>> Everything to do with random numbers and security is more
>>> complicated than it seems.  I took a look at that page, but
>>> it looks wrong to me.  Try this one instead:
>> 
>> It looks wrong to you? Exactly who are "you" that your impressions
>> should be listened to? And why does it "look wrong"
>> 
>
> I'm nobody.  I am neither a mathematician nor a security
> expert.  If you don't agree with me, and you have some
> knowledge of your own, you would be wise not to listen
> to my opinions.
>
> It looks wrong because I know there are two entropy pools in
> the kernel, and the picture drawn, admittedly a simplification,
> shows only one.  I prefer to trust what I've read from the
> detailed analysis I showed you, and comments from Ted T'so's
> blog.
>
And the text states that this is a simplified diagram and that there are
three entropy pools.

"This is a pretty rough simplification. In fact, there isn't just one,
but three pools filled with entropy. One primary pool, and one for
/dev/random and /dev/urandom each, feeding off the primary pool. Those
three pools all have their own entropy counts, but the counts of the
secondary pools (for /dev/random and /dev/urandom) are mostly close to
zero, and “fresh” entropy flows from the primary pool when
needed, decreasing its entropy count. Also there is a lot of mixing and
re-injecting outputs back into the system going on. All of this is far
more detail than is necessary for this document."

 And that analysis does not differentiate between /dev/urandom and
 /dev/random. It does not say that /dev/random is better. 

It basically says they are pretty good could be improved but not
clearly.




 >> 
>>>
>>> <http://eprint.iacr.org/2012/251.pdf>
>>>
>>> The idea is /dev/random is for small amounts of high quality

The idea is that /dev/random is there to trip the unwary.

>> 
>> IF you are going to need it for such "high qulaity" ( what does that
>> mean-- it taes 10^500 ages of the universe to break rather than 10^499?)
>> then do not use /dev/random OR /dev/urandom. Both are bad. As as stated,
>> /dev/random is far worse.
>
> On Liunux systems without a trusted hardware random number generator,
> you can't do better than using /dev/random.  In most cases,
> /dev/urandom is equally good, but as the paper I should you stated,
> and it seems logical to me, the quality of the numbers from /dev/urandom
> could be more predictable once the entropy pool is exhausted.  I don't
> really see how it could possibly be "far worse".

You yourself showed it is far worse. If you can read someone else's
typing from it, it is far far worse. If it blocks it is far worse. If it
encourages people to not use randomness because of that blocking it is
far worse. Security is not a technical thing, it is the whole system.


>
>> 
>>> random numbers, such as when using them as seed values for
>>> PRNGs.  The analysis clearly states that /dev/urandom, when
>>> when the entropy is exhausted, results in theoretically
>>> easier to guess random numbers, but you're right in that
>>> /dev/urandom was designed to provide lots of high-quality
>>> random bytes.  Thus for most uses, one should prefer that.
>>>
>>> As a practical matter, modern hardware (the last couple of
>>> generations of Intel, for example) include a hardware random
>> 
>> As pointed out, my /dev/random certainly blocks. After 10 sec I got all
>> of 64 bytes our of it, while /dev/urandom gave 1/4 GB. 
>> My kernel is 3.10.48. My processor is
>> processor       : 1
>> vendor_id       : GenuineIntel
>> cpu family      : 6
>> model           : 23
>> model name      : Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
>> stepping        : 10
>> microcode       : 0xa0b
>> cpu MHz         : 1596.000
>> cache size      : 3072 KB
>
>
> Yep, that's older hardware.  Try it on an Intel i7 CPU.

And so what? If a program you write blocks on some hardware that people
use, it is bad. 

>
>> I believe that they already had the onboard rng. And writing any program
>> so it will block on commonly used equipment is simply irresponsible. 
>
> Perhaps so, but it is common nonetheless.  As your article points out,
> it is a common belief.

Not my article. DO you mean my post?

>
>> 
>> And note that you said that the intel cpu random number generator is not
>> trusted, but ALL of your randomness in your non-blocking /dev/random is
>> coming from that source. Ie, its randomness is no better than the
>> randomness of that source, even if the randomness estimater in the
>> kernel might estimate more. For example if the on board generator simply
>> does a 10 bit hash on consecutive integers, the randomness is zero, but
>> the linux estimator would say that is far far more than that. 
>
> It is never the sole source of randomness, if there are other
> sources.  And mixing non-random numbers into the input pool
> doesn't not decrease the randomness of the numbers in
> the entropy pool.  In other words, it may not help, but it

The Bernstein argument shows it can. 

But your claim was that /dev/random was better than /dev/urandom. Having
/dev/random not block because it mixes in predictable garbage means it
is no better than /dev/urandom, and it breaks (blocks) of non "modern"
hardware. 


> can never hurt.  This is why /dev/random is writable; any
> process is allowed to add data to the pool.  Doing so does
> not affect the entropy measure however; only data added by
> root is so trusted.
>
>> 
>> It is simply stupid to use /dev/random
>
> Maybe so.  In any case, you are entitled to use /dev/urandom
> if you prefer in your applications.

I do. What I am saying is not for me. I already know. It is for others
that might read this post thread and might be tempted to use
/dev/random.

>
>> 
>> 
>>> number generator.  While the Linux maintainers don't trust
>>> it sufficiently to expose it as /dev/hw_random, it is used
>>> as an entropy source.  The practical result is, it is almost
>>> impossible to block using /dev/random (I've tried on a new
>>> Dell running Fedora 20 to make it block, but couldn't.)
>>> So in the end, it is probably moot which one you use any
>>> more.
>> 
>> If you do not trust /dev/urandom on the intel generator,
>> you sure should not trust /dev/random either. 
>
> That's true, but nobody said they don't trust either.  The
> Linux maintainers decided not to trust Intel's hardware RNG
> sufficient to expose it as /dev/hw_random, which, if used,
> would make the Intel HW the sole source of random numbers.
> But they do trust it sufficient to use it as one of the
> inputs to the input pool, from which the entropy pool
> is derived.

Probably for the same reason as you gave above "it cannot hurt". But in
the situation where /dev/random produces 64 bytes without the generator
and 10^9 with it, then it is the ONLY source of random numbers. Ie, it
IS exposing it as the sole random number source on that system.

>
> For the more trusting among us, there is also
><http://www.nist.gov/itl/csd/ct/nist_beacon.cfm>,
> the U.S. Gov. public random number source.
>
>> 
>>>
>>> (I read the details of an interesting attack, where the
>>> attacker read from /dev/random continuously, and measured
>>> the time between outputs.  On older hardware running virtual
>>> machines, the main source of random noise is keystroke
>>> timings.  The attacker was able to determine what another
>>> user was typing using this method!)
>> 
>> And you are advocating /dev/random? Sheesh.
>
> I never said anything like that.  Sheesh, indeed!

Sure you did-- above.

>
>> 
>>>
>>> An aside:  pwgen uses /dev/urandom, while apg uses /dev/random.
>> 
>> And if it does it is simply irresponsible. 
>
> And yet apg is commonly used.
>
>> And it uses an internal PRNG which is undoubtedly much worse than the
>> one used by /dev/urandom, to generate the output from a seed supplied by
>> /dev/random. This is to put it mildly, insane. 
>
> I believe the code for the FLOSS apg is derived from
> U.S. FIPS-181, although the appendix containing the source code
> is not available on-line.  In any case, it's hardly
> irresponsible or insane to use /dev/random on Linux, if your
> application can tolerate the occasionally blockage.

I disagree. In software you use for yourself you can do what you want of
course. In software for general consumption, I believe it IS
irresponsible. 

>
>> 
>>> So try this simple experiment:
>>>  while :; do apg; done
>>> to see if your system will ever block reading from /dev/random.
>>>
>>> For generating 10+ random characters for use as a password,
>>> probably /dev/urandom is the technically correct choice.
>> 
>> weasle word-- probably. Could you pls give us an estimate as to how much
>> the use of /dev/urandom would decrease the search time for that password
>> over /dev/random?
>
> It would take a lot more math chops than I possess to determine
> that.  Maybe you could do some research on it, you seem to be
> implying you do have the know-how for such an analysis.

Nope. Just implying that you and others who advocate using /dev/urandom
do not. 

>
>>>
>>> Note that some studies suggest that passphrases are harder
>>> to crack than passwords: you generate 5+ randomly selected
>>> English words, and string them together with randomly
>>> selected symbols.  While too small to be very secure, you
>>> could select the words using the standard dictd word
>>> list:
>>>
>>>  shuf /usr/share/dict/words | head -n 8
>>>
>>> (Generating seven random symbols to use to separate the
>>> eight words is left as an exercise to the reader.)
>>>
>
> (William, why so angry?  I only pointed out to the OP that
> /dev/urandom doesn't contain more entropy than /dev/random,
> and later added some hopefully interesting info.  Just who
> the heck are you, that you can afford to be so opinionated,
> and call any disagreement "insane", "irresponsible", etc?
> If I'm wrong, would I be the first to post incorrect
> information on the Internet?  Is that really a good reason
> to be so upset?  Maybe you should switch to decaffeinated
> before any more posting!)

I do not drink coffee of any sort. 
I am upset because I think it is irresponsible to advocate using
/dev/random, and especially because it is so often done. 

>

[toc] | [prev] | [next] | [standalone]

#12284

Bill Cunningham <nospam@nspam.invalid> wrote:

> "William Unruh" <unruh@invalid.ca> wrote in message 
> news:m18un5$la4$4@dont-email.me...
> > On 2014-10-10, Bit Twister <BitTwister@mouse-potato.com> wrote:
> >> On Fri, 10 Oct 2014 08:50:32 +0000 (UTC), Rich wrote:
> >>>
> >>> That is most likely a brute force password attempt.  If you shutdown
> >>> ssh, you'll block the attempts, but also prevent yourself from logging
> >>> in via ssh.  So if you log in via ssh, you'll end up shutting yourself
> >>> out as well.
> >>
> >> Just tell your firewall what ip addresses are allowed to connect to sshd.
> >> Tell sshd that root is not allowed to use a password login.
> >> Tell sshd to listen on a different port.
> >>
> >>
> >>> However, if your password is properly random, you have little to worry
> >>> about other than extra entries in your log files.
> >>
> >> Random passwords are easier to crack. Use a funky phrase like
> >> my dog eats concrete.
> >> Feel free to sprinkle in numbers and !@#$%^&*()_+= characters.
> >
> > He did say "properly random". I am sure by properly he did not mean 4
> > random characters. A long enough password with random characters is
> > certainly better than your example which really is not terribly random.

>     Something generated by uuid would I think be pretty good. Or better yet 
> if you could direct something from dev/urandom as text; but I don't know if 
> you could do that.

Sure you can, provided you are willing to accept outright deletion of
some byte values:

  $ dd if=/dev/urandom bs=1 count=50 2> /dev/null | tr -d '[:cntrl:][:space:]'
  nãnغÐâlæ]ÒÈ&ã0eìGyE¼,^ZOsÔÔ°Ìo%öz£

  $ dd if=/dev/urandom bs=1 count=50 2> /dev/null | tr -d '[:cntrl:][:space:]'
  ئg±Ð>ùÉ$üèHÞÅ(ðS÷dÌ®6°°/¬¿(0CÆW·

  $ dd if=/dev/urandom bs=1 count=50 2> /dev/null | tr -d '[:cntrl:][:space:]'
  e®ü1ð}4y_)¿qîñl&×Ùß÷d·Q¦e,¼0³¸äl½\à¡+¨¶¢

  $

Note - I added a linefeed manually to make things visually lay out better.

[toc] | [prev] | [next] | [standalone]

#12269

On 2014-10-10, Bill Cunningham <nospam@nspam.invalid> wrote:
>
> "Bit Twister" <BitTwister@mouse-potato.com> wrote in message 
> news:slrnm3e6v1.g24.BitTwister@wb.home.test...
>> On Thu, 9 Oct 2014 19:23:11 -0400, Bill Cunningham wrote:
>>>     Hi,
>>>
>>> I can't find in fedora like there seems to be in other distros a config 
>>> file
>>> for ssh.
>>
>> It should not be hard to find, try
>> locate ssh | grep conf | grep etc
>>
>>> There is the sshd that constrols the service. People are trying to
>>> hack me. I did use this to turn it off.
>>>
>>> service sshd stop
>>>
>>> Which in turn caused systemctl to deactivate ssh(d).
>>
>> No it did not deactivate it, It did shut down the sshd service/daemon.
>> Next boot, sshd will be running again.
>>
>>> Not can I turn this off by default?
>>
>> Yes,  "systemctl disable sshd," disables sshd from being started during 
>> boot.
>>
>> You can still do a systemctl start sshd when you need it to run then
>> systemctl stop sshd when done.
>
>     I logged on the other day and the shell told me that there was over 400 
> attempts by a certain IP address to connect. It must've been while I was 
> using the machine and didn't notice it.
>
> Bill
>
>

I have a script which look in /var/log/messages for login attempts and
if it finds more than 5 for root, or 10 for another user, it enters that
IP into /etc/hosts.allow with a deny flag. 

[toc] | [prev] | [next] | [standalone]

#12267

On 2014-10-09, Bill Cunningham <nospam@nspam.invalid> wrote:
>     Hi,
>
> I can't find in fedora like there seems to be in other distros a config file 
> for ssh. There is the sshd that constrols the service. People are trying to 
> hack me. I did use this to turn it off.

The config files are in /etc/ssh/

>
> service sshd stop

They use systemd Somewhere in /usr/lib/systemd
will be the config to start and stop sshd 

>
> Which in turn caused systemctl to deactivate ssh(d). Not can I turn this off 
> by default?

You could try
systemctl disable sshd
>
> Bill
>
>

[toc] | [prev] | [next] | [standalone]

#12271

Bill Cunningham wrote on 09. October 2014:
>
> I can't find in fedora like there seems to be in other distros a config file 
> for ssh. There is the sshd that constrols the service. People are trying to 
> hack me. I did use this to turn it off.
>
> service sshd stop
>
> Which in turn caused systemctl to deactivate ssh(d). Not can I turn this off 
> by default?

By removing the start link of the runlevel it is started. Other mentioned
the systemctl command already. If you don't need ssh yourself you're all
set.

Otherwise you could try to harden the system. Best way is probably
allowing logins only via keys and deactivate password auth (nobody can
log in then, not even you with the correct password).

If you want to keep password authorization you can forbid direct root
logins (you log in as user and become root on the system then if
needed).

And allow only the user(s) to log in you want. If your user is called
"bill" for example, open the /etc/ssh/sshd_config and locate or add the
line

AllowUsers

and add "bill" so it looks like

AllowUsers bill

You may add more users, separated by blanks. You need to restart the ssh
server after these changes.

Now only bill can log in, no one else. Not even with the correct
password.

Then there are iptable rules somewhere which limit access to the system
in a certain time interval.

You cold also change the ssh port to something else than 22.
-- 
Andreas

I wish my grass was emo. Then it would cut itself.

[toc] | [prev] | [next] | [standalone]

#12279

"Andreas Kohlbach" <oct14.5.ankman@spamgourmet.com> wrote in message 
news:87h9zb1yh7.fsf@usenet.ankman.de...
> Bill Cunningham wrote on 09. October 2014:
>>
>> I can't find in fedora like there seems to be in other distros a config 
>> file
>> for ssh. There is the sshd that constrols the service. People are trying 
>> to
>> hack me. I did use this to turn it off.
>>
>> service sshd stop
>>
>> Which in turn caused systemctl to deactivate ssh(d). Not can I turn this 
>> off
>> by default?
>
> By removing the start link of the runlevel it is started. Other mentioned
> the systemctl command already. If you don't need ssh yourself you're all
> set.
>
> Otherwise you could try to harden the system. Best way is probably
> allowing logins only via keys and deactivate password auth (nobody can
> log in then, not even you with the correct password).
>
> If you want to keep password authorization you can forbid direct root
> logins (you log in as user and become root on the system then if
> needed).
>
> And allow only the user(s) to log in you want. If your user is called
> "bill" for example, open the /etc/ssh/sshd_config and locate or add the
> line
>
> AllowUsers
>
> and add "bill" so it looks like
>
> AllowUsers bill
>
> You may add more users, separated by blanks. You need to restart the ssh
> server after these changes.
>
> Now only bill can log in, no one else. Not even with the correct
> password.
>
> Then there are iptable rules somewhere which limit access to the system
> in a certain time interval.
>
> You cold also change the ssh port to something else than 22.

    The only user I have is root. So I will try as you suggest.

AllowUsers root

Now will that work with root?

Bill

[toc] | [prev] | [next] | [standalone]

#12286

On 2014-10-11, Bill Cunningham <nospam@nspam.invalid> wrote:
>
> "Andreas Kohlbach" <oct14.5.ankman@spamgourmet.com> wrote in message 
> news:87h9zb1yh7.fsf@usenet.ankman.de...
>> Bill Cunningham wrote on 09. October 2014:
>>>
>>> I can't find in fedora like there seems to be in other distros a config 
>>> file
>>> for ssh. There is the sshd that constrols the service. People are trying 
>>> to
>>> hack me. I did use this to turn it off.
>>>
>>> service sshd stop
>>>
>>> Which in turn caused systemctl to deactivate ssh(d). Not can I turn this 
>>> off
>>> by default?
>>
>> By removing the start link of the runlevel it is started. Other mentioned
>> the systemctl command already. If you don't need ssh yourself you're all
>> set.
>>
>> Otherwise you could try to harden the system. Best way is probably
>> allowing logins only via keys and deactivate password auth (nobody can
>> log in then, not even you with the correct password).
>>
>> If you want to keep password authorization you can forbid direct root
>> logins (you log in as user and become root on the system then if
>> needed).
>>
>> And allow only the user(s) to log in you want. If your user is called
>> "bill" for example, open the /etc/ssh/sshd_config and locate or add the
>> line
>>
>> AllowUsers
>>
>> and add "bill" so it looks like
>>
>> AllowUsers bill
>>
>> You may add more users, separated by blanks. You need to restart the ssh
>> server after these changes.
>>
>> Now only bill can log in, no one else. Not even with the correct
>> password.
>>
>> Then there are iptable rules somewhere which limit access to the system
>> in a certain time interval.
>>
>> You cold also change the ssh port to something else than 22.
>
>     The only user I have is root. So I will try as you suggest.
>
> AllowUsers root
>
> Now will that work with root?

Really bad idea. It destroys all of the security that Unix goes so far
to achieve. 
root is for setting up the system. Nothing else. 

>
> Bill
>
>

[toc] | [prev] | [next] | [standalone]

#12290

Bill Cunningham wrote on 10. October 2014:
>
> "Andreas Kohlbach" <oct14.5.ankman@spamgourmet.com> wrote in message 
> news:87h9zb1yh7.fsf@usenet.ankman.de...

[...]

>> And allow only the user(s) to log in you want. If your user is called
>> "bill" for example, open the /etc/ssh/sshd_config and locate or add the
>> line
>>
>> AllowUsers
>>
>> and add "bill" so it looks like
>>
>> AllowUsers bill
>>
>> You may add more users, separated by blanks. You need to restart the ssh
>> server after these changes.
>>
>> Now only bill can log in, no one else. Not even with the correct
>> password.
>>
>> Then there are iptable rules somewhere which limit access to the system
>> in a certain time interval.
>>
>> You cold also change the ssh port to something else than 22.
>
>     The only user I have is root. So I will try as you suggest.
>
> AllowUsers root
>
> Now will that work with root?

Never thought of this. Because it's a bad idea. Then an attacker gains
full control over your machine if he has the password. If he only got the
password to a non privileged account he still needs to find the root
password (local exploit or brute force).
-- 
Andreas

I wish my grass was emo. Then it would cut itself.

[toc] | [prev] | [next] | [standalone]

#12556

On Thu, 09 Oct 2014 19:23:11 -0400, Bill Cunningham wrote:

> Hi,
> 
> I can't find in fedora like there seems to be in other distros a config
> file for ssh. There is the sshd that constrols the service. People are
> trying to hack me. I did use this to turn it off.
> 
> service sshd stop
> 
> Which in turn caused systemctl to deactivate ssh(d). Not can I turn this
> off by default?
> 
> Bill

See if sshd is running = pgrep sshd


IF yes THEN KillIt = kill <the pidNumber>

See if it's killed = pgrep sshd

IF not, use a bigger hammer = kill -9 <the pidNumber>

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.misc

csiph-web