Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 11:13 AM, J. Roeleveld wrote:
> 
> What would take longer?
> brute-forcing your root-password or a 4096 byte ssh key?
> 

My password, by a lot. The password needs to be brute-forced over the
network, first of all.

And a 4096-bit public encryption key doesn't provide 4096 bits of
security -- you're thinking of symmetric encryption. Regardless, if
someone is brute-forcing passwords, it would take them "twice" as long
to brute-force both my root password and the password on my SSH key as
it would to do the root password alone. I can do better than 2x by
adding a character to my password. And that's pointless, because it
would already take forever. No-more-Earth forever.


> 
>> All of the good attacks (shoot me, bribe me, steal the hardware, etc.)
>> that I can think of work just fine against the two-factor auth. The only
>> other way to get the root password is to be there when I transfer it
>> from my brain to the terminal, in which case you have the SSH key, too.
> 
> The ssh-key is stored on your desktop/laptop. Secured with a passphrase.
> 

If my machine is compromised, the attacker can see both the SSH key
password when I type it, and the root password when I type that.




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 10:30 AM, Alan McKinnon wrote:
>> Maybe, but your argument isn't convincing. How am I better off doing it
>> your way (what is your way)?
> 
> The most common way is to disallow all remote logins as root. Admins log
> in with their personal unpriv account using an ssh key. To become root
> they must su or sudo -i with a password.
> 
> Benefits: two factor auth using different mechanisms. Having the key or
> the password is not enough to become root, an attacker must have both.
> 
> Allowing root logins directly over the network is considered bad
> practice, due to the "one mistake = you lose" aspect.
> 

It sounds good, but what sort of attack on my root password does the
two-factor authentication prevent? Assume that I'm not an idiot and to
brute-force my root password would take literally forever.

I'm weighing this against the complexity of adding separate accounts,
making sure that *those* are secure, risking breakage of the sudoers
file, granting someone the ability to brute force my SSH key password
offline,...

All of the good attacks (shoot me, bribe me, steal the hardware, etc.)
that I can think of work just fine against the two-factor auth. The only
other way to get the root password is to be there when I transfer it
from my brain to the terminal, in which case you have the SSH key, too.




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread J. Roeleveld
On Tuesday, November 10, 2015 10:58:48 AM Michael Orlitzky wrote:
> On 11/10/2015 10:30 AM, Alan McKinnon wrote:
> >> Maybe, but your argument isn't convincing. How am I better off doing it
> >> your way (what is your way)?
> > 
> > The most common way is to disallow all remote logins as root. Admins log
> > in with their personal unpriv account using an ssh key. To become root
> > they must su or sudo -i with a password.
> > 
> > Benefits: two factor auth using different mechanisms. Having the key or
> > the password is not enough to become root, an attacker must have both.
> > 
> > Allowing root logins directly over the network is considered bad
> > practice, due to the "one mistake = you lose" aspect.
> 
> It sounds good, but what sort of attack on my root password does the
> two-factor authentication prevent? Assume that I'm not an idiot and to
> brute-force my root password would take literally forever.

What would take longer?
brute-forcing your root-password or a 4096 byte ssh key?

> I'm weighing this against the complexity of adding separate accounts,
> making sure that *those* are secure, risking breakage of the sudoers
> file, granting someone the ability to brute force my SSH key password
> offline,...

You secure the seperate account using a ssh-key.
The root-password will only work once logged in using the seperate account.

> All of the good attacks (shoot me, bribe me, steal the hardware, etc.)
> that I can think of work just fine against the two-factor auth. The only
> other way to get the root password is to be there when I transfer it
> from my brain to the terminal, in which case you have the SSH key, too.

The ssh-key is stored on your desktop/laptop. Secured with a passphrase.

--
Joost



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Alan McKinnon
On 10/11/2015 16:47, Michael Orlitzky wrote:
> On 11/09/2015 10:26 PM, Jeff Smelser wrote:
>>
>> The question is, why would you want root login? If your still using it,
>> your doing it wrong.
> 
> Maybe, but your argument isn't convincing. How am I better off doing it
> your way (what is your way)?
> 
> 

The most common way is to disallow all remote logins as root. Admins log
in with their personal unpriv account using an ssh key. To become root
they must su or sudo -i with a password.

Benefits: two factor auth using different mechanisms. Having the key or
the password is not enough to become root, an attacker must have both.

Allowing root logins directly over the network is considered bad
practice, due to the "one mistake = you lose" aspect.

-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/09/2015 10:26 PM, Jeff Smelser wrote:
> 
> The question is, why would you want root login? If your still using it,
> your doing it wrong.

Maybe, but your argument isn't convincing. How am I better off doing it
your way (what is your way)?




Re: [gentoo-user] Better CPU for compiling with gcc

2015-11-10 Thread Alec Ten Harmsel



On 2015-11-10 14:07, Stanislav Nikolov wrote:


On 11/10/2015 08:55 PM, Alan McKinnon wrote:

On 10/11/2015 20:37, Stanislav Nikolov wrote:

On 11/10/2015 08:17 PM, Mick wrote:

On Tuesday 10 Nov 2015 17:47:08 Stanislav Nikolov wrote:

Dear Gentoo users,
I'm building a new PC. I have a budget of ~$550-$650.



The most expensive Intel CPU is the skylake i7-6700k.

Thanks




I can't help but think you are approaching this from the wrong perspective.

Why exactly are you using compile times as your sole criterion? Are you
building a compile farm for Ubuntu? Running continuous integration tests
for LibreOffice [on a $600 budget in a cardboard box :-) ]?

Or do you want emerge world to get it over with quicker?

If the latter, you better rethink your priorities. In computing terms,
compilation is a rare event; launching apps is a common event; and
writing to the disk happens all the time. Optimize for the common case.


In addition, upgrades are something that can be done overnight, or 
really any time you are not using the machine.




A CPU never works in isolation, it is always part of a much larger
system, like disks, RAM and all possible kinds of I/O. The best CPU on
the market plugged into a POS motherboard will perform on emerge world
like a piece of shit - it will follow the weakest link.


This; I have an i7-3930K, which has 6 physical cores at 3.8GHz. I also 
have 32GB of RAM and an SSD. There was a large speedup[1] moving 
portage's workdir from SSD to tmpfs. Compiling is a really balanced 
workload, stressing the disk (multiple small reads), memory, and CPU. 
For fast compilation, emphasize RAM first (compile in tmpfs if 
possible), then CPU, then disk. Like Alan said, though, you should 
really optimize for the average case on not worry about the speed of 
compiling stuff.


Alec

1. It was a long time ago so I don't remember the exact numbers, but my 
firefox compiling time went from ~15 minutes to ~10 minutes after 
switching from SSD to tmpfs for portage's workdir.




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Jeff Smelser
On Tue, Nov 10, 2015 at 11:55 AM, Michael Orlitzky  wrote:

> On 11/10/2015 01:26 PM, Alan McKinnon wrote:
> >
> > I think you are approaching this problem from the wrong viewpoint. You
> > have to assume an attacker has vastly more resources to bear on the
> > problem than you have. Thanks to Amazon and the cloud, this is now a
> > very true reality. Brute force attacking a root password is nowhere near
> > as complex as the maths would lead you to believe; for one thing they
> > are decidedly not random. The fact is that they are heavily biased,
> > mostly due to 1) you need to be able to remember it and 2) you need to
> > be able to type it.
> >
> > Humans have been proven to be very bad at coming up with passwords that
> > are truly good[1] and hard for computers to figure out. And our brains
> > and very very VERY good at convincing us that our latest dumb idea is
> > awesome. Are you really going to protect the mother lode (root password)
> > with a single system proven to be quite broken and deeply flawed by
> wetware?
> >
>
> I know all that, but I asked you to assume that I'm not an idiot and
> that it would take forever to brute-force my root password =)
>
> I'm not going to tell you what it is, so you'll have to believe me.
>
>
I guess from this your assuming that everyones passwords that have been
hacked are god, birthdays and such?


Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Stanislav Nikolov


On 11/10/2015 09:25 PM, Michael Orlitzky wrote:
> On 11/10/2015 02:23 PM, Stanislav Nikolov wrote:
>> Are you sure you know how such keys work? An extremely 15 character
>> password (Upper case, lower case, numbers, 8 more symbols) gives you
>> ~4747561509943000 combinations. Just a simple 2048 bit
>> key on the other hand (~180 of which are "secure")
>> 153249554086558358347027150309183618739122183602176. Thats ALOT
>> moar. You don't have to generate the key from a password!
>>
> I don't have to brute-force the key. The key is encrypted with a
> password. How long is that password?
>
>
>
1) The key is not encrypted.  
2) You don't need a password to generate a key.  
3) Don't go full retard, do your research before arguing.



Re: [gentoo-user] Better CPU for compiling with gcc

2015-11-10 Thread Mick
On Tuesday 10 Nov 2015 17:47:08 Stanislav Nikolov wrote:
> Dear Gentoo users,
> I'm building a new PC. I have a budget of ~$550-$650. No GPU, no special
> case (I may use a card box), not even a hdd or ssd. So, as you can see,
> it's pretty much "get the best CPU and mobo/ram that are compatible with
> it". The problem is, which is the best one. By "best" I mean to compile
> shit fast. My laptop with 3rd gen i5 compiles firefox for 40 minutes on
> average.
> 
> The most expensive Intel CPU is the skylake i7-6700k. But is it the best?
> Is there something from AMD that will perform even better? I can't find
> any benchmarks with AMD/Intel CPUs. And how much does the mobo matter?
> Will a cheap $30 400W PSU power that thing?
> 
> Thanks

I don't (yet) own a i7-6700k, but my 6 year old laptop with (1st generation) 
i7 Q720  @1.60GHz takes slightly less than yours:

 Sat Oct  3 14:35:40 2015 >>> www-client/firefox-38.3.0
   merge time: 36 minutes and 53 seconds.

 Fri Nov  6 09:10:06 2015 >>> www-client/firefox-38.4.0
   merge time: 38 minutes and 8 seconds.


In contrast a year old AMD A10-7850K APU is significantly faster:

 Sat Oct  3 19:40:48 2015 >>> www-client/firefox-38.3.0
   merge time: 17 minutes and 42 seconds.

 Fri Nov  6 08:41:02 2015 >>> www-client/firefox-38.4.0
   merge time: 18 minutes and 18 seconds.


I would also be interested to see compile times of more modern i7s and FXs, 
but bear in mind that in single core operations Intel is these days 
significantly better than AMD.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Alan McKinnon
On 10/11/2015 17:58, Michael Orlitzky wrote:
> On 11/10/2015 10:30 AM, Alan McKinnon wrote:
>>> Maybe, but your argument isn't convincing. How am I better off doing it
>>> your way (what is your way)?
>>
>> The most common way is to disallow all remote logins as root. Admins log
>> in with their personal unpriv account using an ssh key. To become root
>> they must su or sudo -i with a password.
>>
>> Benefits: two factor auth using different mechanisms. Having the key or
>> the password is not enough to become root, an attacker must have both.
>>
>> Allowing root logins directly over the network is considered bad
>> practice, due to the "one mistake = you lose" aspect.
>>
> 
> It sounds good, but what sort of attack on my root password does the
> two-factor authentication prevent? Assume that I'm not an idiot and to
> brute-force my root password would take literally forever.
> 
> I'm weighing this against the complexity of adding separate accounts,
> making sure that *those* are secure, risking breakage of the sudoers
> file, granting someone the ability to brute force my SSH key password
> offline,...
> 
> All of the good attacks (shoot me, bribe me, steal the hardware, etc.)
> that I can think of work just fine against the two-factor auth. The only
> other way to get the root password is to be there when I transfer it
> from my brain to the terminal, in which case you have the SSH key, too.

I think you are approaching this problem from the wrong viewpoint. You
have to assume an attacker has vastly more resources to bear on the
problem than you have. Thanks to Amazon and the cloud, this is now a
very true reality. Brute force attacking a root password is nowhere near
as complex as the maths would lead you to believe; for one thing they
are decidedly not random. The fact is that they are heavily biased,
mostly due to 1) you need to be able to remember it and 2) you need to
be able to type it.

Humans have been proven to be very bad at coming up with passwords that
are truly good[1] and hard for computers to figure out. And our brains
and very very VERY good at convincing us that our latest dumb idea is
awesome. Are you really going to protect the mother lode (root password)
with a single system proven to be quite broken and deeply flawed by wetware?

Two factor auth is cheap (ssh-keygen and ssh-copy-id) and keys take the
human factor out of the first step. It's not security theatre nor cargo
culting, so why not use it and gain the benefits for minimal effort?

Complexity of separate accounts is a bit of a red herring. If your user
account is weak, I have to assume so is your root account - apart from
UID=0 there is no difference between them. Hopefully you use Puppet or
friends so you set up a decent template once and the system ensures it
stays that way. No having to check if user accounts really are still not
weak.

Finally the root password by it's nature is a shared secret between one
or more admins. On every system a boss has had me look after, I have
shown to my own satisfaction that it is the weak link. It has to exist,
it has to be known an it has to be communicated when it changes. Systems
designed to help make that process safe are themselves weak (such as a
GPG encrypted file protected by  a never-changing shared password
that every admin knows!) Am I going to build a front line of defence
based on ssh keys? You betcha.

Alan

[1] Our bosses and auditors keep coming up with stupid ideas designed to
improve this but all they succeed in doing is causing the problem they
seek to solve. Such as rotating passwords, insisting on punctuation, no
repeating characters. In the real world all this does is invite *bad*
practices - people have to resort to this to get something that
satisfies the password policy and they can remember. And from there it's
a short step to Post-It-Note syndrome


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 01:26 PM, Alan McKinnon wrote:
> 
> I think you are approaching this problem from the wrong viewpoint. You
> have to assume an attacker has vastly more resources to bear on the
> problem than you have. Thanks to Amazon and the cloud, this is now a
> very true reality. Brute force attacking a root password is nowhere near
> as complex as the maths would lead you to believe; for one thing they
> are decidedly not random. The fact is that they are heavily biased,
> mostly due to 1) you need to be able to remember it and 2) you need to
> be able to type it.
> 
> Humans have been proven to be very bad at coming up with passwords that
> are truly good[1] and hard for computers to figure out. And our brains
> and very very VERY good at convincing us that our latest dumb idea is
> awesome. Are you really going to protect the mother lode (root password)
> with a single system proven to be quite broken and deeply flawed by wetware?
> 

