Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mosh: Modernizing SSH With IP Roaming, Instant Local Echo

Unknown Lamer posted more than 2 years ago | from the udp-reunion-tour dept.

Unix 158

An anonymous reader writes "Launched in 1995, SSH quickly became the king of network login tools, supplanting the old insecure mainstays TELNET and RLOGIN. But 17 years later, a group of MIT hackers have come out with "mosh", which claims to modernize the most annoying parts of SSH. Mosh keeps its connection alive when clients roam among WiFi networks or switch to 3G, and gives instant feedback on typing (and deleting). No more annoying network lag on typing, the MIT boffins say, citing Bufferbloat, which has been increasing latencies." The folks involved have a pre-press research paper with the gritty details (to be presented at USENIX later this year). Mosh itself is not particularly exciting; the new State Synchronization Protocol it is based upon might be: "This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB mode. While SSP takes care of the networking protocol, it is the implementation of the object being synchronized that defines the ultimate semantics of the protocol."

Sorry! There are no comments related to the filter you selected.

First they invented telnet, which had... (4, Insightful)

ArsenneLupin (766289) | more than 2 years ago | (#39644631)

... a negotiable LOCAL_ECHO mode. Then they invented ssh, and left away that LOCAL_ECHO and linebuffered flags, considered to be archaic.

And 15 years later, LOCAL_ECHO is back in mosh!

Younger coders usually think they know best.. (2)

Viol8 (599362) | more than 2 years ago | (#39645057)

Then they discover there was usually a good reason for something being done the way it was in the past. Eg local echo was very useful for line buffered programs such as MUDs and chat servers or even talking to SENDMAIL or an FTP server directly. It was easier to write the server to cope with just line by line rather than character by character and it used up less network resources in the process.

Re:Younger coders usually think they know best.. (2)

Malties (1942112) | more than 2 years ago | (#39645827)

These younger coders don't know what network lag is. In my day I had a connection that was so slow I could type faster than my 150 baud modem could send the keystrokes.

Re:Younger coders usually think they know best.. (1)

Lawrence_Bird (67278) | more than 2 years ago | (#39646819)

Hmmm.. I think you are fibbing.. the next step up from 110 baud was 300... and I surely date myself with that knowledge. I miss my LA-120.

Re:Younger coders usually think they know best.. (1)

mbadolato (105588) | more than 2 years ago | (#39647099)

When I had my Atari 800, I got an MPP-100C modem. It was a 300, but could go to 450. So if I dialed into a BBS that had a 1200 baud line, WOOHOO!

Re:First they invented telnet, which had... (4, Interesting)

Animats (122034) | more than 2 years ago | (#39645379)

.. a negotiable LOCAL_ECHO mode. Then they invented ssh, and left away that LOCAL_ECHO and linebuffered flags, considered to be archaic. And 15 years later, LOCAL_ECHO is back in mosh!

Right. Breaking local echo in Telnet was a Berkeley misfeature. It was in 3COM's UNET, which predated Berkley networking in UNIX. (Berkeley did not introduce networking in UNIX. Theirs was the third or fourth implementation, after ones from BBN, 3COM, and Phil Karn.) With UNET, circa 1983, Telnet had local echo until you used something like VI or the RAND full screen editor, at which point the server noticed the stty call which switched to "raw mode" and switched to remote echo.

Seamless transition from local echo to remote echo is even older. It was in Tymnet [rogerdmoore.ca] , which used markers called a "red ball" and a "green ball" to do the switch seamlessly.

Red ball, Green ball (1)

hedronist (233240) | more than 2 years ago | (#39645809)

Oh God! The flashbacks are killing me! Back in the mid-70's I worked for Tymshare (sister company/parent/?? of Tymnet) doing load testing on a project called OnTyme (commercial email). I was hip-deep in the Tymnet protocol trying to record and then re-create realistic pseudo-user-loads from different points in the country. Massive PITA.

Pass on the local echo please! (5, Insightful)

Anrego (830717) | more than 2 years ago | (#39644647)

and gives instant feedback on typing (and deleting).

That sounds like a step backwards to me. Any utility in that is lost when something doesn’t sync up properly. When I hit a key, I want to know it has been sent and received and see the result.. not see the result as my shell predicts it. Maybe I’m just having local echo flashbacks from past telnet experiences.

Everything else sounds really neat though. I don’t jump wifi often enough for re-connecting and re-attaching to screen to be a big deal.. but I can see the utility for those who do.

Re:Pass on the local echo please! (1)

Anonymous Coward | more than 2 years ago | (#39644689)

It's not like you aren't used to passing a bunch of obscure flags to Linux commands anyway. I'm sure there will be one for this, as well as a ssh_config option.

Re:Pass on the local echo please! (5, Informative)

Anonymous Coward | more than 2 years ago | (#39644849)

From their website:

Disable instant echo

$ mosh --predict=never niennunb

The -n switch is a synonym. By contrast, passing --predict=always or -a will enable instant local echo even on low-delay links.

Sounds like it tries to be smart about this, but not so smart as to not allow a human to force things the way he wants them.

Re:Pass on the local echo please! (1)

Anrego (830717) | more than 2 years ago | (#39644895)

Hmm, I missed that bit. I assumed there would be a feature to disable it, but didn't realize it would only come on in low latency ..

Re:Pass on the local echo please! (5, Informative)

Anonymous Coward | more than 2 years ago | (#39644931)

According to their website, locally echoed but not yet synced input is visually distinct from synced content, so you'll always know what has been sent and what hasn't.

Re:Pass on the local echo please! (5, Informative)

Anonymous Coward | more than 2 years ago | (#39644949)

I've been using it for a few days now, and I find the local echo to be quite a useful feature. Many of the machines I remotely use are on different continents, and waiting for my keypress to make a round trip can be frustrating at times.

Mosh also makes it clear which characters have been successfully transmitted by underlining those that are still finding their way through the tubes... i've never been unsure what has or has not been received.

After a few days of using mosh, I don't see myself going back to plain old ssh anytime soon.

Re:Pass on the local echo please! (1)

gstrickler (920733) | more than 2 years ago | (#39645325)

Sounds like a great solution. Responsiveness is critical for user interaction, therefore, local echo is vital for high latency links. Knowing that the remote end has received the same thing you see locally (and if it's performing character-by-character filtering, seeing those results) is also important. Local echo, with remote echo verification.

Re:Pass on the local echo please! (-1, Offtopic)

sujan444 (2605375) | more than 2 years ago | (#39645321)

Only fools drive and text *wink* wink*. Parking garages. Tunnels. Toll plazas. Petrol Stations. Or just between I find the local echo to be quite a useful feature. Many of the machines I remotely use are on different continents, and waiting for my keypress to how to make money [vuthang.org]

Instant local echo (1)

Ed Avis (5917) | more than 2 years ago | (#39644671)

So mosh has brought back the ages-old idea of local echo on the terminal. It disappeared as soon as terminal connections became faster than the old teletype links. I have often wished for such a feature in ssh, some kind of 'cooked mode'. However I usually run a 'screen' session on the other end of ssh, with emacs inside that, and finally a shell-mode under Emacs! Mosh would need to do something quite clever to enable local editing in that.

I stopped reading after this (1)

Anonymous Coward | more than 2 years ago | (#39644719)

"To bootstrap an SSP connection, the user rst logs in to the remote host using conventional means, such as SSH or Kerberos."

Re:I stopped reading after this (2)

isama (1537121) | more than 2 years ago | (#39644851)

So that means it's just like GNU Screen? ctrl+a d on one connection, hop wifi, ssh and screen -x. wow. Really?

Re:I stopped reading after this (1)

Anonymous Coward | more than 2 years ago | (#39645023)

Are people still using screen instead of tmux?

Re:I stopped reading after this (1)

David_W (35680) | more than 2 years ago | (#39645185)

Yes, until I can figure out how to get it to stop ringing the bell when it starts and sending ^? instead of ^H for backspace, I'm still using screen.

Re:I stopped reading after this (1)

eldorel (828471) | more than 2 years ago | (#39645261)

Yup. screen is already available on everything I use (and has been for a decade), from the crappy residential grade router at my mothers to the servers at client shops. Tmux, not so much.

Re:I stopped reading after this (0)

Anonymous Coward | more than 2 years ago | (#39645273)

Yes, because a large number of people still use telnet for various devices and still use serial connections with varying baud rates.

Tmux's biggest claim is one of idealogy (BSD vs GPL) rather than any real technical merit.

For a large number of people, tmux is a step backwards from screen, ignoring the default key bind of ctrl-b vs ctrl-a - ooohhhh.

Re:I stopped reading after this (2)

Junta (36770) | more than 2 years ago | (#39646821)

Tmux's biggest claim is one of idealogy (BSD vs GPL) rather than any real technical merit.

Actually, tmux defaults at least are nice. When I 'tmux a' to share a session with someone else, our multi-window view is synced. Fit-to-terminal is a bit more sane too.

Screen developer/advocates really need to provide a guide on how to make screen behave like tmux default, if possible. Ctrl-A default bind is annoying as anything too.

Re:I stopped reading after this (2)

Imagix (695350) | more than 2 years ago | (#39645081)

I think the point this has is that it will automatically do the reconnect for you. What I'm not sold on is that this now requires an arbitrary port to be open on the server side in order to connect to the mosh server, and how irritated are the security guys who control the edge firewalls on your corporate network going to get?

Re:I stopped reading after this (1)

phoenix_rizzen (256998) | more than 2 years ago | (#39647185)

And many (most?) SSH clients support auto-reconnect on short network drops. And many even support reconnect on IP change (like when switching wireless networks or to 3G). And you can even configure your tmux (way better than screen) session to connect on login.

Thus, many SSH clients already do everything that MOSH does, but without having to install any new software anywhere.

Re:I stopped reading after this (0)

Anonymous Coward | more than 2 years ago | (#39645777)

My point was. It tries to come off as UDP based, but it requires tcp to get started.

It seems cool for people with this problem but I dont really think its all the big a deal and I doubt its going to modernize SSH in a way that will impact the majority of users.

Obsolete within five years (2, Interesting)

mikael_j (106439) | more than 2 years ago | (#39644749)

While neat for those who are currently in areas with spotty wireless coverage it is a neat idea but for most users I don't think it's that much of an issue, even at the moment.

Fast forward five years and I just don't see this software being all that useful. Sure, there's always gonna be that handful of people who will scream that this is extremely useful because they're always hopping between wifi hotspots but most users are using 3G/4G when they're on the move and coverage for those is already "good enough" in most civilized places and steadily improving. I've taken 5+ hour train trips several times and only had ssh connections drop once or twice on those trips (due to spotty coverage in what would quality as the middle of nowhere in northern Sweden).

This is like "solving" the IPv4 address exhaustion problem with NAT, it's a neat workaround but doesn't actually solve the problem.

Re:Obsolete within five years (1)

Anonymous Coward | more than 2 years ago | (#39644811)

So, once again, just because you cannot see a benefit, everyone shouldn't either? Try this in your perfect network world: Passenger in a car, logging on to remote boxen, car is moving in and out building, not fucking straight lines on a railway track). Get the picture?

Re:Obsolete within five years (0)

Anonymous Coward | more than 2 years ago | (#39644911)

Wow you're retarded. you manage to concoct an edge case (how often do you ssh while in a moving car that's going in and out of buildings? REALLY?) and conclude that the parent is completely wrong.

Re:Obsolete within five years (1)

ArsenneLupin (766289) | more than 2 years ago | (#39645177)

you manage to concoct an edge case

Sorry, this is about 3G/4G, not EDGE.

how often do you ssh while in a moving car

As the passenger, of course. Only fools drive and text *wink* wink*.

that's going in and out of buildings?

Parking garages. Tunnels. Toll plazas. Petrol Stations. Or just between two tall buildings blocking out the signal.

Re:Obsolete within five years (1)

the_B0fh (208483) | more than 2 years ago | (#39645915)

And people still don't know how to use authorized_keys? WTF?

Re:Obsolete within five years (0)

Anonymous Coward | more than 2 years ago | (#39647645)

What does this have to do with authorized_keys? You still have to type when using ssh, even after login.

Re:Obsolete within five years (1)

A nonymous Coward (7548) | more than 2 years ago | (#39645547)

Wow you're dull and unimaginative. Imagine a cell phone constantly keeping in touch, and WiFi is faster than cell.

Imagine any number of things which are unimaginable. Stretch that brain!

Re:Obsolete within five years (1)

Anonymous Coward | more than 2 years ago | (#39644829)

My phone prefers wifi over 3g, I often hop between the two even with good coverage.

Re:Obsolete within five years (1)

Anonymous Coward | more than 2 years ago | (#39644955)

It's a pain in the butt if you jump between wired & wireless connections, or your work has "dead zones" in the Wifi coverage. It was one of the main reasons I switched from X11 over SSH to VNC: VNC let me reconnect and resume my session while SSH just conked out.

Re:Obsolete within five years (1)

gstrickler (920733) | more than 2 years ago | (#39645369)

Satellite links, network congestion/delays, and other sources of high latency aren't going to magically disappear in 5 years, nor 10, 15, or 20 years. Until you can bypass the speed of light (in x transmission medium) as the limiting factor, this is useful.

Re:Obsolete within five years (2)

TeknoHog (164938) | more than 2 years ago | (#39645473)

Fast forward five years and I just don't see this software being all that useful. Sure, there's always gonna be that handful of people who will scream that this is extremely useful because they're always hopping between wifi hotspots but most users are using 3G/4G when they're on the move

Dunno about 4G, but 3G has enough latency to make ssh annoying, so Mosh would definitely be an improvement.

Re:Obsolete within five years (2)

Kidbro (80868) | more than 2 years ago | (#39645797)

I just started using it (after seeing this article) to connect from my laptop which I suspend and carry in my backpack from work to home. Opened the lid, and the session is still seemingly intact after the few seconds it takes to find my home wifi.
No 4G connection in the world is gonna help a device that's effectively turned off.

I don't think this is a very unusual use case.

Roaming is not needed in mom's basement. (2)

Medievalist (16032) | more than 2 years ago | (#39646341)

I see the need for this all the time. It's a commonplace in large enterprises like hospitals, factories, and financial services corporations.

Example: I'm working on my hospital laptop. I get called urgently to do something elsewhere in the hospital so somebody won't die right now. I grab the lappie and run, then when I get to the theatre I plug into the malfing imager and fix it. Meanwhile all my SSH connections died because I crossed three wireless boundaries at high speed.

Example 2: I'm on the line debugging the tension loader robot while a human continuously manually corrects the tension downthread. I find the upstream data to the robot is bad and I have to backtrack all the way across the building to find the malfunctioning sensor, then come back and double-check the robot again. All my SSH connections into the DCS keep failing because the factory floor's high RFI means we have to have lots of small loud wireless zones, and I have to keep moving among them.

Example 3: I'm in a conference room lecturing junior banksters on how to fleece grandmothers and the CEO throws us out so his pet congressman can use the room to tongue-polish his shoes for him. The next conference room is two wireless zones away, so my secure SSH tunnel into Dr. Evil's antarctic lair fails and I have to sacrifice another day trader to get the blood I need for our in-house key transfer protocol.

OK, that last example was a bit contrived but I was starting to get bored.

Re:Obsolete within five years (3, Insightful)

silanea (1241518) | more than 2 years ago | (#39646989)

If we only ever built technology that appeared immediately useful for at least 95% of the population we would still be trying to figure out how to transport messages across long distances without using a horse.

UDP for a connection which has to -reliably- send? (0)

Anonymous Coward | more than 2 years ago | (#39644761)

and receive?

No thanks, I stopped reading when i saw that udp is used instead of tcp.

Re:UDP for a connection which has to -reliably- se (4, Insightful)

ZorinLynx (31751) | more than 2 years ago | (#39644815)

If they implement their own TCP-like layer over UDP, there's no reason it can't be just as reliable.

It's kind of hard to do things like roaming using TCP because endpoint IPs can change.

Re:UDP for a connection which has to -reliably- se (2)

batrick (1274632) | more than 2 years ago | (#39645557)

> It's kind of hard to do things like roaming using TCP because endpoint IPs can change.

Bullshit. With UDP you have to abstract the connection so that the source IP can change. With TCP you can do the exact same fucking thing. Close the old socket when you get a connection attempt from a new client with the right handshake.

Re:UDP for a connection which has to -reliably- se (2)

agrif (960591) | more than 2 years ago | (#39647775)

Bullshit. With UDP you have to abstract the connection so that the source IP can change. With TCP you can do the exact same fucking thing. Close the old socket when you get a connection attempt from a new client with the right handshake.

I'm a little out of my depth here, but I'd imagine it'd be much easier with UDP because UDP is connectionless. With this sort of roaming, the server isn't expected to change addresses, but the client is. So, have the client sign everything with a negotiated public key, and the server doesn't even have to care where each packet is coming from, or even open any new connections when the client moves across IPs.

Since this is an SSH replacement, I'd expect the key signing to be done already, so once you build an ordering and reliability protocol on top of UDP you essentially get the roaming for free.

Why would I want this compatibility break? (1)

Anonymous Coward | more than 2 years ago | (#39644773)

Let's see...

I get reconnectability (which I already have, either by using a VPN or by using screen on the server), but now it's built-in.

I get local echo so I have no clue whether my connection has been dropped -- but OTOH, this is great if you have the brain of a goldfish and so can't remember what you just typed for a couple seconds till it gets echoed back. I presume this is optional, so non-goldfish-brains can tell it to 'degrade' to be as useful as ssh.

I get better unicode support -- well, that one's cool, anyway.

And it needs ssh for login, but also needs a mosh server -- so I can ssh into every server, but only mosh into a few.

Am I missing some really great thing about it? It seems like a major hassle for a minor improvement.

Re:Why would I want this compatibility break? (1)

Anonymous Coward | more than 2 years ago | (#39644843)

why is unicode a minor improvment. Not everyone wants to use english.

Re:Why would I want this compatibility break? (1)

pipatron (966506) | more than 2 years ago | (#39645011)

I've never had a problem with crazy characters with plain olde SSH. what's the problem?

Re:Why would I want this compatibility break? (-1)

Anonymous Coward | more than 2 years ago | (#39645089)

Not everyone wants to use english.

Yes, well, like with air traffic control, we must. Their can only be one language. We don't need another Tower of Babel here.

On another note, Slashdot seems to believe that unicode is insecure, so we do without.

Re:Why would I want this compatibility break? (1)

jellomizer (103300) | more than 2 years ago | (#39645511)

unicode isn't insecure, it is how it is used that could cause security problems. There are letters that are different then from the ASCII but look almost the same, if not the same. Which means too wide support of unicode could allow people to trick people to go to trusted names to an untrustworthy file/location.

Re:Why would I want this compatibility break? (0)

Anonymous Coward | more than 2 years ago | (#39645877)

unicode isn't insecure, it is how it is used that could cause security problems...

?? Can you run that across one more time? I mean, that line of thinking would lead one to conclude that the world's favorite operating system is 'not insecure', it's just how it's being used..

Re:Why would I want this compatibility break? (-1)

Anonymous Coward | more than 2 years ago | (#39645863)

Their can only be one language.

Then I suggest you learn it.

Re:Why would I want this compatibility break? (-1)

Anonymous Coward | more than 2 years ago | (#39646287)

And I 'suggest' you fuck off and die... What, can't take a typo?

Re:Why would I want this compatibility break? (1)

jellomizer (103300) | more than 2 years ago | (#39645463)

For the most part if you are connecting via a Command Line you are using "An Older" (I am using this lightly, as a lot of new system still have command line and even new version of windows is expanding it command line) System designed for ASCII or VT100 transmission of data. Adding Unicode is a minor improvement, because for the bulk of us whatever language we speak, ls -l is still ls -l.

Unicode will be handy for newer systems that may have a more human language interface to it.

Re:Why would I want this compatibility break? (1)

Kidbro (80868) | more than 2 years ago | (#39647583)

I'm sorry, but that is simply not true. At least not outside the English only speaking world.

ls -l may still be ls -l, but its man page, and the filenames it spits out on stdout are localized, with non US-ASCII characters. The files we view with cat and less are filled with non US-ASCII characters.

Re:Why would I want this compatibility break? (4, Insightful)

Hes Nikke (237581) | more than 2 years ago | (#39645137)

You, now:

so I can ssh into every server, but only mosh into a few.

You, 1995:

so I can telnet into every server, but only ssh into a few.

Re:Why would I want this compatibility break? (1)

Anonymous Coward | more than 2 years ago | (#39646185)

Security is a huge feature. Resurrecting local echo to screw with people's heads is not.

Plus, you don't even seem to get what I was saying; perhaps I rushed over that point a little too fast.

mosh requires ssh. There CANNOT be a mosh-only host which would require me to have a mosh client or have no remote access, unless it's by deliberate brain-dead policy -- so when mosh gets, say, 5% uptake server-side, there's still no good reason for people to get a mosh client, and so there's no good reason for the other 95% to add it. This is the OS/2 thing, where it (allegedly) died largely because it ran Windows apps so well, nobody bothered coding OS/2-specific apps.

ssh does NOT require telnet. It's quite possible (and, these days, incredibly common) to have ssh and not have telnet, if only for password security. And once you have 5% ssh-only servers, everyone needs both ssh and telnet clients; once they have them, other servers can be upgraded at leisure. It breaks the chicken-and-egg problem.

So ssh has a worthwhile feature, and a workable upgrade scheme.
mosh has no worthwhile (to me, YMMV) features, and a self-frustrating upgrade scheme.

The similarity you think you saw just isn't there in reality.

Re:Why would I want this compatibility break? (2)

A nonymous Coward (7548) | more than 2 years ago | (#39645649)

Let's see...

I get reconnectability (which I already have, either by using a VPN or by using screen on the server), but now it's built-in.

But now it's automatic.

I get local echo so I have no clue whether my connection has been dropped -- but OTOH, this is great if you have the brain of a goldfish and so can't remember what you just typed for a couple seconds till it gets echoed back. I presume this is optional, so non-goldfish-brains can tell it to 'degrade' to be as useful as ssh.

It also is automatic and shows what hasn't been echoed. Further, typing while lagging by a character or two is incredibly frustrating to almost all brains in existence. It's like listening to headphones which have a half second delay in what you said. Your brain simply freezes.

I get better unicode support -- well, that one's cool, anyway.

And it needs ssh for login, but also needs a mosh server -- so I can ssh into every server, but only mosh into a few.

Am I missing some really great thing about it? It seems like a major hassle for a minor improvement.

What a pessimist.

iMosh (0)

Anonymous Coward | more than 2 years ago | (#39644809)

Is there a mosh iOS app?

Re:iMosh (1)

vlm (69642) | more than 2 years ago | (#39645575)

Is there a mosh iOS app?

They're promising a droid app soon, for the Daft Punk fans...

OCB Mode is Toxic. (4, Interesting)

TechyImmigrant (175943) | more than 2 years ago | (#39644831)

We tried to put OCB mode in 802.11i. So IBM sent a guy to explain the 'licensing terms' for their patents on OCB mode. The next vote in 802.11i after that presentation was to replace OCB mode with CCM.

Until the patents expire or are freely licensed, OCB mode should be considered off limits for free and open projects.

Re:OCB Mode is Toxic. (2, Informative)

Anonymous Coward | more than 2 years ago | (#39645571)

according to Wikipedia: [wikipedia.org]

Two U.S. patents have been issued for OCB mode. [1] However, a special exemption has been granted so that OCB mode can be used in software licensed under the GNU General Public License without cost, as well as for any non-commercial, non-governmental application. Since the authors have only applied for patent protection in the U.S., the algorithm is free to use in software not developed and not sold inside the U.S. [2].

Re:OCB Mode is Toxic. (5, Informative)

mikechant (729173) | more than 2 years ago | (#39645593)

The patents are freely licensed for any GPL software; see link for details.
http://www.cs.ucdavis.edu/~rogaway/ocb/offer.htm [ucdavis.edu]

Mosh appears to be GPL:
https://github.com/keithw/mosh/blob/master/COPYING [github.com]

Re:OCB Mode is Toxic. (-1)

Anonymous Coward | more than 2 years ago | (#39647441)

So now the FSF and Richard "eats his own toenail fungus" Stallman are working with the patent system to promote their anti-freedom license? Once again we see how the GPL is in fact the worst license possible, far far worse than even the worst EULA's from any closed source company. Another great reason to shun the FSF and the GPL.

Think different. Think BETTER. Think !APPLE!

Re:OCB Mode is Toxic. (2)

vlm (69642) | more than 2 years ago | (#39645753)

It would be an interesting battle. I read the Rogaway original paper years ago and he was granting free use to anything GPL licensed. For a more modern view you can also see"

http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm [ucdavis.edu]

I've looked into MOSH recently, and it is GPL. The battle would be, does mosh live under Rogaway's OCB patents which makes it free, or IBMs patents, which makes it unclear... From a "money is justice" perspective, I donno if ucdavis would win against IBM, but they'd have better odds than "just a bunch of random hackers" vs IBM.

To burn an informative couple hours on the topic, simply google for "rogaway OCB" and start reading.

Other improvements ? (5, Interesting)

redelm (54142) | more than 2 years ago | (#39644853)

IP roaming looks nice & ought to be secure with the right steps (no reply from old IP:port, correct cryto negotiation with new IP:port).

But LOCAL ECHO is a big problem -- applications have to be aware of it. On CLI, many keystrokes are commands, not text to be entered. On vi in command-mode, G goes to the last line.

Personally, a bigger thing is traffic reduction, particularly keystoke combining. Nagel's algorithm is a start, but I've modded ssh to delay and buffer likely-text keystrokes for a short time (400ms) while letting likely commands through immediately to retain responsiveness. The delays aren't irksome, and I reduce outbound traffic by ~80%.

Missed from summary (1)

Anonymous Coward | more than 2 years ago | (#39644897)

mosh is not made to replace ssh but to work with its aid. from page 3 i'm not exactly sure how could user remotely login using Kerberos (in contrast to ssh), but it essentially is a user process started over ssh, wrapping a shell like screen on server.

only problem i can see is the firewall/portforwarding bypassing; if all UDP packets are encrypted and from/to random ports there's no way your iptables is going to pick that one up.

i can't see any idle traffic or re-keying being specified, though i guess it's easy to add later on. i'll definetly try this out, once i can get it through NATs.

Re:Missed from summary (3, Interesting)

vlm (69642) | more than 2 years ago | (#39645807)

i can't see any idle traffic ... being specified

I looked into MOSH in detail a little while ago and the keepalive packet is every 3 seconds or 3 packets per second can't remember which.

It was often enough to make me pause... that's a lot of traffic if you're metered and paying by the K and/or powered by battery...

Why was a fork necessary? (1)

batrick (1274632) | more than 2 years ago | (#39644913)

I see no rationale for not helping to improve SSH. This shit shouldn't be encouraged.

Re:Why was a fork necessary? (0)

Anonymous Coward | more than 2 years ago | (#39645009)

Because some of the improvements break compatibility with the SSH protocol, duh.

Re:Why was a fork necessary? (-1)

Anonymous Coward | more than 2 years ago | (#39645045)

Now it makes sense ;)

Does this formulier [cloudformz.com] work?

Re:Why was a fork necessary? (1)

TeknoHog (164938) | more than 2 years ago | (#39645341)

Moreover, I regard Mosh as solving a higher-level problem, and it is simply good Unix style to use another application on top of ssh. There are also many use cases where ssh does not need these improvements, so it is better to keep the core protocol simple.

Re:Why was a fork necessary? (2)

batrick (1274632) | more than 2 years ago | (#39645601)

Because writing a new RFC for the SSH protocol and then improving the current ubiquitous OpenSSH is an unheard of undertaking.

Re:Why was a fork necessary? (2)

Anrego (830717) | more than 2 years ago | (#39645447)

Once something becomes widely used and stable, making drastic changes becomes next to impossible.

That's why we went CVS -> SVN -> git. Too many people were using CVS to make the changes made in SVN. Too many people are using SVN now to fix the (very old and oft complained about) problems with SVN.

See also NFS. There are issues with NFS that people have complained about for years.. and they will never be fixed for the same reason.

Re:Why was a fork necessary? (0)

Anonymous Coward | more than 2 years ago | (#39646195)

It allowed them to GPL downgrade the stack. That's the goal of every GNU zealot.

modernizing ssh (-1)

Anonymous Coward | more than 2 years ago | (#39644997)

I missed that too.
Does formulier [cloudformz.com] work?

Modernizing SSH (-1)

Anonymous Coward | more than 2 years ago | (#39645149)

Now I get it ;)

Does this formulier [cloudformz.com] work?

Firewalls (5, Insightful)

Alarash (746254) | more than 2 years ago | (#39645161)

Reading the linked research paper a bit, and something strikes me.

We use the existing infrastructure for authenticating hosts and users. To bootstrap an SSP connection, the user ïrst logs in to the remote host using conventional means, such as SSH or Kerberos. From there, the user or her script runs the server: an unprivileged process that chooses a random shared encryption key and begins listening on a UDP port. The server conveys the port number and key over the initial connection back to the client, which uses the information to start talking to the server over UDP.

You open a SSH connection (client->server:22). This port is allowed on the firewall, it lets you through. But then the server decides to listen on UDP:(random port) and tells the client, back through the (encrypted) initial connection, which UDP port to contact. So you initiate a SSP UDP session on that port. How does the firewall knows it should let you through? Since the port number is communicated on an encrypted session, it doesn't have access to that information. So how does this work in a secure environment? The paper doesn't mention any mean for the server to communicate with the network which port its listening on.

Re:Firewalls (2)

jimicus (737525) | more than 2 years ago | (#39645781)

Welcome to Yet Another Protocol Devised By Academics Who Have Not Been Near a Real Network in Twenty Years, If Ever.

Or YAPDBAWHNBNARNITYIE for short.

Re:Firewalls (0)

Anonymous Coward | more than 2 years ago | (#39646751)

"Real" networks don't filter outgoing UDP datagrams (or anything outgoing for that matter). Filtering network traffic is a poor alternative to proper security as it can ALWAYS be circumvented.

Re:Firewalls (0)

Anonymous Coward | more than 2 years ago | (#39647301)

I thought it was the academics who were the last to maintain Real Networks instead of the NAT crap we get in the Real World.

Re:Firewalls (0)

Anonymous Coward | more than 2 years ago | (#39647309)

You didn't read the man page did you? Says it uses UDP ports 60000-61000. So, easy enough let those through your firewall - if you want.
From my limited use, these seem to be sequentially used starting from 60001...

Re:Firewalls (1)

jochem_m (1718280) | more than 2 years ago | (#39645931)

Not having read TFA and going purely by the quote in the parent, I would assume that the key is random ("chooses a random shared encryption key") but the port is not ("begins listening on a UDP port").

Re:Firewalls (2)

inject_hotmail.com (843637) | more than 2 years ago | (#39645973)

You open a SSH connection (client->server:22). This port is allowed on the firewall, it lets you through. But then the server decides to listen on UDP:(random port) and tells the client, back through the (encrypted) initial connection, which UDP port to contact. So you initiate a SSP UDP session on that port. How does the firewall knows it should let you through? Since the port number is communicated on an encrypted session, it doesn't have access to that information. So how does this work in a secure environment? The paper doesn't mention any mean for the server to communicate with the network which port its listening on.

My guess is as good as anyone else's, but I surmise it does a bit of packet trickery. Once device A (behind firewall) is connected to device B (may/may not be behind firewall, but at least one port is open, 22 by default in this case), device A can create an SSH tunnel...they really are rather neat and VERY useful as a means of security. For example, I have webmin running on a server, but its port (10 000) is blocked by the firewall. Once I connect to SSH I can redirect packets to a certain IP:Port combo (device A's IP:Random Port#) to the servers local address (127.0.0.1) and new UDP port, and voila: hidden/secure/direct connection. One can even make a tunnel in the other direction, so that the server can connect to a remote device in the same manner, and any application won't realize that it's even connecting to anything outside of its network.

Whomever thought of and implemented SSH tunnels is a master genius. I would shake his/her hand if I ever saw them.

Re:Firewalls (0)

Anonymous Coward | more than 2 years ago | (#39645997)

Mosh uses UDP on ports 60000-61000, which IUC, must be opened at the firewall level. (See their descriptor for mosh on EC2)

Re:Firewalls (0)

Anonymous Coward | more than 2 years ago | (#39646255)

So you initiate a SSP UDP session on that port. How does the firewall knows it should let you through?

It doesn't. The project's documentation and web page specifically state you have to open all the ports in the 61xxxx (?) range in your firewall.

Re:Firewalls (0)

Anonymous Coward | more than 2 years ago | (#39646623)

You open a SSH connection (client->server:22). This port is allowed on the firewall, it lets you through. But then the server decides to listen on UDP:(random port) and tells the client, back through the (encrypted) initial connection, which UDP port to contact. So you initiate a SSP UDP session on that port. How does the firewall knows it should let you through? Since the port number is communicated on an encrypted session, it doesn't have access to that information. So how does this work in a secure environment? The paper doesn't mention any mean for the server to communicate with the network which port its listening on.

That's easy, you just tunnel SSP over the SSH connection.

Less is More (0)

Anonymous Coward | more than 2 years ago | (#39645167)

As with TLS, I'd like to see any future revisions of these secure protocols trim more fat. Arcane ciphers, modes, etc. Crypto software is very difficult to secure - there are a lot of subtleties, and there's been a distinct lack of basic software engineering discipline. Lack of regard for domains, layers, interfaces, etc.

Re:Less is More (1)

phantomfive (622387) | more than 2 years ago | (#39645391)

As with TLS, I'd like to see any future revisions of these secure protocols trim more fat.

Dude, SSH is half a meg. Calm down.

Re:Less is More (0)

Anonymous Coward | more than 2 years ago | (#39645465)

When you're operating on a slow wireless connection with an already high amount of traffic on it, every bit counts.

Re:Less is More (2)

phantomfive (622387) | more than 2 years ago | (#39645521)

When you're operating on a slow wireless connection with an already high amount of traffic on it, every bit counts.

Um, then don't download SSH over a slow wireless connection? Download over a high-speed wired connection and side-load it onto your device.

Re:Less is More (1)

inject_hotmail.com (843637) | more than 2 years ago | (#39646109)

When you're operating on a slow wireless connection with an already high amount of traffic on it, every bit counts.

Aw man! Nerdiest double-entendre ever! I'm jealous.

Re:Less is More (1)

vlm (69642) | more than 2 years ago | (#39646181)

As with TLS, I'd like to see any future revisions of these secure protocols trim more fat.

Dude, SSH is half a meg. Calm down.

The problem with "Arcane ciphers, modes, etc" is not executable size at all, but security.

For example, MD2 finally go the axe from openssl back in '09, not because md2 took up too much executable space, but because it was obsolete small / psuedo-broken. I call it psuedo-broken because they crypto guys would call it broken, cracked wide open, but its not totally broken like DRM or copy-protection schemes. Its still has got about 50 bits or so of security, and for many apps that's more than enough, as long as you go in eyes wide open that its a "50 bit hash" not a "128 bit hash". Anyway in '97 md2 was looking shaky, and in '04 it was psuedo-broken, so it should have gotten the axe around 97 to 04, not wait until '09....

You don't want the "ssh of a new decade" to support all kinds of cruft that can be used to exploit it later on. Using md2 in mosh, for example, would be a bug not a feature, or merely a waste of executable code size.

Re:Less is More (1)

inject_hotmail.com (843637) | more than 2 years ago | (#39646203)

As with TLS, I'd like to see any future revisions of these secure protocols trim more fat.

Dude, SSH is half a meg. Calm down.

I think buddy's point is that SSH should deprecate support for old crypto libs because no one uses them anymore, and they are sort of an Achilles Heal...look at how easily GSM can be subverted because it supports old cypher protocols (and even one that is "No Encryption" encryption!)...anyway, point is: get rid of the stuff no one uses anymore, use only strong crypto with no option for in-the-clear, to reduce the potential for security issues. Our good friend AC just isn't so verbose about his idea...

TFA has been analyzed and has a critical weakness (0)

Anonymous Coward | more than 2 years ago | (#39646679)

No more annoying network lag on typing, the MIT boffins say

Many boffins died to bring us this information

Hold on (0)

Anonymous Coward | more than 2 years ago | (#39646935)

Quoting from the technical info; "Every time the server receives an authentic packet from the client with a sequence number higher than any it has previously received, the IP source address of that packet becomes the server's new target for its outgoing packets"

What's to stop one from replaying a captured packet with a higher sequence number and a spoofed source address to redirect the connection?
Seeing as this is designed for hopping networks, this could easily happen on a public network. MITM, anyone?

Re:Hold on (1)

profplump (309017) | more than 2 years ago | (#39647945)

Because the sequence number is part of the encrypted payload, and already-seen sequences do not update the state.

Port Forwarding? (1)

QuantumRiff (120817) | more than 2 years ago | (#39646993)

Does this do things like Port Forwarding? or is this not a replacement for SSH, but almost an extension of it?

I use SSH port forwarding (both directions) compression, and stuff all the time.

Object synchronization is not new... (1)

Roogna (9643) | more than 2 years ago | (#39647271)

Heck, people have done that with Objective-C remote proxies have basically been doing that as a form of RPC since NeXT days. Not to mention any other usages of it.

Sorry, you know the saying... (0)

Anonymous Coward | more than 2 years ago | (#39647657)

No shoes, no shirt, no Windows client, no service.

Smooth scrolling terminal (1)

jones_supa (887896) | more than 2 years ago | (#39647777)

As we're talking about things related to terminals, the one thing I'm still anxiously missing is a terminal emulator which implements smooth scrolling of new text, a feature that was also present in some hardware terminals a million years ago. I guess some smart guy could modify an existing terminal to support this. Heck, if I had a bit more skills, I'd roll up my sleeves and do it myself. It would be sweet.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?