20 Jan
2016
20 Jan
'16
4 p.m.
Sadly, noone seems to be interested in setting up Multinet link. Apart
from the one to LEGATO, not a single one have been set up from MIM so
far. I was hoping for at least SG1 as well.
Meanwhile I've added TCP tunneling in RSX as well, which now works.
I have a question on how Multinet on VMS works, though. When you have
passive TCP connections, are they all sharing the same port number, or
do you configure each with a different number? Right now I did it with
separate port numbers under TCP for each connection, but for incoming
connections, I could change the code to use a common port number.
Any opinions from anyone?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
20 Jan
20 Jan
4:05 p.m.
Sadly, noone seems to be interested in setting up
Multinet link. Apart
from the one to LEGATO, not a single one have been set up from MIM so
far. I was hoping for at least SG1 as well.
I'll point out that you specified you wanted to convert existing bridge
connections, not just add redundant links.
I have a question on how Multinet on VMS works,
though. When you have
passive TCP connections, are they all sharing the same port number, or
do you configure each with a different number? Right now I did it with
separate port numbers under TCP for each connection, but for incoming
connections, I could change the code to use a common port number.
Best I can tell, Multinet wants decnet-over-ip connections to originate
and terminate on the same port number (700, iirc).
De
4:11 p.m.
On 2016-01-20 16:05, Dennis Boone wrote:
Huh? Where did I say that??? I am in fact very fond of redundant links.
Well, it is configurable, as far as I gathered. But the default is 700.
But if you are accepting connections from multiple sites using TCP, you
all accept them all at the same local port, or different ones, or is it
selectable?
For UDP it's a different story, and my current implementation always
assume they will all use the same UDP port.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Sadly, noone
seems to be interested in setting up Multinet link. Apart
from the one to LEGATO, not a single one have been set up from MIM so
far. I was hoping for at least SG1 as well.
I'll point out that you specified you wanted to convert existing bridge
connections, not just add redundant links. I have a
question on how Multinet on VMS works, though. When you have
passive TCP connections, are they all sharing the same port number, or
do you configure each with a different number? Right now I did it with
separate port numbers under TCP for each connection, but for incoming
connections, I could change the code to use a common port number.
Best I can tell, Multinet wants decnet-over-ip connections to originate
and terminate on the same port number (700, iirc).
4:31 p.m.
On 2016-01-20 16:16, Dennis Boone wrote:
That means that we can eventually reduce the size of the bridge, when
people want to. It's not required. The size of the bridge have some
implicit problems. The number of routers on one ethernet segment is
limited in DECnet, as well as the number of nodes.
So, I'm sorry if that was read as dropping off the bridge was required.
It was meant as a possible later action with some good side effects. I'm
definitely not going to kick anyone off the bridge.
But, honestly, in some situations, the Multinet link might give better
performance, and in either case, the bridge cannot grow that much more
no matter what.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> I'll
point out that you specified you wanted to convert existing bridge
> connections, not just add redundant links.
Huh? Where did I say that??? I am in fact very
fond of redundant links.
You said:
but who would like to peer with me, and reduce the size of the
bridge? 
4:09 p.m.
passive TCP connections, are they all sharing the same
port number,
or do you configure each with a different number?
Active TCP connections and UDP can both share the same port - there's no conflict
there.
A single passive TCP connection can share the same port with active TCP and UDP
connections.
But if you have more than one passive TCP connection, you'll have to assign all the
others to unique port numbers. There's a /PORT= option to the MULTINET SET/DECNET
command to do just that.
Bob
4:13 p.m.
On 2016-01-20 16:09, Robert Armstrong wrote:
Yes. Different domains.
passive TCP
connections, are they all sharing the same port number,
or do you configure each with a different number?
Active TCP connections and UDP can both share the same port - there's no conflict
there. A single passive TCP connection can share the same
port with active TCP and UDP connections.
But if you have more than one passive TCP connection, you'll have to assign all
the others to unique port numbers. There's a /PORT= option to the MULTINET SET/DECNET
command to do just that.
Not sure how you meant the two lines above to be read. How could a
passive connection use the same port as a passive one? That would cause
just as much conflict as if you have several passive ones.
However, thanks for the details. Seems like Multinet do not share the
passive port between connections then. Same as my current code. So maybe
I'll just leave it as it is for now then.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
4:17 p.m.
Not sure how you meant the two lines above to be read.
How could a passive
connection use the same port as a passive one?
I think you misspoke and used the word "passive" twice in error, right?
For active connections, the /PORT is the port number to connect to on the remote end.
The local port number is moot and is assigned dynamically.
For passive connections, the /PORT is the port number to listen to on the local host.
QED - you can have as many outgoing active connections as you like, and exactly one
incoming connection all on the same port. But if you have more than one listener on the
local host, then they have to listen to unique ports.
Bob
4:34 p.m.
On 2016-01-20 16:17, Robert Armstrong wrote:
Yes. Sorry.
Not sure how
you meant the two lines above to be read. How could a passive
connection use the same port as a passive one?
I think you misspoke and used the word "passive" twice in error, right?
For active connections, the /PORT is the port
number to connect to on the remote end. The local port number is moot and is assigned
dynamically.
Aha! That is interesting. So Multinet do not control the local port
number when in active mode. Does that mean it also accepts connections
from anywhere for passive connections? Or how do they authenticate?
IP address only?
For passive connections, the /PORT is the port
number to listen to on the local host.
QED - you can have as many outgoing active connections as you like, and exactly one
incoming connection all on the same port. But if you have more than one listener on the
local host, then they have to listen to unique ports.
Now I understand how you meant it. I'm thinking local machine all the
time, and all connections will have different local ports then. What
remote port is used is also a different domain.
TCP can listen for, and accept multiple connections on one port. telnet
is a typical example of this, as well as http. So I was wondering if
Multinet also did that, but apparently not then. Thanks.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
4:45 p.m.
So Multinet do not control the local port number when
in active mode.
Correct. AFAIK this is like most TCP applications (e.g. telnet) that initiate outgoing,
active, connections.
Does that mean it also accepts connections from
anywhere for passive connections?
Yep.
Or how do they authenticate? IP address only?
Authenticate?? We don't need no stinking authentication :-)
Seriously, though, AFAIK Multinet tunnels have no authentication at all. If somebody
out there was smart enough to know what we were doing and spoof the DECnet packets, then
they could probably break in. Or at least they could take over the DECnet tunnel -
whether they could log in and access files depends on how secure you've made your
host. Since a lot of the HECnet hosts, especially ones with TCP/IP tunnels, already have
direct Internet facing ports for telnet, ssh, ftp, etc the question of DECnet security
seems moot.
You can always configure your router, as I have, to only forward port 700 traffic from
specific Internet hosts. That'll solve the problem unless somebody also cares enough
to go to the trouble of spoofing IPs as well.
Getting off topic - don't I remember that there was a way to set a password on
point-to-point DDCMP circuits? How (or rather, at what level in the protocol stack) was
that implemented ?
Bob
4:51 p.m.
On 2016-01-20 16:45, Robert Armstrong wrote:
Right. But you can control the local port number if you want to, and a
few cases like that do exist, but it is unusual...
Even random IP addresses, or just random ports?
:-)
So Multinet do
not control the local port number when in active mode.
Correct. AFAIK this is like most TCP applications (e.g. telnet) that initiate
outgoing, active, connections. Does that mean
it also accepts connections from anywhere for passive connections?
Yep. Or how do they
authenticate? IP address only?
Authenticate?? We don't need no stinking authentication :-) Seriously, though, AFAIK Multinet tunnels have no
authentication at all. If somebody out there was smart enough to know what we were doing
and spoof the DECnet packets, then they could probably break in. Or at least they could
take over the DECnet tunnel - whether they could log in and access files depends on how
secure you've made your host. Since a lot of the HECnet hosts, especially ones with
TCP/IP tunnels, already have direct Internet facing ports for telnet, ssh, ftp, etc the
question of DECnet security seems moot.
Well, yes, that is true. However, I doubt many would be clever enough to
even know what they are doing.
However, a more silly thing is just simple DOS attacks. If you connect
to the multinet server, then the proper remote end cannot. Which is
simple, not super harmful, but annoying...
You can always configure your router, as I have, to
only forward port 700 traffic from specific Internet hosts. That'll solve the problem
unless somebody also cares enough to go to the trouble of spoofing IPs as well.
True.
Getting off topic - don't I remember that there
was a way to set a password on point-to-point DDCMP circuits? How (or rather, at what
level in the protocol stack) was that implemented ?
There is. I've never used it, but you can set passwords on circuits.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
4:55 p.m.
On 20 Jan 2016, at 15:51, Johnny Billquist <bqt at softjar.se> wrote:
Well, yes, that is true. However, I doubt many would be clever enough to even know what
they are doing.
However, a more silly thing is just simple DOS attacks. If you connect to the multinet
server, then the proper remote end cannot. Which is simple, not super harmful, but
annoying...
This problem has existed with for the bridge and Multinet tunnels since the beginning.
However I doubt most hackers would go through the trouble of learning the precise format
of a DECNET packet encapsulated in UDP/TCP to insert malicious data into our network -
we're just not valuable enough a goal..
Sampsa
4:58 p.m.
On 2016-01-20 16:55, Sampsa Laine wrote:
On 20 Jan 2016, at 15:51, Johnny Billquist <bqt at softjar.se> wrote:
The bridge do not have that problem, no.
Well, yes, that is true. However, I doubt many would be clever enough to even know what
they are doing.
However, a more silly thing is just simple DOS attacks. If you connect to the multinet
server, then the proper remote end cannot. Which is simple, not super harmful, but
annoying...
This problem has existed with for the bridge and Multinet tunnels since the beginning.
However I doubt most hackers would go through the
trouble of learning the precise format of a DECNET packet encapsulated in UDP/TCP to
insert malicious data into our network - we're just not valuable enough a goal..
Agreed that we're likely not a target for purposeful attacks. More
potentially victims of stupidity. Which is why I ask, and is concerned.
Like I said, the bridge is not susceptible to this. Seems Multinet might
be...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:02 p.m.
Seems Multinet might be...
Do what I said - configure your router so it only forwards port 700 for hosts you
recognize.
... unless you're worried about DDoS attacks that are smart enough to spoof the
source IP too. If you're worried about that too, then your paranoia is wasted here
:-)
Bob
5 p.m.
Even random IP addresses, or just random ports?
Passive connections don't care about the incoming port or IP. In fact, Fred and I
accidentally proved this a couple of times when my ISP changed my IP. As long as I had
Fred's correct IP on my active end, Fred's passive end didn't care what my IP
was.
BTW, if exploited properly, that property could come in handy for people with dynamic
IPs.
And along those same lines, for /TCP=LISTEN circuits, the /REMOTE=ip modifier is
ignored.
you can set passwords on circuits.
Well, that might work with TCP circuits then. That'd at least give you some simple
password authentication. I suspect DECnet sends passwords in clear text, though, so
it'd be only trivially secure.
As for DDoS attacks on my DECnet port, it's not something I'm going to lose
sleep over....
Bob
5:08 p.m.
On 2016-01-20 17:00, Robert Armstrong wrote:
Ok. That would confirm it then. But I suspect it do check for UDP
traffic, as it needs to map the packets to the right circuit.
Of course it will be in clear text. :-)
Even random IP
addresses, or just random ports?
Passive connections don't care about the incoming port or IP. In fact, Fred and I
accidentally proved this a couple of times when my ISP changed my IP. As long as I had
Fred's correct IP on my active end, Fred's passive end didn't care what my IP
was. BTW, if exploited properly, that property could
come in handy for people with dynamic IPs.
You still have the problem on the originating side...
Anyway, I realized that for my implementation, I can actually do any
already.
If I create a tcp socket under RSX, I can leave either host or port at
zero, to allow anything, or set it more explicitly. And the tool I wrote
to configure the multinet tunnels allows me to also set this, so I can
put it at any level I want to on the RSX side...
And along those same lines, for /TCP=LISTEN
circuits, the /REMOTE=ip modifier is ignored.
Follows from above, I guess.
you can set
passwords on circuits.
Well, that might work with TCP circuits then. That'd at least give you some
simple password authentication. I suspect DECnet sends passwords in clear text, though,
so it'd be only trivially secure. As for DDoS attacks on my DECnet port, it's not
something I'm going to lose sleep over....
I'm not going to loose any sleep either. It just seems a bit silly when
you can specify all that info, but it is not actually used, and there is
no way we'll get rid of annoying crachers on the internet anyway.
I have about 500 telnet connections per day to Mim, with people trying
to log in as root, ftp, anonymous, apache, and god knows what else. That
is, if their script isn't clever enough to wait for a "user:" prompt, in
which case they are connecting and then nothing happens, and they
disconnect about 20s later.
And then we have all the http requests for wordpress and I don't know
what. The logs on Mim are actually quite funny to read.
Who would have known an RSX system could cause that much fun (for me)
and confusion (for others) on the Internet...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:17 p.m.
BTW, if
exploited properly, that property could come in handy for people with dynamic IPs.
You still have the problem on the originating side...
5:19 p.m.
On 2016-01-20 17:17, Robert Armstrong wrote:
The person with the dynamic IP would be the originating (aka "active") side.
The person with the static IP would be the listening side. Multinet doesn't care
what the IP of the active side might be, so the dynamic IP would not be an issue.
Good point. In that case, it would indeed improve life.
BTW, if exploited properly, that property could
come in handy for people with dynamic IPs.
You still have the problem on the
originating side... Of course, you're router would have to forward
all port 700 traffic this way so maybe you're back to DDoS nightmares...
:-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:22 p.m.
I have about 500 telnet connections per day to Mim, ...
Put your telnet on a non-standard port. All the bots and scripts are hardwired to
standard port numbers.
I only open ssh, and I use a non-standard port number. I basically never get any break
in attempts. Sure, if somebody did a port scan they could find it, but none of the bots
do that and the human hackers who might be smart enough to figure it out are also smart
enough not to care about my machines.
I also only permit public/private key authentication with external ssh connections, so
trying to guess passwords is a non-starter.
BTW, do you have ssh for RSX too??
Bob
5:27 p.m.
I don?t need to be faster than the bear, I just need to be faster than you.
They don?t need or care to be smart enough because it?s not worth the effort for them. :)
I so need to implement key auth only.
-brian
On Jan 20, 2016, at 11:22 AM, Robert Armstrong <bob
at jfcl.com> wrote:
I have about 500 telnet connections per day to
Mim, ...
Put your telnet on a non-standard port. All the bots and scripts are hardwired to
standard port numbers.
I only open ssh, and I use a non-standard port number. I basically never get any break
in attempts. Sure, if somebody did a port scan they could find it, but none of the bots
do that and the human hackers who might be smart enough to figure it out are also smart
enough not to care about my machines.
I also only permit public/private key authentication with external ssh connections, so
trying to guess passwords is a non-starter.
BTW, do you have ssh for RSX too??
Bob
5:35 p.m.
And if you?ve spent any time on the internet you know that?s not exactly a high bar. :)
-brian
On Jan 20, 2016, at 11:34 AM, Robert Armstrong <bob
at jfcl.com> wrote:
I don't need to be faster than the bear, I
just need to be faster than you.
Yep, I don't need to be the smartest guy on the Internet - I just need to be smarter
than 90% of the other guys on the Internet :-)
Bob
6:01 p.m.
On 2016-01-20 17:22, Robert Armstrong wrote:
If I wanted to hide things, sure.
I have about
500 telnet connections per day to Mim, ...
Put your telnet on a non-standard port. All the bots and scripts are hardwired to
standard port numbers. I only open ssh, and I use a non-standard port
number. I basically never get any break in attempts. Sure, if somebody did a port scan
they could find it, but none of the bots do that and the human hackers who might be smart
enough to figure it out are also smart enough not to care about my machines.
Like I said, this is a source of amusement to me. I don't mind. And
since occasionally an honest tourist also might happen to pass by, I do
not want to hide things. Mim is a public service.
In fact, if you telnet to mim.update.uu.se, you'll get information on
how to log in at connection time. Except bots are too stupid to
understand such information. :-)
I also only permit public/private key
authentication with external ssh connections, so trying to guess passwords is a
non-starter.
BTW, do you have ssh for RSX too??
Nope. I don't think I'm going to try and implement it either. While an
emulated PDP-11 probably is fast enough, writing the code to do this in
a limited memory space just isn't my idea of fun. Besides, I'm not a
math genius, and trying to understand all of that would be a lot of
headache...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
9:12 p.m.
SSH to the VAX is just painful (imo)... I can't imagine what is like on a
PDP/RSX ?!?
On Wed, Jan 20, 2016 at 11:22 AM, Robert Armstrong <bob at jfcl.com> wrote:
I have about
500 telnet connections per day to Mim, ...
Put your telnet on a non-standard port. All the bots and scripts are
hardwired to standard port numbers.
I only open ssh, and I use a non-standard port number. I basically
never get any break in attempts. Sure, if somebody did a port scan they
could find it, but none of the bots do that and the human hackers who might
be smart enough to figure it out are also smart enough not to care about my
machines.
I also only permit public/private key authentication with external ssh
connections, so trying to guess passwords is a non-starter.
BTW, do you have ssh for RSX too??
Bob
9:30 p.m.
On Jan 20, 2016, at 3:28 PM, Robert Armstrong <bob
at jfcl.com> wrote:
That makes sense, there are bignum operations going on at that point. You could improve
matters a bit, at the expense of somewhat reduced security (at least against three letter
agencies) by reducing the public key size. 512 bits is pretty decent, though no longer
considered strong enough for serious work.
paul
SSH to the VAX is just painful (imo)...
I don?t have any problems once I?m logged in, but the initial key verification takes
forever on a VAX. On an 800Mhz Alpha it only takes a second.
9:38 p.m.
by reducing the public key size.
Yeah, I actually use the same key on all my servers. Don't tell anybody :-) On a
modern PC, even a slow one, the delay is imperceptible. The VAX will just have to live
with it.
I use an ssh client on my Android tablet called "juice ssh". Works great, but
it could never log into the VAX because the client would time out before the VAX could
finish the handshake. I sent 'em an email to complain, and they jacked up the timeout
just for my VAX :-)
Bob
9:56 p.m.
I was using eliptical-curve on my VAX ...
nah... just kidding... sticking with telnet here so you guys can sniff the
traffic over the bridge... and I can enjoy the VAX. Otherwise, I'm not
worried about the internet - there've been move vulnerabilities in SSH
lately than telnet (except for the HUGE SUN/Solaris one a few years ago) -
granted, I think those were x86 specific ?!?! In any case an ssh-attach
against a VAX would be boring (waiting for handshake). I'd rather think an
attacker would try to DoS / overwhelm the VAX with a few hundred ssh
connects.
Agreed, AXP / IA64... ssh seems suitable.
Off topic - does anyone have VAX cd's laying around online? Looking for
MMS to compile `wget`.
Joe
On Wed, Jan 20, 2016 at 3:38 PM, Robert Armstrong <bob at jfcl.com> wrote:
by reducing the public key size.
Yeah, I actually use the same key on all my servers. Don't tell anybody
:-) On a modern PC, even a slow one, the delay is imperceptible. The VAX
will just have to live with it.
I use an ssh client on my Android tablet called "juice ssh". Works
great, but it could never log into the VAX because the client would time
out before the VAX could finish the handshake. I sent 'em an email to
complain, and they jacked up the timeout just for my VAX :-)
Bob
10:07 p.m.
An HTML attachment was scrubbed...
URL:
<http://lists.sonic.net/pipermail/hecnet-list/attachments/20160120/abb6e964/attachment.html>
10:09 p.m.
An HTML attachment was scrubbed...
URL:
<http://lists.sonic.net/pipermail/hecnet-list/attachments/20160120/bc56d7c4/attachment.html>
10:15 p.m.
An HTML attachment was scrubbed...
URL:
<http://lists.sonic.net/pipermail/hecnet-list/attachments/20160120/8f6f2979/attachment-0001.html>
10:20 p.m.
An HTML attachment was scrubbed...
URL:
<http://lists.sonic.net/pipermail/hecnet-list/attachments/20160120/f2bf30b1/attachment.html>
10:36 p.m.
Thanks!! - pulling them now from WOPR::
On Wed, Jan 20, 2016 at 4:20 PM, <hvlems at zonnet.nl> wrote:
Logon to node OZON
Usercode HECNET
No password
Unzip the savesets with the "-V"? switch
Hans
Verzonden vanaf mijn BlackBerry 10-smartphone.
*Van: *Joe Ferraro
*Verzonden: *woensdag 20 januari 2016 21:56
*Aan: *hecnet at Update.UU.SE
*Beantwoorden: *hecnet at Update.UU.SE
*Onderwerp: *Re: [HECnet] DECnet over IP
I was using eliptical-curve on my VAX ...
nah... just kidding... sticking with telnet here so you guys can sniff the
traffic over the bridge... and I can enjoy the VAX. Otherwise, I'm not
worried about the internet - there've been move vulnerabilities in SSH
lately than telnet (except for the HUGE SUN/Solaris one a few years ago) -
granted, I think those were x86 specific ?!?! In any case an ssh-attach
against a VAX would be boring (waiting for handshake). I'd rather think an
attacker would try to DoS / overwhelm the VAX with a few hundred ssh
connects.
Agreed, AXP / IA64... ssh seems suitable.
Off topic - does anyone have VAX cd's laying around online? Looking for
MMS to compile `wget`.
Joe
On Wed, Jan 20, 2016 at 3:38 PM, Robert Armstrong <bob at jfcl.com> wrote:
by reducing the public key size.
Yeah, I actually use the same key on all my servers. Don't tell
anybody :-) On a modern PC, even a slow one, the delay is imperceptible.
The VAX will just have to live with it.
I use an ssh client on my Android tablet called "juice ssh". Works
great, but it could never log into the VAX because the client would time
out before the VAX could finish the handshake. I sent 'em an email to
complain, and they jacked up the timeout just for my VAX :-)
Bob
10:44 p.m.
An HTML attachment was scrubbed...
URL:
<http://lists.sonic.net/pipermail/hecnet-list/attachments/20160120/00873310/attachment-0002.html>
10:22 p.m.
An HTML attachment was scrubbed...
URL:
<http://lists.sonic.net/pipermail/hecnet-list/attachments/20160120/614aa717/attachment-0002.html>
11:14 p.m.
On 2016-01-20 21:56, Joe Ferraro wrote:
I was using eliptical-curve on my VAX ...
nah... just kidding... sticking with telnet here so you guys can sniff
the traffic over the bridge... and I can enjoy the VAX.
telnet don't pass over the bridge. :-)
But I'm still not going to implement ssh on RSX quite yet. If someone is
interested in the protocol side, I could help out with the OS side...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:08 p.m.
On 01/20/2016 03:38 PM, Robert Armstrong wrote:
Oh, as a user of both JuiceSSH and VAXen, thank you!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
by reducing
the public key size.
Yeah, I actually use the same key on all my servers. Don't tell anybody :-) On a
modern PC, even a slow one, the delay is imperceptible. The VAX will just have to live
with it.
I use an ssh client on my Android tablet called "juice ssh". Works great,
but it could never log into the VAX because the client would time out before the VAX could
finish the handshake. I sent 'em an email to complain, and they jacked up the timeout
just for my VAX :-)
5:02 p.m.
On Jan 20, 2016, at 10:51 AM, Johnny Billquist <bqt
at softjar.se> wrote:
...
Yes, on any point to point circuit, which Multinet is. That is implemented at the routing
layer; the password exchange is done as part of the routing layer initialization exchange
(Routing Init and Routing Verify messages). See the routing architecture spec.
Note that this is a plain text password, so all the usual security limitations of
plaintext passwords apply. Also, the way it is set as the circuit attribute is not
specified in the standard -- a strange omission because the feature itself IS standardized
at the protocol level.
paul
Getting off topic - don't I remember that
there was a way to set a password on point-to-point DDCMP circuits? How (or rather, at
what level in the protocol stack) was that implemented ?
There is. I've never used it, but you can set passwords on circuits.
5:14 p.m.
On 2016-01-20 17:12, Brian Hechinger wrote:
Indeed. And the same is true for Mim. If people just ask, they'll get an
account. And still people try to crach it instead. It's hilarious.
I guess we're an echo from a past age, when the internet was more open...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 20, 2016, at 10:45 AM, Robert Armstrong
<bob at jfcl.com
<mailto:bob at jfcl.com>> wrote:
You don?t need to hack HECnet. You just need to ask nicely and we?ll let
you in. :) Or how do they authenticate? IP address only?
Authenticate?? We don't need no stinking authentication :-)
4:19 p.m.
P.S. FWIW, you can also change the port number for UDP too if you don't like the
default of 700. In the case of UDP, though, I think you'd have to use the same port
number on both ends. For TCP it's only the listening (passive) end port number that
matters.
Bob
4:36 p.m.
On 2016-01-20 16:19, Robert Armstrong wrote:
P.S. FWIW, you can also change the port number for
UDP too if you don't like the default of 700. In the case of UDP, though, I think
you'd have to use the same port number on both ends. For TCP it's only the
listening (passive) end port number that matters.
I think I might have over-designed my implementation. :-)
I can control both the local and remote port for all my connections. And
I also need the incoming packets to fully match. Which might be a
problem with TCP then, as VMS Multinet do not actually control the
originating TCP port... So it will be tricky to specify what it will be.
I guess I can let incoming connections accept any remote port.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
4:44 p.m.
On Jan 20, 2016, at 10:36 AM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2016-01-20 16:19, Robert Armstrong wrote:
That would make sense. The typical practice, if you want to limit who can connect, is to
limit by IP address, not port.
paul
P.S. FWIW, you can also change the port number
for UDP too if you don't like the default of 700. In the case of UDP, though, I think
you'd have to use the same port number on both ends. For TCP it's only the
listening (passive) end port number that matters.
I think I might have over-designed my implementation. :-)
I can control both the local and remote port for all my connections. And I also need the
incoming packets to fully match. Which might be a problem with TCP then, as VMS Multinet
do not actually control the originating TCP port... So it will be tricky to specify what
it will be.
I guess I can let incoming connections accept any remote port.
3028
days inactive
3028
days old
43 comments
9 participants
participants (9)
-
bob＠jfcl.com -
bqt＠softjar.se -
drb＠msu.edu -
hvlems＠zonnet.nl -
jferraro＠gmail.com -
mcguire＠neurotica.com -
Paul_Koning＠Dell.com -
sampsa＠mac.com -
wonko＠4amlunch.net