I know all that, but I asked you to assume that I'm not an idiot and
that it would take forever to brute-force my root password =)

I'm not going to tell you what it is, so you'll have to believe me.


> Two factor auth is cheap (ssh-keygen and ssh-copy-id) and keys take the
> human factor out of the first step. It's not security theatre nor cargo
> culting, so why not use it and gain the benefits for minimal effort?
> 

The rest of what you say is all true, but *given that no one is going to
brute-force the root password*, what specific attack am I defending against?

I'm not trying to be annoying -- if switching to two-factor auth will
improve things, I'll do it -- but no one has ever been able to tell me
what I'd gain from it.




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 11:26 AM, Michael Orlitzky wrote:
> On 11/10/2015 11:13 AM, J. Roeleveld wrote:
>>
>> What would take longer?
>> brute-forcing your root-password or a 4096 byte ssh key?
>>
> 
> My password, by a lot. The password needs to be brute-forced over the
> network, first of all.

I realized this wasn't correct while I was in the shower =P

To tell if you decrypted the key properly, you need to send it over the
network, so verification of a brute-force attempt on the SSH key takes
about the same amount of time as a brute-force attempt on the root
password. The root password in my head is safe against crypto attacks
though, so if we're just arguing for fun, it's probably still safer.

Adding the key *in addition to* the root password still only gives you a
constant factor improvement, and I'm not worried whether it takes the
bad guys 4,359,811,353 or 8,719,622,706 years to log in. My time would
be better spent taking karate lessons to prevent one of those other
attacks I mentioned.




Re: [gentoo-user] Better CPU for compiling with gcc

2015-11-10 Thread Stanislav Nikolov


On 11/10/2015 08:55 PM, Alan McKinnon wrote:
> On 10/11/2015 20:37, Stanislav Nikolov wrote:
>>
>> On 11/10/2015 08:17 PM, Mick wrote:
>>> On Tuesday 10 Nov 2015 17:47:08 Stanislav Nikolov wrote:
 Dear Gentoo users,
 I'm building a new PC. I have a budget of ~$550-$650. No GPU, no special
 case (I may use a card box), not even a hdd or ssd. So, as you can see,
 it's pretty much "get the best CPU and mobo/ram that are compatible with
 it". The problem is, which is the best one. By "best" I mean to compile
 shit fast. My laptop with 3rd gen i5 compiles firefox for 40 minutes on
 average.

 The most expensive Intel CPU is the skylake i7-6700k. But is it the best?
 Is there something from AMD that will perform even better? I can't find
 any benchmarks with AMD/Intel CPUs. And how much does the mobo matter?
 Will a cheap $30 400W PSU power that thing?

 Thanks
>>> I don't (yet) own a i7-6700k, but my 6 year old laptop with (1st 
>>> generation) 
>>> i7 Q720  @1.60GHz takes slightly less than yours:
>>>
>>>  Sat Oct  3 14:35:40 2015 >>> www-client/firefox-38.3.0
>>>merge time: 36 minutes and 53 seconds.
>>>
>>>  Fri Nov  6 09:10:06 2015 >>> www-client/firefox-38.4.0
>>>merge time: 38 minutes and 8 seconds.
>>>
>>>
>>> In contrast a year old AMD A10-7850K APU is significantly faster:
>>>
>>>  Sat Oct  3 19:40:48 2015 >>> www-client/firefox-38.3.0
>>>merge time: 17 minutes and 42 seconds.
>>>
>>>  Fri Nov  6 08:41:02 2015 >>> www-client/firefox-38.4.0
>>>merge time: 18 minutes and 18 seconds.
>>>
>>>
>>> I would also be interested to see compile times of more modern i7s and FXs, 
>>> but bear in mind that in single core operations Intel is these days 
>>> significantly better than AMD.
>>>
>> So, I shouldn't prepare for a 8x times faster compile time... :(
>>
>
>
> I can't help but think you are approaching this from the wrong perspective.
>
> Why exactly are you using compile times as your sole criterion? Are you
> building a compile farm for Ubuntu? Running continuous integration tests
> for LibreOffice [on a $600 budget in a cardboard box :-) ]?
>
> Or do you want emerge world to get it over with quicker?
>
> If the latter, you better rethink your priorities. In computing terms,
> compilation is a rare event; launching apps is a common event; and
> writing to the disk happens all the time. Optimize for the common case.
>
> A CPU never works in isolation, it is always part of a much larger
> system, like disks, RAM and all possible kinds of I/O. The best CPU on
> the market plugged into a POS motherboard will perform on emerge world
> like a piece of shit - it will follow the weakest link.
>
> If you want to build a compiling machine, buy the best collection of
> stuff that works together well and still fits the budget. If you want a
> machine that you can use and be happy with, ignoree the temptation to
> must have the biggest baddest fastest CU (you will never get to use all
> that big bad fast) and invest rather in gobs of RAM and an SSD. Remember
> that apps are launched many times more than they are compiled. Or put
> another way, sacrifice compilation times t get something you can use.

8GB of RAM are waaay more than I use daily (several firefox tabs, nvim = 2Gb 
max), I have a pretty fast SSD too. Even buying 8GB RAM and a brand new SSD, I 
have > $450 left. Can I buy a AMD CPU that will get the job done faster than 
6700k and/or cheaper?



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Jeff Smelser
I am going to stop this convo. As soon as you say it cant be brute forced,
I am going to move on.

Good luck with that.

On Tue, Nov 10, 2015 at 12:17 PM, Michael Orlitzky  wrote:

> On 11/10/2015 02:00 PM, Jeff Smelser wrote:
> >
> > I guess from this your assuming that everyones passwords that have been
> > hacked are god, birthdays and such?
> >
>
> Again: assume that I'm not an idiot, and that I know how to choose a
> long, random password. It cannot be brute-forced. And if it could,
> adding an SSH key encrypted with a password of the same length would
> provide no extra security.
>
>
>


Re: [gentoo-user] Better CPU for compiling with gcc

2015-11-10 Thread Alan McKinnon
On 10/11/2015 21:07, Stanislav Nikolov wrote:
> 
> 
> On 11/10/2015 08:55 PM, Alan McKinnon wrote:
>> On 10/11/2015 20:37, Stanislav Nikolov wrote:
>>>
>>> On 11/10/2015 08:17 PM, Mick wrote:
 On Tuesday 10 Nov 2015 17:47:08 Stanislav Nikolov wrote:
> Dear Gentoo users,
> I'm building a new PC. I have a budget of ~$550-$650. No GPU, no special
> case (I may use a card box), not even a hdd or ssd. So, as you can see,
> it's pretty much "get the best CPU and mobo/ram that are compatible with
> it". The problem is, which is the best one. By "best" I mean to compile
> shit fast. My laptop with 3rd gen i5 compiles firefox for 40 minutes on
> average.
>
> The most expensive Intel CPU is the skylake i7-6700k. But is it the best?
> Is there something from AMD that will perform even better? I can't find
> any benchmarks with AMD/Intel CPUs. And how much does the mobo matter?
> Will a cheap $30 400W PSU power that thing?
>
> Thanks
 I don't (yet) own a i7-6700k, but my 6 year old laptop with (1st 
 generation) 
 i7 Q720  @1.60GHz takes slightly less than yours:

  Sat Oct  3 14:35:40 2015 >>> www-client/firefox-38.3.0
