[mosh-devel] mosh without ssh?

[Weiwu Zhang]

Hello. I believe many are attracted to mosh like me because they
cannot run ssh, and sad to realize, although advertised as a
replacement of ssh, mosh depends on ssh.

The reasons users prefer not to use ssh could be because it is plain
out blocked. Like in Iran, or stemed, like in China?.

Nobody talked about it in email archive (at least I didn't find). So
is there any plan to d?monize mosh? Or to write an authenticating
d?mon for mosh. I would write one, but my hands are full for the year.

Best regards.

? If constant data transfer over a threshold is detected, our national
firewall would sometimes "halt" ssh, like giving it a speed of 1 byte
per minute. This is to maintain basic utility of ssh and prevent it
being used as a proxy to access 'harmful content'.

[Michael Weber]

Post by Weiwu Zhang
Hello. I believe many are attracted to mosh like me because they
cannot run ssh, and sad to realize, although advertised as a
replacement of ssh, mosh depends on ssh.

For starters, man mosh-server and man mosh-client.

On the server run:
mosh-server new -p $randomport -- $shellprogram
you get an result like QzdRHbAWzL7eRobi75DCrz
On the client you run:
MOSH_KEY=QzdRHbAWzL7eRobi75DCrz mosh-client $serverip $radomport
done.

Note that $serverip has to be an ip, no hostname resolution.

How you get the key from one side to the other is up to you.
Afaiks mosh-server does not allow to set the MOSH_KEY to a specific value.

Post by Weiwu Zhang
The reasons users prefer not to use ssh could be because it is
plain out blocked. Like in Iran, or stemed, like in China?.
Nobody talked about it in email archive (at least I didn't find).
So is there any plan to d?monize mosh? Or to write an
authenticating d?mon for mosh. I would write one, but my hands are
full for the year.
? If constant data transfer over a threshold is detected, our
national firewall would sometimes "halt" ssh, like giving it a
speed of 1 byte per minute. This is to maintain basic utility of
ssh and prevent it being used as a proxy to access 'harmful
content'.

So it doesn't block outbound port scans et al. *great*
I assume that this traffic limitiation is applied on all ports?
Setting up ssh server on non-standard ports would be too easy to
accomplish.

In general case, the ssh traffic is limited to an handshake and the
transmission of the MOSH_KEY token, not that much traffic.

But, ports hopping at a randomized, either pre-determined or as
counter-measure would be funny to have. Just like radio style
frequency hopping.

Michael

- --
Michael Weber
web: https://xmw.de/
mailto: michael at xmw.de
mobile: [phone]

[Axel Beckert]

Hi,

I don't expect that mosh will grow an authentication layer besides SSH
so quickly (and many are happy that mosh uses a well-known,
well-understood and proven system for authentication), but I know

Post by Weiwu Zhang
? If constant data transfer over a threshold is detected, our national
firewall would sometimes "halt" ssh, like giving it a speed of 1 byte
per minute. This is to maintain basic utility of ssh and prevent it
being used as a proxy to access 'harmful content'.

In case it just kills one TCP connection (and not all port 22
connections from the same IP), autossh[1] may help, If it detects a no
more working SSH connection, it kills it and starts a new one with the
same parameters.

[1] http://www.harding.motd.ca/autossh/ (Should also be available in
many Linux distributions.)

Kind regards, Axel

[Keith Winstein]

Hello Weiwu,

The "mosh" wrapper script does use ssh, but only to remotely execute a
"mosh-server" on the server (running as the user) and collect the
session key it prints out.

Others have replaced SSH with HTTPS (the user authenticates with a
password or X.509 certificates and then gets the secret key in the Web
connection), or remctl (Kerberos). You could even use NFS by putting
files in magic places. Could these work for you instead?

Pretty much _any_ means of getting the server to start a mosh-server
process and convey the session key back to you would work. That's why
I think writing our own authenticating daemon on top of all the
existing ones is probably unnecessary.

If all else fails, you could remove the 60-second timeout from
mosh-server and just start 100 processes when you do have a
connection, and then save the corresponding port numbers and session
keys. Then just feed one of them to mosh-client when you feel like
starting a new session. (See timeout_if_no_client in
src/frontend/mosh-server.cc for this timeout.) I hope this helps.

Best regards,
Keith

Post by Weiwu Zhang
Hello. I believe many are attracted to mosh like me because they
cannot run ssh, and sad to realize, although advertised as a
replacement of ssh, mosh depends on ssh.
The reasons users prefer not to use ssh could be because it is plain
out blocked. Like in Iran, or stemed, like in China?.
Nobody talked about it in email archive (at least I didn't find). So
is there any plan to d?monize mosh? Or to write an authenticating
d?mon for mosh. I would write one, but my hands are full for the year.
Best regards.
? If constant data transfer over a threshold is detected, our national
firewall would sometimes "halt" ssh, like giving it a speed of 1 byte
per minute. This is to maintain basic utility of ssh and prevent it
being used as a proxy to access 'harmful content'.
_______________________________________________
mosh-devel mailing list
mosh-devel at mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[Weiwu Zhang]

Thanks all of you for answering my posts, and especially Keith who
listed almost all possible methods. I don't usually reply email in
half a year, except when caught in busines for too long, like now.

Post by Keith Winstein
Pretty much _any_ means of getting the server to start a mosh-server
process and convey the session key back to you would work. That's why
I think writing our own authenticating daemon on top of all the
existing ones is probably unnecessary.

Then this should also work:

Server:

1. store my public key (ssh public key for example) on the server --
while it is already on the server, in ~/.ssh/authorized_key
2. wrap mosh-server in inetd, and emit the session key encrypted with
the public key.

Client:

1. get an encrypted session key from given port.
2. decrypte it and with it establish mosh client.

Both server and client can be done with one line command, if properly
pipe the session key to cipher tools, which I don't know how to. Few
would elaborately reinvent ssh authentication using this homebrew
workaround to prevent the connection being detected as ssh, but in the
worst times in Beijing, during political events, housing area network
outgoing ssh connection attempts can get your ssh server graylisted
for days. In these critical eventful days, not a single clue should be
given to the big brother sensorship that somebody is doing ssh.

The thick Kerberos admin manual always daunts me. However it also
daunts big brother sensorship, who, I feel sure, doesn't bother to
detect Kerberos, except the version wrapped in other products like
ActiveDirectory. If somebody offers Kerberos authentication server as
an inexpesive online service like DNS, backed by his own reputation or
two cents of bitcoins, I would consider buying it just to free myself
from the manuals - my security requirement is only that it should
stand against botnet membership recruitment, not that it stands
against targeted attempts.

[Daniel]

You could also do something like using a key pair, with the public key
on the server, use this to encrypt the random mosh-server key and then
publish it in a DNS TXT record, then change it every <x> days or
script it so when you start a new mosh-server instance, it generates
another mosh key and then publishes that, etc.

Post by Weiwu Zhang
Thanks all of you for answering my posts, and especially Keith who
listed almost all possible methods. I don't usually reply email in
half a year, except when caught in busines for too long, like now.

Post by Keith Winstein
Pretty much _any_ means of getting the server to start a mosh-server
process and convey the session key back to you would work. That's why
I think writing our own authenticating daemon on top of all the
existing ones is probably unnecessary.

1. store my public key (ssh public key for example) on the server --
while it is already on the server, in ~/.ssh/authorized_key
2. wrap mosh-server in inetd, and emit the session key encrypted with
the public key.
1. get an encrypted session key from given port.
2. decrypte it and with it establish mosh client.
Both server and client can be done with one line command, if properly
pipe the session key to cipher tools, which I don't know how to. Few
would elaborately reinvent ssh authentication using this homebrew
workaround to prevent the connection being detected as ssh, but in the
worst times in Beijing, during political events, housing area network
outgoing ssh connection attempts can get your ssh server graylisted
for days. In these critical eventful days, not a single clue should be
given to the big brother sensorship that somebody is doing ssh.
The thick Kerberos admin manual always daunts me. However it also
daunts big brother sensorship, who, I feel sure, doesn't bother to
detect Kerberos, except the version wrapped in other products like
ActiveDirectory. If somebody offers Kerberos authentication server as
an inexpesive online service like DNS, backed by his own reputation or
two cents of bitcoins, I would consider buying it just to free myself
from the manuals - my security requirement is only that it should
stand against botnet membership recruitment, not that it stands
against targeted attempts.
_______________________________________________
mosh-devel mailing list
mosh-devel at mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel