Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The little ssh that (sometimes) couldn't

mina.naguib.ca

Post reply on HN
Print view View original

41–50 of 66 posts

Re: The little ssh that (sometimes) couldn't

#41

Post by ComputerGuru »

18pfsmt wrote: post #33
ComputerGuru wrote: post #26

Off-topic: can someone provide a good reason why SSH w/ the HPN patches is not the default for every SSH install on every platform? Today, people are relying on SSH for binary transfer more than ever. SFTP and SCP are the new defacto file transfer standards between machine to machine over a secured connection. Source control like GIT (or even SVN) make heavy use of binary transfers over SSH. The performance benefit t…

I have to admit I felt pretty ignorant for not knowing what you were talking about. So, for anyone else in a similar situation: http://www.psc.edu/index.php/hpn-ssh

Don't. It's a very esoteric topic. Hence my frustration - I wish it weren't so!

Re: The little ssh that (sometimes) couldn't

#42

Post by dfc »

ComputerGuru wrote: post #40
dfc wrote: post #39

Earlier quoted context omitted.

The none cipher switch was always a turn off for a lot of people.

iirc, it's off by default? Even when enabled, it'll only not encrypt binary blobs; TTY input will remain encrypted. Obviously many times that is not an option, but sometimes it is.

So you are not worried about the confidentiality of your data?

Leaving aside the crypto worries and concerns over why it was not merged upstream can you imagine being the Debian package maintainer? Having to manage and triage bug reports with two upstreams? And then having to keep track of whether the bug occurred when HPN initiated a connection to pristine upstream, pristine connects to HPN or HPN connects to HPN? If you want to get an idea of the headache involved site:debian.org ssh hpn.

Have you read why upstream never merged it? The pleas for funding and lack of maintainer time do not give you cause for concern?

Re: The little ssh that (sometimes) couldn't

#43

Post by derleth »

js2 wrote: post #10

This is insane. The closest scenarios to this I've seen in my career: 1) A private frame relay network that one day stopped passing packets over a certain size. Worked around by lowering the MTU at both ends till I was able to convince the frame relay provider that yes, the problem was in their network. This was relatively straight-forward to diagnose, but it was still odd being able to ssh into a box, then have the…

> someone had deleted its own MAC address from its ARP table

blink

Two questions:

- Is there ever a valid reason to do this?

- How do you attain the skills required to do this while not also learning not to?

Re: The little ssh that (sometimes) couldn't

#44

Post by cnvogel »

derleth wrote: post #43
js2 wrote: post #10

This is insane. The closest scenarios to this I've seen in my career: 1) A private frame relay network that one day stopped passing packets over a certain size. Worked around by lowering the MTU at both ends till I was able to convince the frame relay provider that yes, the problem was in their network. This was relatively straight-forward to diagnose, but it was still odd being able to ssh into a box, then have the…

> someone had deleted its own MAC address from its ARP table blink Two questions: - Is there ever a valid reason to do this? - How do you attain the skills required to do this while not also learning not to?

So, I was working at a very small internet service provider in a rural area in the mid-nineties. For the lack of affordable hardware, we were using Linux machines for routing, and a lot of "unconventional" solutions were necessary due to insufficient hardware being used. Tunelling, and other virtual interfaces of any kind were used often.

I remember one particular case were we running both routed IP and bridged ethernet over a single frame-relay link, and there we had to resort to fixed ethernet-to-ip mapping (turning off ARP) on the bridged link for some reason I really can no longer remember.

Re: The little ssh that (sometimes) couldn't

#47

Post by chuppo »

This kind of packet corruption probably happens more often than we like to think intentionally, I know at least one country whos ISPs all corrupt and drop random packets, just to make internet-usage an infuriating experience. It works, the people are held away from it, and dont see internet as anything but a bad toy. Id would be really surprising other states hadnt thought of similar techniques.

Re: The little ssh that (sometimes) couldn't

#48

Post by drcross »

derleth wrote: post #43
js2 wrote: post #10

This is insane. The closest scenarios to this I've seen in my career: 1) A private frame relay network that one day stopped passing packets over a certain size. Worked around by lowering the MTU at both ends till I was able to convince the frame relay provider that yes, the problem was in their network. This was relatively straight-forward to diagnose, but it was still odd being able to ssh into a box, then have the…

> someone had deleted its own MAC address from its ARP table blink Two questions: - Is there ever a valid reason to do this? - How do you attain the skills required to do this while not also learning not to?

"First hop redundancy" such as HSRP, VRRP and GLBP use similar techniques to load balance and redundancy. This could be a reason for it's use.

Re: The little ssh that (sometimes) couldn't

#49

Post by qznc »

qznc wrote: post #22
swordswinger12 wrote: post #6

I love reading weird bug stories like this. Is there a place where lots of these types of stories are aggregated? Maybe a book about them?

Here are two more: http://news.ycombinator.com/item?id=1293849 http://catb.org/jargon/html/magic-story.html

And even more:

http://netlib.bell-labs.com/cm/cs/pearls/sec0510.html

http://discovermagazine.com/2012/jul-aug/06-vital-signs-woma...

Re: The little ssh that (sometimes) couldn't

#50

Post by peteretep »

derleth wrote: post #43
js2 wrote: post #10

This is insane. The closest scenarios to this I've seen in my career: 1) A private frame relay network that one day stopped passing packets over a certain size. Worked around by lowering the MTU at both ends till I was able to convince the frame relay provider that yes, the problem was in their network. This was relatively straight-forward to diagnose, but it was still odd being able to ssh into a box, then have the…

> someone had deleted its own MAC address from its ARP table blink Two questions: - Is there ever a valid reason to do this? - How do you attain the skills required to do this while not also learning not to?

> How do you attain the skills required to do this while not also learning not to

Half-understood StackOverflow answers, natch.

Post reply on HN