merge time: 36 minutes and 53 seconds.

  Fri Nov  6 09:10:06 2015 >>> www-client/firefox-38.4.0
merge time: 38 minutes and 8 seconds.


 In contrast a year old AMD A10-7850K APU is significantly faster:

  Sat Oct  3 19:40:48 2015 >>> www-client/firefox-38.3.0
merge time: 17 minutes and 42 seconds.

  Fri Nov  6 08:41:02 2015 >>> www-client/firefox-38.4.0
merge time: 18 minutes and 18 seconds.


 I would also be interested to see compile times of more modern i7s and 
 FXs, 
 but bear in mind that in single core operations Intel is these days 
 significantly better than AMD.

>>> So, I shouldn't prepare for a 8x times faster compile time... :(
>>>
>>
>>
>> I can't help but think you are approaching this from the wrong perspective.
>>
>> Why exactly are you using compile times as your sole criterion? Are you
>> building a compile farm for Ubuntu? Running continuous integration tests
>> for LibreOffice [on a $600 budget in a cardboard box :-) ]?
>>
>> Or do you want emerge world to get it over with quicker?
>>
>> If the latter, you better rethink your priorities. In computing terms,
>> compilation is a rare event; launching apps is a common event; and
>> writing to the disk happens all the time. Optimize for the common case.
>>
>> A CPU never works in isolation, it is always part of a much larger
>> system, like disks, RAM and all possible kinds of I/O. The best CPU on
>> the market plugged into a POS motherboard will perform on emerge world
>> like a piece of shit - it will follow the weakest link.
>>
>> If you want to build a compiling machine, buy the best collection of
>> stuff that works together well and still fits the budget. If you want a
>> machine that you can use and be happy with, ignoree the temptation to
>> must have the biggest baddest fastest CU (you will never get to use all
>> that big bad fast) and invest rather in gobs of RAM and an SSD. Remember
>> that apps are launched many times more than they are compiled. Or put
>> another way, sacrifice compilation times t get something you can use.
> 
> 8GB of RAM are waaay more than I use daily (several firefox tabs, nvim = 2Gb 
> max), I have a pretty fast SSD too. Even buying 8GB RAM and a brand new SSD, 
> I have > $450 left. Can I buy a AMD CPU that will get the job done faster 
> than 6700k and/or cheaper?
> 


That changes things. It wasn't obvious you already had RAM & SSD & stuff.

I'd first make sure I have a decent PSU - none of that crap puny
el-cheapo $300 shit (search list archives for 1000s of posts about dodgy
PSUs). Then split the difference between 8G RAM, a good CPU and an
excellent motherboard. You will use that extra RAM, and a motherboard
that ties all the bits together properly is much more cost-effective
than raw CPU grunt alone.

-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 02:23 PM, Stanislav Nikolov wrote:
> 
> 
> On 11/10/2015 09:17 PM, Michael Orlitzky wrote:
>> On 11/10/2015 02:00 PM, Jeff Smelser wrote:
>>> I guess from this your assuming that everyones passwords that
>>> have been hacked are god, birthdays and such?
>>> 
>> Again: assume that I'm not an idiot, and that I know how to choose
>> a long, random password. It cannot be brute-forced. And if it
>> could, adding an SSH key encrypted with a password of the same
>> length would provide no extra security.
>> 
>> 
> Are you sure you know how such keys work? An extremely 15 character
> password (Upper case, lower case, numbers, 8 more symbols) gives you
> ~4747561509943000 combinations


And since no one seems to believe me, if you could try a million
passwords a second (over the network!), it would take you about
75,272,093,955,210 years to try half of those combinations.




[gentoo-user] Better CPU for compiling with gcc

2015-11-10 Thread Stanislav Nikolov
Dear Gentoo users,
I'm building a new PC. I have a budget of ~$550-$650. No GPU, no special case 
(I may use a card box), not even a hdd or ssd.
So, as you can see, it's pretty much "get the best CPU and mobo/ram that are 
compatible with it". The problem is, which is the best one. By "best" I mean to 
compile shit fast. My laptop with 3rd gen i5 compiles firefox for 40 minutes on 
average.

The most expensive Intel CPU is the skylake i7-6700k. But is it the best? Is 
there something from AMD that will perform even better? I can't find any 
benchmarks with AMD/Intel CPUs.
And how much does the mobo matter? Will a cheap $30 400W PSU power that thing?

Thanks



Re: [gentoo-user] Better CPU for compiling with gcc

2015-11-10 Thread Stanislav Nikolov


On 11/10/2015 08:17 PM, Mick wrote:
> On Tuesday 10 Nov 2015 17:47:08 Stanislav Nikolov wrote:
>> Dear Gentoo users,
>> I'm building a new PC. I have a budget of ~$550-$650. No GPU, no special
>> case (I may use a card box), not even a hdd or ssd. So, as you can see,
>> it's pretty much "get the best CPU and mobo/ram that are compatible with
>> it". The problem is, which is the best one. By "best" I mean to compile
>> shit fast. My laptop with 3rd gen i5 compiles firefox for 40 minutes on
>> average.
>>
>> The most expensive Intel CPU is the skylake i7-6700k. But is it the best?
>> Is there something from AMD that will perform even better? I can't find
>> any benchmarks with AMD/Intel CPUs. And how much does the mobo matter?
>> Will a cheap $30 400W PSU power that thing?
>>
>> Thanks
> I don't (yet) own a i7-6700k, but my 6 year old laptop with (1st generation) 
> i7 Q720  @1.60GHz takes slightly less than yours:
>
>  Sat Oct  3 14:35:40 2015 >>> www-client/firefox-38.3.0
>merge time: 36 minutes and 53 seconds.
>
>  Fri Nov  6 09:10:06 2015 >>> www-client/firefox-38.4.0
>merge time: 38 minutes and 8 seconds.
>
>
> In contrast a year old AMD A10-7850K APU is significantly faster:
>
>  Sat Oct  3 19:40:48 2015 >>> www-client/firefox-38.3.0
>merge time: 17 minutes and 42 seconds.
>
>  Fri Nov  6 08:41:02 2015 >>> www-client/firefox-38.4.0
>merge time: 18 minutes and 18 seconds.
>
>
> I would also be interested to see compile times of more modern i7s and FXs, 
> but bear in mind that in single core operations Intel is these days 
> significantly better than AMD.
>
So, I shouldn't prepare for a 8x times faster compile time... :(



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 02:23 PM, Stanislav Nikolov wrote:
>> 
> Are you sure you know how such keys work? An extremely 15 character
> password (Upper case, lower case, numbers, 8 more symbols) gives you
> ~4747561509943000 combinations. Just a simple 2048 bit
> key on the other hand (~180 of which are "secure")
> 153249554086558358347027150309183618739122183602176. Thats ALOT
> moar. You don't have to generate the key from a password!
> 

I don't have to brute-force the key. The key is encrypted with a
password. How long is that password?





Re: [gentoo-user] Better CPU for compiling with gcc

