On 1/12/2015 3:23 AM, Brooks Davis wrote:
On Tue, Nov 24, 2015 at 09:29:44PM +0100, Aaron Zauner wrote:
Hi,
Please forgive my ignorance but what's the reason FreeBSD ships
OpenSSH patched with HPN by default? Besides my passion for
security, I've been working in the HPC sector for a while and
b
On Tue, Nov 24, 2015 at 09:29:44PM +0100, Aaron Zauner wrote:
> Hi,
>
> Please forgive my ignorance but what's the reason FreeBSD ships
> OpenSSH patched with HPN by default? Besides my passion for
> security, I've been working in the HPC sector for a while and
> benchmarked the patch for a custom
Hi,
Please forgive my ignorance but what's the reason FreeBSD ships
OpenSSH patched with HPN by default? Besides my passion for
security, I've been working in the HPC sector for a while and
benchmarked the patch for a customer about 1.5 years ago. The
CTR-multi threading patch is actually *slower*
Benjamin Kaduk writes:
> Things seem to have slowed down a lot since the lead Heimdal developer
> got hired for Apple. [...] MIT employs developers whose job
> descriptions include being the krb5 release manager [...] Heimdal has
> changed plans to a 1.7 release [...] and since the developers i
On 11/12/15 5:32 AM, Bryan Drewery wrote:
On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote:
I would also like to remove the NONE cipher
patch, which is also available in the port (off by default, just like in
base).
Fun fact, it's been broken in the port for several months with no
complaints.
On 11/12/15 3:28 AM, Brooks Davis wrote:
On Tue, Nov 10, 2015 at 04:40:42PM -0800, Bryan Drewery wrote:
On 11/10/15 1:42 AM, Dag-Erling Sm??rgrav wrote:
Some of you may have noticed that OpenSSH in base is lagging far behind
the upstream code.
The main reason for this is the burden of maintain
On Thu, 12 Nov 2015, Dewayne Geraghty wrote:
> Heimdal is (and has been for some time) undergoing constant development.
> For reasons unknown, they do not perform releases. I am aware of updates
> from heimdal that are being applied to the samba project (in fact some of
> the samba developers are
Slawa,
Heimdal is (and has been for some time) undergoing constant development.
For reasons unknown, they do not perform releases. I am aware of updates
from heimdal that are being applied to the samba project (in fact some of
the samba developers are also feeding into heimdal). The latest discus
Bryan Drewery writes:
> It's harder to maintain the port version due to how the patches are
> applied and generated.
I have the diametrically opposite experience. The workflow for ports is
significantly simpler than for base. Perhaps I should set up a paralell
workflow for OpenSSH and apply the
Trustworthy networks do exist. They just aren't the same networks as 20
years ago.
They do of course but is that really relevant considering how rare
verifyably trustworthy networks are, particularly in light of what we
know about NONE cipher usage?
The same logic applies to SCTP. It is little
Oh just the opposite of what you're claiming. Did you even read the article
about the Beyond Corp project? It is 100% about thinking very hard about
trust and making sure that the trust model used doesn't depend on the
concept of internal/external network.
Also, the type of thinking where two or m
On 11/11/2015 3:56 PM, Slawa Olhovchenkov wrote:
> On Wed, Nov 11, 2015 at 10:18:08AM -0800, Bryan Drewery wrote:
>
>> On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote:
>>> On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
>>>
Bryan Drewery writes:
> Another thing that
On 11/11/15 4:05 PM, Slawa Olhovchenkov wrote:
> On Wed, Nov 11, 2015 at 03:58:35PM -0800, Bryan Drewery wrote:
>
>>> Some for as ports version?
>>> Or ports version different?
>>> Or port mantainer have more time (this is not to blame for DES)?
>>> I am just don't know what is different between p
On Wed, Nov 11, 2015 at 01:32:27PM -0800, Bryan Drewery wrote:
> On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote:
> > I would also like to remove the NONE cipher
> > patch, which is also available in the port (off by default, just like in
> > base).
>
> Fun fact, it's been broken in the port fo
On Wed, Nov 11, 2015 at 03:58:35PM -0800, Bryan Drewery wrote:
> > Some for as ports version?
> > Or ports version different?
> > Or port mantainer have more time (this is not to blame for DES)?
> > I am just don't know what is different between port ssh and base ssh.
> > We need ssh 6.x in base,
On Wed, Nov 11, 2015 at 10:18:08AM -0800, Bryan Drewery wrote:
> On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote:
> > On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
> >
> >> Bryan Drewery writes:
> >>> Another thing that I did with the port was restore the tcpwrapper
> >>>
On Wed, Nov 11, 2015 at 4:29 PM, Robert Simmons wrote:
> I don't think there is such a thing as a trusted network. That is a unicorn
> these days.
>
> No networks should be considered trusted.
>
oh baloney. That's just a clever way to say you want to stop thinking about
trust.
If I've connected
On Wed, 11 Nov 2015, Daniel Kalchev wrote:
>
> Perhaps similar level of security could be achieved by “the old tools”
> if they were by default compiled with Kerberos. Although, this still
> requires building additional infrastructure.
The kerberized versions of the old tools are basically unsupp
I don't think there is such a thing as a trusted network. That is a unicorn
these days.
If you are using ssh to connect to the VPN server itself over the VPN
connection, I can see why that would be useless double encryption. However,
if you are connecting to a server on the network on the other si
On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote:
> I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).
Fun fact, it's been broken in the port for several months with no
complaints. It was just reported and fixed upstream
On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote:
> On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
>
>> Bryan Drewery writes:
>>> Another thing that I did with the port was restore the tcpwrapper
>>> support that upstream removed. Again, if we decide it is not worth
>>> keep
On Tue, Nov 10, 2015 at 04:40:42PM -0800, Bryan Drewery wrote:
> On 11/10/15 1:42 AM, Dag-Erling Sm??rgrav wrote:
> > Some of you may have noticed that OpenSSH in base is lagging far behind
> > the upstream code.
> >
> > The main reason for this is the burden of maintaining the HPN patches.
> > Th
Ben Woods wrote this message on Wed, Nov 11, 2015 at 16:27 +0800:
> On Wednesday, 11 November 2015, John-Mark Gurney wrote:
>
> > Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > > I have to agree that there are cases when the NONE cipher makes sense,
> > and
> > > it is up t
Daniel Kalchev wrote this message on Wed, Nov 11, 2015 at 17:49 +0200:
> It is my understanding, that using the NONE cypher is not identical to using
> ???the old tools??? (rsh/rlogin/rcp).
>
> When ssh uses the NONE cypher, credentials and authorization are still
> encrypted and verified. Only
On Wed, Nov 11, 2015 at 07:18:31PM +0100, Dag-Erling Smørgrav wrote:
> Slawa Olhovchenkov writes:
> > Can you explain what is problem?
>
> Radical suggestion: read the first email in the thread.
I am read and don't understund (you talk about trouble of maintaining
the HPN patches).
I see patche
Slawa Olhovchenkov writes:
> Can you explain what is problem?
Radical suggestion: read the first email in the thread.
> PS: As I today know, kerberos heimdal is practicaly dead as opensource
> project. Have FreeBSD planed switch to MIT Kerberos? I am know about
> security/krb5.
We switched fro
On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
> Bryan Drewery writes:
> > Another thing that I did with the port was restore the tcpwrapper
> > support that upstream removed. Again, if we decide it is not worth
> > keeping in base I will remove it as default in the port.
>
On Wed, 11 Nov 2015, Dag-Erling Sm?rgrav wrote:
I want to keep tcpwrapper support - it is another reason why I still
haven't upgraded OpenSSH, but to the best of my knowledge, it is far
less intrusive than HPN.
There's also inetd's tcpwrapper support if you call sshd from inetd for
D/DOS protec
On 11/11/2015 7:49 AM, Daniel Kalchev wrote:
> It is my understanding, that using the NONE cypher is not identical to using
> “the old tools” (rsh/rlogin/rcp).
>
> When ssh uses the NONE cypher, credentials and authorization are still
> encrypted and verified. Only the actual data payload is not
It is my understanding, that using the NONE cypher is not identical to using
“the old tools” (rsh/rlogin/rcp).
When ssh uses the NONE cypher, credentials and authorization are still
encrypted and verified. Only the actual data payload is not encrypted.
Perhaps similar level of security could be
On 11/10/2015 3:48 AM, Dag-Erling Smørgrav wrote:
> Willem Jan Withagen writes:
>> "Dag-Erling Smørgrav" writes:
>>> Willem Jan Withagen writes:
Are they still willing to accept changes to the old version that
is currently in base?
>>> No, why would they do that?
>> Exactly my question
On 11/11/2015 8:51 AM, Dag-Erling Smørgrav wrote:
> Bryan Drewery writes:
>> Another thing that I did with the port was restore the tcpwrapper
>> support that upstream removed. Again, if we decide it is not worth
>> keeping in base I will remove it as default in the port.
>
> I want to keep tcpwr
On 11/11/2015 1:23 AM, Dag-Erling Smørgrav wrote:
> Bryan Drewery writes:
>> Actually I am missing the client-side VersionAddendum support (ssh.c). I
>> only have server-side (sshd.c). This is just due to lack of motivation
>> to import the changes.
>
> Pretty sure I sent Damien the patch a few
On 11/11/2015 1:04 AM, Dag-Erling Smørgrav wrote:
> Ben Woods writes:
>> Personally I have used it at home to backup my old FreeBSD server
>> (which does not have AESNI) over a dedicated network connection to a
>> backup server using rsync/ssh. Since it was not possible for anyone
>> else to be on
> On 11 Nov 2015, at 16:53 , Bryan Drewery wrote:
>
> On 11/11/2015 8:51 AM, Dag-Erling Smørgrav wrote:
>> Bryan Drewery writes:
>>> Another thing that I did with the port was restore the tcpwrapper
>>> support that upstream removed. Again, if we decide it is not worth
>>> keeping in base I wil
Bryan Drewery writes:
> Another thing that I did with the port was restore the tcpwrapper
> support that upstream removed. Again, if we decide it is not worth
> keeping in base I will remove it as default in the port.
I want to keep tcpwrapper support - it is another reason why I still
haven't up
Daniel Kalchev writes:
> I must have missed the explanation. But why having a NONE cypher
> compiled in, but disabled in the configuration is a bad idea?
It increases the cost of maintaining OpenSSH in base noticeably without
providing real value unless you are one of the few people who need HPN
Julian Elischer writes:
> Now we'll have to resurrect all that framework and pain.
I guess pain is fine as long as it's not yours...
> have you mentioned this plan to Brooks? Didn't he add it?
These are public lists, but by all means, mention it to him if he hasn't
noticed this thread.
DES
--
On 11/11/15 7:56 PM, Dag-Erling Smørgrav wrote:
Julian Elischer writes:
The inclusion of the HPN patches meant that we could drop a custom
unsupported HPN enabled ssh from our build process. It makes ssh
actually usable.
Define "usable". Does it actually make a measurable difference with the
Julian Elischer writes:
> Bob Bishop writes:
> > Is removing HPN going to impact the performance of tunnelled X
> > connexions?
> yes if your rtt is greater than about 85 mSec
With an RTT of 85 ms, X is unusable with or without HPN.
DES
--
Dag-Erling Smørgrav - d...@des.no
On Tue, Nov 10, 2015 at 11:59:30PM -0800, John-Mark Gurney wrote:
> Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > On Wednesday, 11 November 2015, Bryan Drewery wrote:
> >
> > > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > > My vote is to remove the HPN patches. Fir
On Tue, Nov 10, 2015 at 09:52:16AM -0800, John-Mark Gurney wrote:
> Dag-Erling Smrgrav wrote this message on Tue, Nov 10, 2015 at 10:42 +0100:
> > Therefore, I would like to remove the HPN patches from base and refer
> > anyone who really needs them to the openssh-portable port, which has
> > them
On Wednesday, 11 November 2015, Bryan Drewery wrote:
> On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > My vote is to remove the HPN patches. First, the NONE cipher made more
> > sense back when we didn't have AES-NI widely available, and you were
> > seriously limited by it's performance. Now
On Wednesday, 11 November 2015, John-Mark Gurney wrote:
> Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > I have to agree that there are cases when the NONE cipher makes sense,
> and
> > it is up to the end user to make sure they know what they are doing.
> >
> > Personally
On Wed, Nov 11, 2015 at 6:59 PM, John-Mark Gurney wrote:
> If you have a trusted network, why not just use nc?
Perhaps more generally relevant is that ssh/scp are *waves hands* vaguely
analogous to secure versions of rsh/rlogin/rcp. I'd think that most cases
of "I wanted to send files and invoke
Julian Elischer writes:
> The inclusion of the HPN patches meant that we could drop a custom
> unsupported HPN enabled ssh from our build process. It makes ssh
> actually usable.
Define "usable". Does it actually make a measurable difference with the
latest OpenSSH? And if HPN is so important
On 11/10/15 7:16 PM, Dag-Erling Smørgrav wrote:
Bob Bishop writes:
Is removing HPN going to impact the performance of tunnelled X
connexions?
yes if your rtt is greater than about 85 mSec
I don't know he details but I noticed a big difference.
I had thought X wouldn't show much difference but
On 11/10/15 5:42 PM, Dag-Erling Smørgrav wrote:
Some of you may have noticed that OpenSSH in base is lagging far behind
the upstream code.
The main reason for this is the burden of maintaining the HPN patches.
They are extensive, very intrusive, and touch parts of the OpenSSH code
that change si
Bryan Drewery writes:
> Actually I am missing the client-side VersionAddendum support (ssh.c). I
> only have server-side (sshd.c). This is just due to lack of motivation
> to import the changes.
Pretty sure I sent Damien the patch a few years ago... There was also a
bug in the server-side code
Ben Woods writes:
> Personally I have used it at home to backup my old FreeBSD server
> (which does not have AESNI) over a dedicated network connection to a
> backup server using rsync/ssh. Since it was not possible for anyone
> else to be on that local network, and the server was so old it didn't
On Tue, Nov 10, 2015 at 11:59 PM, John-Mark Gurney wrote:
>
>
>
> If you have a trusted network, why not just use nc?
Defense in depth for starters.
The ipfw how to guide I learned from years ago, started with the
statement that a
firewall should be a shield in front of machines that don't nee
Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> On Wednesday, 11 November 2015, Bryan Drewery wrote:
>
> > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > My vote is to remove the HPN patches. First, the NONE cipher made more
> > > sense back when we didn't have AES-NI wid
On 11/10/15 4:40 PM, Bryan Drewery wrote:
> Anyway, reverting the base SSH to stock, and then importing all patches
> from the ports default version should result in the same base patches
> applied and a working HPN.
Actually I am missing the client-side VersionAddendum support (ssh.c). I
only hav
On 11/10/15 1:42 AM, Dag-Erling Smørgrav wrote:
> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> that
On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> My vote is to remove the HPN patches. First, the NONE cipher made more
> sense back when we didn't have AES-NI widely available, and you were
> seriously limited by it's performance. Now we have both aes-gcm and
> chacha-poly which it's performance s
On 11/10/15 3:07 AM, Willem Jan Withagen wrote:
> Which when I found out that upstreaming patches from base will be hard,
> because the whole logging in the ports version is totally different.
No it's not. The HPN patch in the ports version had *extra logging* for
a while but that is not the case
Bryan Drewery wrote this message on Tue, Nov 10, 2015 at 16:32 -0800:
> On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > My vote is to remove the HPN patches. First, the NONE cipher made more
> > sense back when we didn't have AES-NI widely available, and you were
> > seriously limited by it's per
On 11/10/15 1:42 AM, Dag-Erling Smørgrav wrote:
Some of you may have noticed that OpenSSH in base is lagging far behind
the upstream code.
The main reason for this is the burden of maintaining the HPN patches.
They are extensive, very intrusive, and touch parts of the OpenSSH code
that change si
Dag-Erling Smrgrav wrote this message on Tue, Nov 10, 2015 at 10:42 +0100:
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch,
Mark Felder wrote on 11/10/2015 17:02:
[...]
But like I said: The code I found at openssh was so totally different
that I did not continued this track, but chose to start running openssh
from ports. Which does not generate warnings I have questions about the
originating ip-nr.
Are they still
On Tue, Nov 10, 2015, at 05:25, Willem Jan Withagen wrote:
> On 10-11-2015 12:11, Dag-Erling Smørgrav wrote:
> > Willem Jan Withagen writes:
> >> Digging in my logfiles , and its things like:
> >> sshd[84942]: Disconnecting: Too many authentication failures [preauth]
> >>
> >> So errors/w
On Tue, Nov 10, 2015 at 10:42:49AM +0100, Dag-Erling Smørgrav wrote:
> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of t
Willem Jan Withagen writes:
> "Dag-Erling Smørgrav" writes:
> > Willem Jan Withagen writes:
> > > Are they still willing to accept changes to the old version that
> > > is currently in base?
> > No, why would they do that?
> Exactly my question I guess I misinterpreted your suggestion on
>
On 10-11-2015 12:11, Dag-Erling Smørgrav wrote:
Willem Jan Withagen writes:
Digging in my logfiles , and its things like:
sshd[84942]: Disconnecting: Too many authentication failures [preauth]
So errors/warnings without IP-nr.
And I think I fixed it on one server to also write:
error:
Bob Bishop writes:
> Is removing HPN going to impact the performance of tunnelled X
> connexions?
I don't think so. It mostly affects the performance of long
unidirectional streams (file transfers) whereas the X protocol, as far
as I know, is a bidirectional exchange of relatively short messages
Willem Jan Withagen writes:
> Digging in my logfiles , and its things like:
> sshd[84942]: Disconnecting: Too many authentication failures [preauth]
>
> So errors/warnings without IP-nr.
>
> And I think I fixed it on one server to also write:
> error: maximum authentication attempts exceeded
On 10-11-2015 11:55, Dag-Erling Smørgrav wrote:
> Willem Jan Withagen writes:
>> I know I've installed the ports once to see if, and how I would be
>> able to add more IP-address infor to some of the warnings and
>> errors. And then to get thos errors recognised by tools like sshguard
>> and fail
Hi,
> On 10 Nov 2015, at 09:42, Dag-Erling Smørgrav wrote:
>
> […]
>
> Therefore, I would like to remove the HPN patches from base and refer
> anyone who really needs them to the openssh-portable port, which has
> them as a default option. I would also like to remove the NONE cipher
> patch, w
Willem Jan Withagen writes:
> I know I've installed the ports once to see if, and how I would be
> able to add more IP-address infor to some of the warnings and
> errors. And then to get thos errors recognised by tools like sshguard
> and fail2ban.
Do you mean logging IP addresses instead of host
On 10-11-2015 10:42, Dag-Erling Smørgrav wrote:
Some of you may have noticed that OpenSSH in base is lagging far behind
the upstream code.
The main reason for this is the burden of maintaining the HPN patches.
They are extensive, very intrusive, and touch parts of the OpenSSH code
that change si
On 10/11/2015 8:42 PM, Dag-Erling Smørgrav wrote:
> Some of you may have noticed that OpenSSH in base is lagging far behind
> the upstream code.
>
> The main reason for this is the burden of maintaining the HPN patches.
> They are extensive, very intrusive, and touch parts of the OpenSSH code
> th
Some of you may have noticed that OpenSSH in base is lagging far behind
the upstream code.
The main reason for this is the burden of maintaining the HPN patches.
They are extensive, very intrusive, and touch parts of the OpenSSH code
that change significantly in every release. Since they are not
72 matches
Mail list logo