2015-11-10 Thread Alan McKinnon
On 10/11/2015 20:37, Stanislav Nikolov wrote:
> 
> 
> On 11/10/2015 08:17 PM, Mick wrote:
>> On Tuesday 10 Nov 2015 17:47:08 Stanislav Nikolov wrote:
>>> Dear Gentoo users,
>>> I'm building a new PC. I have a budget of ~$550-$650. No GPU, no special
>>> case (I may use a card box), not even a hdd or ssd. So, as you can see,
>>> it's pretty much "get the best CPU and mobo/ram that are compatible with
>>> it". The problem is, which is the best one. By "best" I mean to compile
>>> shit fast. My laptop with 3rd gen i5 compiles firefox for 40 minutes on
>>> average.
>>>
>>> The most expensive Intel CPU is the skylake i7-6700k. But is it the best?
>>> Is there something from AMD that will perform even better? I can't find
>>> any benchmarks with AMD/Intel CPUs. And how much does the mobo matter?
>>> Will a cheap $30 400W PSU power that thing?
>>>
>>> Thanks
>> I don't (yet) own a i7-6700k, but my 6 year old laptop with (1st generation) 
>> i7 Q720  @1.60GHz takes slightly less than yours:
>>
>>  Sat Oct  3 14:35:40 2015 >>> www-client/firefox-38.3.0
>>merge time: 36 minutes and 53 seconds.
>>
>>  Fri Nov  6 09:10:06 2015 >>> www-client/firefox-38.4.0
>>merge time: 38 minutes and 8 seconds.
>>
>>
>> In contrast a year old AMD A10-7850K APU is significantly faster:
>>
>>  Sat Oct  3 19:40:48 2015 >>> www-client/firefox-38.3.0
>>merge time: 17 minutes and 42 seconds.
>>
>>  Fri Nov  6 08:41:02 2015 >>> www-client/firefox-38.4.0
>>merge time: 18 minutes and 18 seconds.
>>
>>
>> I would also be interested to see compile times of more modern i7s and FXs, 
>> but bear in mind that in single core operations Intel is these days 
>> significantly better than AMD.
>>
> So, I shouldn't prepare for a 8x times faster compile time... :(
> 



I can't help but think you are approaching this from the wrong perspective.

Why exactly are you using compile times as your sole criterion? Are you
building a compile farm for Ubuntu? Running continuous integration tests
for LibreOffice [on a $600 budget in a cardboard box :-) ]?

Or do you want emerge world to get it over with quicker?

If the latter, you better rethink your priorities. In computing terms,
compilation is a rare event; launching apps is a common event; and
writing to the disk happens all the time. Optimize for the common case.

A CPU never works in isolation, it is always part of a much larger
system, like disks, RAM and all possible kinds of I/O. The best CPU on
the market plugged into a POS motherboard will perform on emerge world
like a piece of shit - it will follow the weakest link.

If you want to build a compiling machine, buy the best collection of
stuff that works together well and still fits the budget. If you want a
machine that you can use and be happy with, ignoree the temptation to
must have the biggest baddest fastest CU (you will never get to use all
that big bad fast) and invest rather in gobs of RAM and an SSD. Remember
that apps are launched many times more than they are compiled. Or put
another way, sacrifice compilation times t get something you can use.



-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 02:00 PM, Jeff Smelser wrote:
> 
> I guess from this your assuming that everyones passwords that have been
> hacked are god, birthdays and such?
> 

Again: assume that I'm not an idiot, and that I know how to choose a
long, random password. It cannot be brute-forced. And if it could,
adding an SSH key encrypted with a password of the same length would
provide no extra security.




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Stanislav Nikolov


On 11/10/2015 09:17 PM, Michael Orlitzky wrote:
> On 11/10/2015 02:00 PM, Jeff Smelser wrote:
>> I guess from this your assuming that everyones passwords that have been
>> hacked are god, birthdays and such?
>>
> Again: assume that I'm not an idiot, and that I know how to choose a
> long, random password. It cannot be brute-forced. And if it could,
> adding an SSH key encrypted with a password of the same length would
> provide no extra security.
>
>
Are you sure you know how such keys work? An extremely 15 character password 
(Upper case, lower case, numbers, 8 more symbols) gives you 
~4747561509943000 combinations. Just a simple 2048 bit key on the 
other hand (~180 of which are "secure") 
153249554086558358347027150309183618739122183602176. Thats ALOT moar. You 
don't have to generate the key from a password!



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Stanislav Nikolov


On 11/10/2015 09:31 PM, Michael Orlitzky wrote:
> On 11/10/2015 02:23 PM, Stanislav Nikolov wrote:
>>
>> On 11/10/2015 09:17 PM, Michael Orlitzky wrote:
>>> On 11/10/2015 02:00 PM, Jeff Smelser wrote:
 I guess from this your assuming that everyones passwords that
 have been hacked are god, birthdays and such?

>>> Again: assume that I'm not an idiot, and that I know how to choose
>>> a long, random password. It cannot be brute-forced. And if it
>>> could, adding an SSH key encrypted with a password of the same
>>> length would provide no extra security.
>>>
>>>
>> Are you sure you know how such keys work? An extremely 15 character
>> password (Upper case, lower case, numbers, 8 more symbols) gives you
>> ~4747561509943000 combinations
>
> And since no one seems to believe me, if you could try a million
> passwords a second (over the network!), it would take you about
> 75,272,093,955,210 years to try half of those combinations.
>
>
I know that brute forcing a password is hard. I'm not stating the opposite. But 
brute forcing a 2048 bit key is not 2 times slower, it's 2398748237489237489 
times slower. And you don't need a password for a key! I think that's the right 
time to end this conversation, it won't lead to anything good.



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread wabenbau
Michael Orlitzky  wrote:

> On 11/10/2015 11:13 AM, J. Roeleveld wrote:
> > 
> > What would take longer?
> > brute-forcing your root-password or a 4096 byte ssh key?
> > 
> 
> My password, by a lot. The password needs to be brute-forced over the
> network, first of all.
> 
> And a 4096-bit public encryption key doesn't provide 4096 bits of
> security -- you're thinking of symmetric encryption. Regardless, if
> someone is brute-forcing passwords, it would take them "twice" as long
> to brute-force both my root password and the password on my SSH key as
> it would to do the root password alone. I can do better than 2x by
> adding a character to my password. And that's pointless, because it
> would already take forever. No-more-Earth forever.
> 
> 
> > 
> >> All of the good attacks (shoot me, bribe me, steal the hardware,
> >> etc.) that I can think of work just fine against the two-factor
> >> auth. The only other way to get the root password is to be there
> >> when I transfer it from my brain to the terminal, in which case
> >> you have the SSH key, too.
> > 
> > The ssh-key is stored on your desktop/laptop. Secured with a
> > passphrase.
> > 
> 
> If my machine is compromised, the attacker can see both the SSH key
> password when I type it, and the root password when I type that.

That's right. If an attacker has the full control over your machine
then it doesn't make any difference. 

But if he can only see what you are typing, for example by a keylogger 
or by detecting the electromagentic radiation of your keyboard or by 
watching your keyboard with a camera, then he can do nothing with the 
root password of your server when root login with password is forbidden.

Just my two cents. ;-)

--
Regards
wabe



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 02:32 PM, Stanislav Nikolov wrote:
> 
> 
> On 11/10/2015 09:25 PM, Michael Orlitzky wrote:
>> On 11/10/2015 02:23 PM, Stanislav Nikolov wrote:
>>> Are you sure you know how such keys work? An extremely 15 character
>>> password (Upper case, lower case, numbers, 8 more symbols) gives you
>>> ~4747561509943000 combinations. Just a simple 2048 bit
>>> key on the other hand (~180 of which are "secure")
>>> 153249554086558358347027150309183618739122183602176. Thats ALOT
>>> moar. You don't have to generate the key from a password!
>>>
>> I don't have to brute-force the key. The key is encrypted with a
>> password. How long is that password?
>>
>>
>>
> 1) The key is not encrypted.  
> 2) You don't need a password to generate a key.  
> 3) Don't go full retard, do your research before arguing.
> 

I guess I'll just say that I'm fine with it taking trillions of years to
hack my systems and give up.

Yes, adding another key would make it take longer than trillions of
years. So would increasing the password length.




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 04:11 PM, waben...@gmail.com wrote:
> 
> You can disable password login for that user on the server. Then he 
> can only login via ssh key. Only with the knowledge of the root
> password it is not possible to gain root access to the server. An
> attacker also needs the ssh key. And with a camera, keylogger, or
> measuring radiation he can not fetch that key.
> 

This is pretty close to what I originally asked for, thank you.
If you disable all password logins to the server AND disable remote root
logins altogether, then you can stop someone from gaining root by
peeking over your shoulder as you type.

Unless they bash you over the head and swipe your laptop. But still,
I'll take it.




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Dale
Michael Orlitzky wrote:
> On 11/10/2015 04:11 PM, waben...@gmail.com wrote:
>> You can disable password login for that user on the server. Then he 
>> can only login via ssh key. Only with the knowledge of the root
>> password it is not possible to gain root access to the server. An
>> attacker also needs the ssh key. And with a camera, keylogger, or
>> measuring radiation he can not fetch that key.
>>
> This is pretty close to what I originally asked for, thank you.
> If you disable all password logins to the server AND disable remote root
> logins altogether, then you can stop someone from gaining root by
> peeking over your shoulder as you type.
>
> Unless they bash you over the head and swipe your laptop. But still,
> I'll take it.
>
>
>

Now I'm curious.  Just how often does all this stuff take place?   I
figure when hackers attack, they go straight for root access anyway.  If
that access is disabled then they will never get in, no matter how long
they try.  From what little I know, even if they have the root password
they still can't get in unless they also have the other user account to
login with first. 

Now when hackers get around to hitting folks over the head with a club,
we got problems.  Given I touched my electric fence by accident a while
back, a stun gun would get me to give up quite a lot.  O_O 

Dale

:-)  :-) 



Re: [gentoo-user] Better CPU for compiling with gcc

2015-11-10 Thread Dale
Alan McKinnon wrote:
> On 10/11/2015 21:07, Stanislav Nikolov wrote:
>>
>> 8GB of RAM are waaay more than I use daily (several firefox tabs, nvim = 2Gb 
>> max), I have a pretty fast SSD too. Even buying 8GB RAM and a brand new SSD, 
>> I have > $450 left. Can I buy a AMD CPU that will get the job done faster 
>> than 6700k and/or cheaper?
>>
>
> That changes things. It wasn't obvious you already had RAM & SSD & stuff.
>
> I'd first make sure I have a decent PSU - none of that crap puny
> el-cheapo $300 shit (search list archives for 1000s of posts about dodgy
> PSUs). Then split the difference between 8G RAM, a good CPU and an
> excellent motherboard. You will use that extra RAM, and a motherboard
> that ties all the bits together properly is much more cost-effective
> than raw CPU grunt alone.
>


If he needs a guide to at least increase the odds of getting a good P/S,
this may help.

http://www.jonnyguru.com/modules.php?name=NDReviews=Review_Cat=13


I been reading their reviews for a few years.  They are pretty tough. 
To be honest, if I picked out one that rated 8 on their scale, that
would likely be a good P/S for me.  You get into the 9's and it should
be a really good one.  Short of lightening, it would be the last thing
I'd expect trouble from.  They torture them pretty well.  Should be the
worst a P/S should ever see, example, air conditioner goes out and its
really warm that day.   Also, they take them apart so you can see what
is inside them, good brand of caps for example.  Still, they include the
quality of the build and parts in their scoring.  If a company skimps on
that, they deduct points. 

Honestly tho, the P/S is a critical part.  If it fails, it can wreak all
kinds of havoc.  I've seen P/Ss go out and take a mobo, hard drive or
something else out with it.  After all, pretty much everythign plugs
into power somehow. 

Hope that helps. 

Dale

:-)  :-) 

P. S.  Makes me want to upgrade my CPU to a 8 core now.  I need a hard
drive first tho.  ;-)




Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Jeff Smelser
Again, your not understanding  that brute force is not entirely how you
think it works. As a former employee of a large tech company. They are much
more cunning how they do it these days..

If you wanted to break into an account, would you really start with a and
work your way up?

Come on.

Accounts are broken into all the time and they claimed their passwords were
awesome..

Your not an idiot, you just need to do more research on how hackers get in.

On Tue, Nov 10, 2015 at 12:31 PM, Michael Orlitzky  wrote:

> On 11/10/2015 02:23 PM, Stanislav Nikolov wrote:
> >
> >
> > On 11/10/2015 09:17 PM, Michael Orlitzky wrote:
> >> On 11/10/2015 02:00 PM, Jeff Smelser wrote:
> >>> I guess from this your assuming that everyones passwords that
> >>> have been hacked are god, birthdays and such?
> >>>
> >> Again: assume that I'm not an idiot, and that I know how to choose
> >> a long, random password. It cannot be brute-forced. And if it
> >> could, adding an SSH key encrypted with a password of the same
> >> length would provide no extra security.
> >>
> >>
> > Are you sure you know how such keys work? An extremely 15 character
> > password (Upper case, lower case, numbers, 8 more symbols) gives you
> > ~4747561509943000 combinations
>
>
> And since no one seems to believe me, if you could try a million
> passwords a second (over the network!), it would take you about
> 75,272,093,955,210 years to try half of those combinations.
>
>
>


Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread wabenbau
Michael Orlitzky  wrote:

> On 11/10/2015 03:52 PM, waben...@gmail.com wrote:
> > 
> > That's right. If an attacker has the full control over your machine
> > then it doesn't make any difference. 
> > 
> > But if he can only see what you are typing, for example by a
> > keylogger or by detecting the electromagentic radiation of your
> > keyboard or by watching your keyboard with a camera, then he can do
> > nothing with the root password of your server when root login with
> > password is forbidden.
> > 
> 
> I said I would give up but I lied.
> 
> The scenario that we're talking about has the user log in via an SSH
> key to some server. Once he's logged in to the server, the user uses
> "su" or "sudo" to become root. This requires that he type the root
> password. So a keyboard camera would still obtain the password.
> 
> If you never actually obtain root access, of course you are safe =)

You can disable password login for that user on the server. Then he 
can only login via ssh key. Only with the knowledge of the root
password it is not possible to gain root access to the server. An
attacker also needs the ssh key. And with a camera, keylogger, or
measuring radiation he can not fetch that key.

--
Regards
wabe



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Michael Orlitzky
On 11/10/2015 03:52 PM, waben...@gmail.com wrote:
> 
> That's right. If an attacker has the full control over your machine
> then it doesn't make any difference. 
> 
> But if he can only see what you are typing, for example by a keylogger 
> or by detecting the electromagentic radiation of your keyboard or by 
> watching your keyboard with a camera, then he can do nothing with the 
> root password of your server when root login with password is forbidden.
> 

I said I would give up but I lied.

The scenario that we're talking about has the user log in via an SSH key
to some server. Once he's logged in to the server, the user uses "su" or
"sudo" to become root. This requires that he type the root password. So
a keyboard camera would still obtain the password.

If you never actually obtain root access, of course you are safe =)




Re: [gentoo-user] printing problems

2015-11-10 Thread Frank Steinmetzger
On Mon, Nov 02, 2015 at 05:01:26PM -0800, Daniel Frey wrote:
> On 11/02/2015 04:46 PM, Philip Webb wrote:
> > 151101 Daniel Frey wrote:
> >> I had so many problems with hplip I stopped using it.  I found another way
> >> to use my hp CP1025nw with foomatic and that works trouble-free.
> > 
> > Don't be coy ! -- What did you actually do which works (smile) ?
> > 
> 
> It's a driver for Laserjet printers, it won't work on deskjets AFAIK.
> The driver is foo2zjs: http://foo2zjs.rkkda.com/  - it relies on
> ghostscript.

I used to use foo2zjs happily many a year ago. But then it vanished from
portage and I never got it working again.

> I looked and it looks like that won't help you. I had so many problems
> with hplip randomly stopping working and refusing to reinstall I gave up
> on printing for six months before I found foo2zjs.

What I found out is that the plugin hplip downloads for my laserjet 1000
is a self-extracting archive running on python2, but it does not state a
python version. So if your system python is set to v3, the plugin intall
will fail with only an “I failed” message. Once I switched to python 2, it
ran through. *shrug*

A few days ago I couldn’t get my printer to print more than one page in a
go. It just stops after the first page. Luckily, I have a virtual Ubuntu
which I originally set up just out of curiosity, but now acts as my printing
client, because it just works™.

If I find the time, I will go through the tips of this thread myself.

PS.: The printer is from 2004, and only now the toner, which is the one I
bought with the printer – is getting weaker.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Why do Java developers wear glasses? – Because they don’t C#.


signature.asc
Description: Digital signature


Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Alan Mackenzie
Hello, Jeff.

On Mon, Nov 09, 2015 at 08:26:27PM -0700, Jeff Smelser wrote:
> On Mon, Nov 9, 2015 at 6:38 PM, Michael Orlitzky  wrote:

> > A major upgrade to OpenSSH is being stabilized:

> >   https://bugs.gentoo.org/show_bug.cgi?id=18

> > The default of PermitRootLogin for sshd in the new version is
> > "prohibit-password". If you typically log in to the root account over
> > SSH using a password, **IT'S GONNA BREAK**, and you won't be able to fix
> > it remotely unless you have an account that can sudo to root.

> > To maintain the current behavior, set PermitRootLogin to "yes" before
> > you upgrade, and then be careful not to wipe out sshd_config.



> The question is, why would you want root login? If your still using it,
> your doing it wrong.

You might have just booted up a bare machine with the Gentoo install CD,
and you're using ssh to issue the installation commands from a more
comfortable fully installed machine.

By the way, anybody, what's the alternative to a password login when you
need to login remotely as root?

-- 
Alan Mackenzie (Nuremberg, Germany).



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Neil Bothwick
On Tue, 10 Nov 2015 09:53:52 +, Alan Mackenzie wrote:

> By the way, anybody, what's the alternative to a password login when you
> need to login remotely as root?

key login, set "PermitRootLogin without-password" and add your public
keys to .ssh/authorized_keys


-- 
Neil Bothwick

WINDOWS: Will Install Needless Data On Whole System


pgp_U2Q4OiymA.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Alan McKinnon

On 10/11/2015 11:53, Alan Mackenzie wrote:

Hello, Jeff.

On Mon, Nov 09, 2015 at 08:26:27PM -0700, Jeff Smelser wrote:

On Mon, Nov 9, 2015 at 6:38 PM, Michael Orlitzky  wrote:



A major upgrade to OpenSSH is being stabilized:



   https://bugs.gentoo.org/show_bug.cgi?id=18



The default of PermitRootLogin for sshd in the new version is
"prohibit-password". If you typically log in to the root account over
SSH using a password, **IT'S GONNA BREAK**, and you won't be able to fix
it remotely unless you have an account that can sudo to root.



To maintain the current behavior, set PermitRootLogin to "yes" before
you upgrade, and then be careful not to wipe out sshd_config.





The question is, why would you want root login? If your still using it,
your doing it wrong.


You might have just booted up a bare machine with the Gentoo install CD,
and you're using ssh to issue the installation commands from a more
comfortable fully installed machine.

By the way, anybody, what's the alternative to a password login when you
need to login remotely as root?



ssh keys



Re: [gentoo-user] bring back emerge to terminal window

2015-11-10 Thread Mick
On Wednesday 11 Nov 2015 06:47:00 Alon Bar-Lev wrote:
> Checkout app-misc/reptyr
> 

Also consider emerging within screen or tmux, so that you can re-attach the 
terminal from any machine.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


[gentoo-user] can't login

2015-11-10 Thread Ran Shalit
Hello,

After doing a reset, I can't login.
on trying to enter password I get for a second a screen which
"This is gentoo unkown_domain", and then it get back to the login screen.
I login using tty (alt_ctrl+f1) and changed the user password, but on
trying to login again in the graphic logic, it keep the same
behaviour.


Please help,

Regards,
Ran



[gentoo-user] bring back emerge to terminal window

2015-11-10 Thread thelma
I was running and emerge -uDNavq world and accidentally closed the terminal 
window.  
I know the process ID as it is still running.

 ps fax |grep emerge
-- 19131 pts/1 SN+ 4:03 | | \_ /usr/bin/python3.4 -b 
/usr/lib/python-exec/python3.4/emerge -uDNavq world

Is there a way to ring it back to a terminal window?

--
Thelma



Re: [gentoo-user] bring back emerge to terminal window

2015-11-10 Thread Alon Bar-Lev
Checkout app-misc/reptyr

On 11 November 2015 at 08:38,  wrote:

> I was running and emerge -uDNavq world and accidentally closed the
> terminal window.
> I know the process ID as it is still running.
>
>  ps fax |grep emerge
> -- 19131 pts/1 SN+ 4:03 | | \_ /usr/bin/python3.4 -b
> /usr/lib/python-exec/python3.4/emerge -uDNavq world
>
> Is there a way to ring it back to a terminal window?
>
> --
> Thelma
>
>


Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread wabenbau
Dale  wrote:

> Michael Orlitzky wrote:
> > On 11/10/2015 04:11 PM, waben...@gmail.com wrote:
> >> You can disable password login for that user on the server. Then
> >> he can only login via ssh key. Only with the knowledge of the root
> >> password it is not possible to gain root access to the server. An
> >> attacker also needs the ssh key. And with a camera, keylogger, or
> >> measuring radiation he can not fetch that key.
> >>
> > This is pretty close to what I originally asked for, thank you.
> > If you disable all password logins to the server AND disable remote
> > root logins altogether, then you can stop someone from gaining root
> > by peeking over your shoulder as you type.
> >
> > Unless they bash you over the head and swipe your laptop. But still,
> > I'll take it.
> >
> >
> >
> 
> Now I'm curious.  Just how often does all this stuff take place?   I
> figure when hackers attack, they go straight for root access anyway.
> If that access is disabled then they will never get in, no matter how
> long they try.  From what little I know, even if they have the root
> password they still can't get in unless they also have the other user
> account to login with first. 

A server is called is called a server because it has has something to
serve. ;-) If these services (web, ftp, mail, file or whatever else) 
are  accessible through a public network (Internet, Intranet, WLAN) 
then attackers are are looking for vulnerabilities in these services.
Often they use exploit-kits like blackhole for that. If they find a
vulnerability, they trying to exploit it. If the attackers are 
successful or not, depends also on how good the server is hardened, 
that means how good it is protected against such vulnerable services.

There are different mechanisms for such protections. For example 
simple chroot()jails or, much more complex, access control systems
like apparmor and selinux for isolating services, and SSP and PAX for
protection against stack- and bufferoverflow based exploits.

--
Regards
wabe



Re: [gentoo-user] OpenSSH upgrade warning

2015-11-10 Thread Walter Dnes
On Mon, Nov 09, 2015 at 08:38:20PM -0500, Michael Orlitzky wrote
> A major upgrade to OpenSSH is being stabilized:
> 
>   https://bugs.gentoo.org/show_bug.cgi?id=18
> 
> The default of PermitRootLogin for sshd in the new version is
> "prohibit-password". If you typically log in to the root account over
> SSH using a password, **IT'S GONNA BREAK**, and you won't be able to fix
> it remotely unless you have an account that can sudo to root.
> 
> To maintain the current behavior, set PermitRootLogin to "yes" before
> you upgrade, and then be careful not to wipe out sshd_config.

  Thanks for the info.  I'd doing an install on a machine at home, and I
ran into that.  Since I hadn't yet created a local user, there was
nowhere to sudo from.  Fortunately, it's all in one room, and a few
clicks of the KVM remote-switcher brought me to the actual machine,
where I could log in directly.  I now have my key on the installed
machine and can ssh in from my current machine.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications



Re: [gentoo-user] Bind stole my /

2015-11-10 Thread Tom H
On Tue, Nov 10, 2015 at 12:32 AM, Mike Gilbert  wrote:
> On Mon, Nov 9, 2015 at 2:36 PM, Jarry  wrote:
>> On 08-Nov-15 17:58, Mike Gilbert wrote:
>>> On Fri, Nov 6, 2015 at 12:19 PM, Jarry  wrote:

 I noted one strange thing today: It seems one of my servers lost "/"!

 vs5-dns ~ # df
 Filesystem1K-blocksUsed Available Use% Mounted on
 /var/log/named 10138552 2223148   7377344  24% /chroot/dns/var/log/named
 tmpfs308196 420307776   1% /run
 dev   10240   0 10240   0% /dev
 shm 1540968   0   1540968   0% /dev/shm
 cgroup_root   10240   0 10240   0% /sys/fs/cgroup
 none1048576   0   1048576   0% /var/tmp/portage
>>>
>>> Is your /etc/mtab a regular file, or is it a symlink to
>>> /proc/self/mounts? The latter is recommended.
>>
>> It is regular file. I never changed it...
>>
>> vs5-dns ~ # ls -l /etc/mtab
>> -rw-r--r-- 1 root root 908 Nov  9 19:14 /etc/mtab
>>
>>> Anyway, please have a look at the contents of /etc/mtab,
>>> /proc/self/mounts, and proc/self/mountinfo while named is running and
>>> when it is stopped. If you pastebin them we can take a look for key
>>> differences.
>>
>> With bind running:
>> http://pastebin.com/wkTW6xAY
>>
>> without bind:
>> http://pastebin.com/JG5FPNDW
>>
>> While I can see some differences there, I still do not understand
>> why is "/" missing in "df" output. BTW I can not proove it, but this
>> was not the case all the time. At least when I was tuning monitoring
>> software, I'm pretty sure "/" was there...
>
> It may be a bug.
>
> Can you try replacing /etc/mtab with a symlink to /proc/self/mounts to
> see if it makes any difference? That triggers different code paths in
> several programs.

>From the OP's pastebin:

vs5-dns ~ # more /etc/mtab
/dev/sda2 / ext4 rw,noatime,data=ordered 0 0
/etc/bind /chroot/dns/etc/bind none rw,bind 0 0
/var/bind /chroot/dns/var/bind none rw,bind 0 0
/var/log/named /chroot/dns/var/log/named none rw,bind 0 0

vs5-dns ~ # more /proc/self/mounts
/dev/sda2 / ext4 rw,noatime,data=ordered 0 0
/dev/sda2 /chroot/dns/etc/bind ext4 rw,noatime,data=ordered 0 0
/dev/sda2 /chroot/dns/var/bind ext4 rw,noatime,data=ordered 0 0
/dev/sda2 /chroot/dns/var/log/named ext4 rw,noatime,data=ordered 0 0

There was a blog post a few years ago by the util-linux maintainer in
which he was pushing for users to symlink "/etc/mtab" to
"/proc/self/mounts" and he was explaining that having "bind" as a
property in mtab doesn't make sense because you could unmount the
"bound-to" mount and the "bound" mount would still show "bind" as a
property.

Is "/" shown when you run "df -a"? If it's shown, then there's a bug
in coreutils (as long as they accept a bug on a system where mtab
isn't a symlink) because, AFAIR, "df" should show the mount with the
shortest mount path if a filesystem's mounted more than once.



[gentoo-user] reading data cd/dvd

2015-11-10 Thread allan gottlieb
All my machines run gentoo / systemd / gnome3

On my older laptop when I plug in a data cd I get a popup suggesting
that I open it with files.  All is well

On my newer laptop the disk spins up but no popup appears.
What must I configure?

On the old machine there is a directory /run/media/ with a subdirectory
gottlieb.  The data cd is mounted there.  Looking at df gives
/dev/sr0286490   286490  0 100% /run/media/gottlieb/COD3E

The new machine does not even have /dev/sr0.

Am I missing a kernel option

I have the following in scsi device support.

  < > RAID Transport Class 
  -*- SCSI device support  
  [ ] SCSI: use blk-mq I/O path by default 
  [*] legacy /proc/scsi/ support   
  *** SCSI support type (disk, tape, CD-ROM) ***   
  <*> SCSI disk support
  < > SCSI tape support
  < > SCSI OnStream SC-x0 tape support 
  <*> SCSI CDROM support   
  [*]   Enable vendor-specific extensions (for SCSI CDROM) 
  <*> SCSI generic support 
  < > SCSI media changer support   
  [*] Verbose SCSI error reporting (kernel size +=12K) 
  [ ] SCSI logging facility
  [ ] Asynchronous SCSI scanning   
  SCSI Transports  --->
  [ ] SCSI low-level drivers   
  [ ] PCMCIA SCSI adapter support  
  < > SCSI Device Handlers     
  < > OSD-Initiator library

Thanks in advance for any help.
allan