How to avoid port forwarding warning with multiple logins?

[Chris Green]

I use ssh (a lot!) to connect from my laptop machine to my desktop
machine at home. I often have several logins running at the same
time, for example reading mail with one, reading Usenet news in
another, checking files in a third, etc.

I have a RemoteForward set up to allow my desktop machine to send files
to an rsync daemon process on the laptop. This means that on the
second (and any more) connections from the laptop to the desktop I get
the message "Warning: remote port forwarding failed for listen port .."
after the login.

While this isn't all that important, no harm is done, I just find it a
bit irritating so I'd like to get rid of it if I can.

One way to avoid the warning message is to set up ssh with 'ControlMaster
auto' but that has its own irritation of not being able to log out of
the 'master' connection until all the others have disconnected.

Is there any other way to get rid of this (very minor) annoyance?

--
Chris Green
·

[William Unruh]

On 2020-09-14, Chris Green <c...@isbd.net> wrote:
> I use ssh (a lot!) to connect from my laptop machine to my desktop
> machine at home. I often have several logins running at the same
> time, for example reading mail with one, reading Usenet news in
> another, checking files in a third, etc.
>
> I have a RemoteForward set up to allow my desktop machine to send files
> to an rsync daemon process on the laptop. This means that on the
> second (and any more) connections from the laptop to the desktop I get
> the message "Warning: remote port forwarding failed for listen port .."
> after the login.

What it sounds to me like is that when you log into your destop from
your laptop, you run a program to allow the destop to connect through a
port on the desktop to your laptop. However, after the first time, that
port is already in use so that program tells you. Instead you could,
when you switch on the laptop or log in on the laptop, run a program on
the laptop to connect to the desktop and open a port on the desktop to
send the rsync stuff to the laptop. But make sure that that little
program checks to make sure that that port is open. If there is already
something connected do not try to rerun.
Or you could set up a user, with public key logon onto your desktop on
the desktop and laptop, and, when the laptop boots up, it automatically
connects via that user (for example in /etc/rc.d/rc.local) and now the
port is open for the rsync (I use this as a mail trasport procedure)
eg, in rc.local is the line

su sshuser -c " autossh -f -M0 -nNT -L 9154:desktop:22 desktop "

sshuser is that common user, authssh is a program which, if the ssh link
goes down, will try to restart that ssh connection. 9154 is some random
number which will be the port on the desktop through which you connect
to the laptop, 22 is the ssh port on the laptop, and the computer name
desktop in in /etc/hosts.

[Grant Taylor]

On 9/14/20 4:36 AM, Chris Green wrote:
> Is there any other way to get rid of this (very minor) annoyance?

Have you considered slightly altering how you use the master connection?

Specifically, try spawning a background master connection and ignoring
it. Then do everything else with secondary connections?

E.g. ssh -fnN <host>

Then all other connections are secondary to the multiplex master.

The main goal is to make it so that you don't experience the apparent
hang when existing the master while others are using the master.



--
Grant. . . .
unix || die

[Chris Green]

William Unruh <un...@invalid.ca> wrote:
> On 2020-09-14, Chris Green <c...@isbd.net> wrote:
> > I use ssh (a lot!) to connect from my laptop machine to my desktop
> > machine at home. I often have several logins running at the same
> > time, for example reading mail with one, reading Usenet news in
> > another, checking files in a third, etc.
> >
> > I have a RemoteForward set up to allow my desktop machine to send files
> > to an rsync daemon process on the laptop. This means that on the
> > second (and any more) connections from the laptop to the desktop I get
> > the message "Warning: remote port forwarding failed for listen port .."
> > after the login.
>
> What it sounds to me like is that when you log into your destop from
> your laptop, you run a program to allow the destop to connect through a
> port on the desktop to your laptop. However, after the first time, that
> port is already in use so that program tells you.

Exactly, "that program" being ssh on subsequent logins.

> Instead you could,
> when you switch on the laptop or log in on the laptop, run a program on
> the laptop to connect to the desktop and open a port on the desktop to
> send the rsync stuff to the laptop. But make sure that that little
> program checks to make sure that that port is open. If there is already
> something connected do not try to rerun.

It would have to loop and wait for network as my laptop isn't always
on the LAN or internet. Thus it would have to be a while loop started
when the laptop GUI starts up which then waits for a connection to
appear. It's a possible solution.

> Or you could set up a user, with public key logon onto your desktop on
> the desktop and laptop, and, when the laptop boots up, it automatically
> connects via that user (for example in /etc/rc.d/rc.local) and now the
> port is open for the rsync (I use this as a mail trasport procedure)
> eg, in rc.local is the line
>
> su sshuser -c " autossh -f -M0 -nNT -L 9154:desktop:22 desktop "
>
> sshuser is that common user, authssh is a program which, if the ssh link
> goes down, will try to restart that ssh connection. 9154 is some random
> number which will be the port on the desktop through which you connect
> to the laptop, 22 is the ssh port on the laptop, and the computer name
> desktop in in /etc/hosts.
>

Yes, I use autossh from a headless BeagleBone Black computer. However
I'm not keen on having a key without a passphrase on the laptop. It
would mean that anyone finding/stealing my laptop would have access to
my desktop machine.

--
Chris Green
·

[Chris Green]

This is a possible solution, but how would one do the 'ssh -fnN <host>'?

It's not very handy to have to remember to execute an extra command
before doing the first normal ssh, even if the extra command was
wrapped up in a script.

I *guess* one could wrap it up in a LocalCommand, I've done things
like that before, it involves strange convolutions because you have to
turn PermitLocalCommand off in the thing that's run by the
LocalCommand otherwise it repeatedly calls itself.

In fact I think the neatest way might be the following:-

Remove the RemoteForward from my default ssh login from laptop to desktop

Add a Local Command something like
LocalCommand ssh -fnN -o PermitLocalCommand=no -R xxxxx:localhost:yyyyy <desktop>

Enable ControlMaster auto


With ControlMaster the LocalCommand only gets executed once, when the
connection is first set up. This will open the reverse tunnel just
once as required.

I'll try it and report on success/failure in a while.

--
Chris Green
·

[William Unruh]

Well, if your laptop is stolen you would presumable know about it, and
could remove the laptop key from .ssh/authorized-hosts. Or you could run
the autossh line when you log into your computer. One of the reasons I
suggested that you use a special user is that you could restrict the
ability of that user to do anything but run that ssh link. Thus the
access the thief got would be pretty limited.

>

[Grant Taylor]

On 9/15/20 4:11 PM, William Unruh wrote:
> Well, if your laptop is stolen you would presumable know about it,
> and could remove the laptop key from .ssh/authorized-hosts.

Conceptually, this sounds acceptable. However, if you're traveling and
your notebook is stolen, you'll probably find it's somewhat difficult to
log into systems and remove said key(s) from authorized_hosts.
Especially on systems that require a key to log in, not accepting passwords.

I prefer to rely on the from="..." stanzas to indicate where the key can
be used from. So even if someone does have the key, and manages to
brute force the passphrase, they quite likely can't use it.

> Or you could run the autossh line when you log into your computer. One
> of the reasons I suggested that you use a special user is that you
> could restrict the ability of that user to do anything but run that
> ssh link. Thus the access the thief got would be pretty limited.

Crossing user contexts makes a number of things ... more difficult.

[Grant Taylor]

On 9/15/20 2:43 AM, Chris Green wrote:
> This is a possible solution, but how would one do the 'ssh -fnN
> <host>'?

You could simply run the command. ;-)

But that might not be convenient.

> It's not very handy to have to remember to execute an extra command
> before doing the first normal ssh, even if the extra command was
> wrapped up in a script.

You could do a few different things.

1) Some sort of program that automatically establishes the background
connection for you. -- I've seen a few.
2) A short cut / wrapper script around command that connects to the
host. e.g.: alias <hostname>="ssh -fnN <hostname>; \ssh <hostname>"
(or a comparable script).
3) Leveraging a custom proxy command script that does something similar
to the alias above and / or checks the status of the background connection.

I would probably go with the ProxyCommand as it moves the management of
the master command to a script where I have better control than inside
of OpenSSH's capability. E.g. I could check the existence of the socket
file, and establish the background connection if the socket file doesn't
exist.

I also feel like the ProxyCommand is relatively easy to interface with
OpenSSH. Establish the data path somehow and hand it off to the OpenSSH
client. I think that it's convenient.

> I *guess* one could wrap it up in a LocalCommand, I've done things
> like that before, it involves strange convolutions because you have to
> turn PermitLocalCommand off in the thing that's run by the LocalCommand
> otherwise it repeatedly calls itself.

I don't think that LocalCommand is a good solution. Primarily because
LocalCommand seems to run /after/ the connection is established.

I've never needed to disable the PermitLocalCommand. I've always done
other things to avoid undesired recursive loops.

> In fact I think the neatest way might be the following:-
>
> Remove the RemoteForward from my default ssh login from laptop to desktop
>
> Add a Local Command something like
> LocalCommand ssh -fnN -o PermitLocalCommand=no -R xxxxx:localhost:yyyyy <desktop>
>
> Enable ControlMaster auto

This is where and why I'd prefer to use a ProxyCommand wrapper script.

This is where I stopped drafting the reply and spent more time thinking
about how to do something with OpenSSH than I've needed to do in a very
long time.

...

It's now almost 12 hours later and I think I have an idea. I'm fairlyl
certain that I would still use the ProxyCommand to do this.

Remember, the purpose of the ProxyCommand is to establish the network
connectivity instead of SSH managing the TCP connection therefor.

So ... with that in mind, I think the proxy command could manage a
background connection, establishing it when necessary, and leverage said
background connection as a conduit to pass traffic over for the ssh
connection for the command being run.

Host problemhost
ProxyCommand /path/to/specialSSHshim

Where specialSSHshim:

1) checks to see if there is a socket for a multiplexed connection,
establishing it if there is not one.
2) Re-uses the multiplexed connection for something akin to an ssh -W to
pass traffic between the local ssh client and the remote host.

#1 is relatively easy to do:

if [ ! -S /path/to/socket ]; then
ssh -o ControlMaster=yes -o ControlPath=/path/to/socket -fnN $BASTION
fi

#2 would then do something like the following:

ssh -o ControlPath=/path/to/socket $BASTION -W $RemoteHost:$RemotePort

I would need to spend some time doing more than mocking things up to
confirm if this would work or not and to determine if it's possible for
$BASTION to be the problemhost or something else like problemhost-helper.

> With ControlMaster the LocalCommand only gets executed once, when
> the connection is first set up. This will open the reverse tunnel
> just once as required.

True.

I was thinking that you were trying to press LocalCommand into
establishing the background multiplexed connection. Something that I
think will be difficult to do. Though you might be able to run the
proper command(s) to only establish the RemoteForward on the initial
background multiplexing connection.

> I'll try it and report on success/failure in a while.

Cool. Please do.

[Chris Green]

William Unruh <un...@invalid.ca> wrote:
> > Yes, I use autossh from a headless BeagleBone Black computer. However
> > I'm not keen on having a key without a passphrase on the laptop. It
> > would mean that anyone finding/stealing my laptop would have access to
> > my desktop machine.
>
> Well, if your laptop is stolen you would presumable know about it, and

But almost certainly not soon enough. I agree it's not a huge
security hole but it is just one more weakness.

> could remove the laptop key from .ssh/authorized-hosts. Or you could run
> the autossh line when you log into your computer. One of the reasons I
> suggested that you use a special user is that you could restrict the
> ability of that user to do anything but run that ssh link. Thus the
> access the thief got would be pretty limited.
>

Yes, that would work I suppose, but it's getting more complex. :-)

--
Chris Green
·

[William Unruh]

Not sure what you mean.
If I open a path you desktop to your laptop as user A, then user B can
use that path on the desktop to go to your laptop. I do it all the time.

user a on compute 1 opens a path between compter 2 to 1 by logging in on
1 and running that autossh command Then user B on 2 can use that to ssh
into 1.

In particular user B can use rsync to transfer files from 2 onto 1.
So what problem do you forsee? What do you mean by "Crossing user
contexts"?



>
>
>

[William Unruh]

How is it more complex? You set it up once and it is then set up forever.

On the laptop you can put it into rc.local as I said.
su sshtunnel -c "autossh....."
where user sshtunnel is set up so it has minial priviledges on the
desktop.
>

[Chris Green]

Hmm, well I tried, but it didn't work after a couple of tries and
revisions so I gave up. I've found a much simpler, if not quite so
perfect, solution - I've added 'LogLevel ERROR' so that warning
messages no longer appear.

--
Chris Green
·

[Grant Taylor]

On 9/16/20 2:57 AM, William Unruh wrote:
> Not sure what you mean.

I'm referencing group membership to control access to files. So if
"grant1" is allowed to access a file, but I us an alternate user,
"grant2" to connect to the system, then I can't directly access the
necessary file.

> If I open a path (from) you(r) desktop to your laptop as user A,

> then user B can use that path on the desktop to go to your laptop. I
> do it all the time.

"path" can mean multiple things in this context. It can be the network
communications path (TCP / ProxyCommand) or it can be who is allowed to
log in over an SSH connection. It's quite possible that both A and B
can establish a TCP connection but that only A will be allowed to log in.

> user a on compute 1 opens a path between compter 2 to 1 by logging
> in on 1 and running that autossh command Then user B on 2 can use
> that to ssh into 1.
>
> In particular user B can use rsync to transfer files from 2 onto 1.

Just because B can start an SSH session from 2 to 1 does not mean that B
can log into 1. It's entirely possible that the SSH daemon running on 1
will prevent B from logging into 1, thus stopping B in their tracks.

> So what problem do you forsee?

Many.

> What do you mean by "Crossing user contexts"?

See above.

[William Unruh]

On 2020-09-16, Grant Taylor <gta...@tnetconsulting.net> wrote:
> On 9/16/20 2:57 AM, William Unruh wrote:
>> Not sure what you mean.
>
> I'm referencing group membership to control access to files. So if
> "grant1" is allowed to access a file, but I us an alternate user,
> "grant2" to connect to the system, then I can't directly access the
> necessary file.

No, that is not what I mean. Set up a user named sshtunnel on both
systems, laptop and desktop. SEt it up so that sshtunnel can log into
desktop with public key. Then run the autossh .... as user sshtunnel
You NEVER again use the user sshtunnel. In particular you do not use
sshtunnel to log onto the desktop. You use your grant2 to log on and do
everything you want.

The autossh will have opened a local port on the desktop, lets say it is
port 7952. When you want to run rsync on desktop to trasfer stuff to the
laptop you do not connect to laptop, you connect to localhost on the
desktop and port 7952. You can do this as any user on the destop You do
not need to use user sshtunnel.

ssh -p 7952 localhost or ssh -p 7952 127.0.0.1
will connect you to the laptop.
If you want to rsync, then
rsync -av --progress --rsh="ssh -p 7952" /file/you/want/to/tansfer localhost:/file/location/on/laptop/

>
>> If I open a path (from) you(r) desktop to your laptop as user A,
>> then user B can use that path on the desktop to go to your laptop. I
>> do it all the time.
>
> "path" can mean multiple things in this context. It can be the network
> communications path (TCP / ProxyCommand) or it can be who is allowed to
> log in over an SSH connection. It's quite possible that both A and B
> can establish a TCP connection but that only A will be allowed to log in.
>
>> user a on compute 1 opens a path between compter 2 to 1 by logging
>> in on 1 and running that autossh command Then user B on 2 can use
>> that to ssh into 1.
>>
>> In particular user B can use rsync to transfer files from 2 onto 1.
>
> Just because B can start an SSH session from 2 to 1 does not mean that B
> can log into 1. It's entirely possible that the SSH daemon running on 1
> will prevent B from logging into 1, thus stopping B in their tracks.

Yes. And? Of course if you have set up your laptop to disallow B logging
in then B cannot log in. But if you want B to be able to log in, or to
transfer files via rsync, then let B log in!

>
>> So what problem do you forsee?
>
> Many.

So far you have not mentioned even one.

>
>> What do you mean by "Crossing user contexts"?
>
> See above.

We seem to be talking completely past each other.
Perhaps you should try what I suggest and see how it works, and whether
the potential problems you seem to be secretly forseeing are actually
problems.

ssh tunnelling in this context simply means that you can set up the two
systems so that you can ssh from the desktop to the laptop even if the
laptop is behind a NAT router, and you cannot access it from the net and
use it for things like rsync files from the desktop to the laptop. That
was the problem I thought you were trying to solve, but your solution
had undesirable features.
What I am giving you is a way to accomplish what I thought you wanted
without those undesireable features, which I use daily, and have never
run into problems. But you seem to be misinterpreting what I say and
forseeing problems.

To again go through the procedure.

On both desktop and laptop install a new user sshtunnel. Set up
sshtunnel with a public key on the laptop, and place the public part of
that key (eg the contents of ~sshtunnel/.ssh/id_rsa.pub on the laptop) into ~sshtunnel/.ssh/authorized_keys

Now, log into sshtunnel (or use sudo to log into sshtunnel) and run
autossh -f -M0 -nN -R 7952:localhost:22 desktop.domain.name

This will set up a tunnel from the desktop to the laptop with
localhost -p 7952 being a direct connection from the desktop to port 22
on the laptop. Now anyone can use that to connect to the port 22 on the
laptop to connect via ssh to the laptop
Ie,
ssh -p 7952 127.0.0.1
would be the same as doing
ssh <IP address of laptop>.

But of course that laptop usually does not have a internet address-- it
is hidden behind a NAT router, with no way to get a packet to the
laptop.

This would be true for anyone, not just user sshtunnel, on the desktop.
This includes user grant2.

If instead you wanted to sent mail to the laptop via port 25 on the
laptop, you could create a tunnel from some other port on the desktop
(ie not 7952 since that is used for ssh in my example) to port 25 rathr
than 22.

Note that you do NOT have to use public key to do all this. You could do
everything without public key logon from laptop to desktop. In that
case, ssh would ask you for a password when it attempted to connect as
user sshtunnel.
Exactly what would happen if the ssh connection dropped and autossh
restarted it I do not know, since it would be hard for ssh, running in
the background, to ask for a password. But I leave you to figure that
out.

If someone got your laptop, the most they could do is to log onto your
desktop as user sshtunnel. I would assume you have set up your desktop
so that user sshtunnel cannot do much.

Note that you would not need to use autossh, but could do it directly
with ssh itself. It just would not restart the tunnel if something
caused the connection to drop. Then you could log in as sshtunnel, run
the ssh command to open the tunnel, and if the connection went down, you
would have to bring it back up yourself.

[Grant Taylor]

On 9/16/20 12:54 PM, William Unruh wrote:
> No, that is not what I mean. Set up a user named sshtunnel on both
> systems, laptop and desktop. SEt it up so that sshtunnel can log into
> desktop with public key. Then run the autossh .... as user sshtunnel
> You NEVER again use the user sshtunnel. In particular you do not use
> sshtunnel to log onto the desktop. You use your grant2 to log on and
> do everything you want.

That's considerably different than what I thought you were saying.

I'm now understanding you to be using this other user purely as an
account that an SSH connection is established with / as and that said
SSH connection is /only/ being used for port forwarding to enable
connection to the SSH daemon on the other end. In effect, (ab)using SSH
as a VPN via port-forward.

> The autossh will have opened a local port on the desktop, lets say
> it is port 7952. When you want to run rsync on desktop to trasfer
> stuff to the laptop you do not connect to laptop, you connect to
> localhost on the desktop and port 7952. You can do this as any user
> on the destop You do not need to use user sshtunnel.

Agreed.

> ssh -p 7952 localhost or ssh -p 7952 127.0.0.1 will connect you to
> the laptop. If you want to rsync, then rsync -av --progress --rsh="ssh
> -p 7952" /file/you/want/to/tansfer localhost:/file/location/on/laptop/

I believe I understand what you're suggesting. I wouldn't go about it
quite like that though.

First, I'd do as much of this as possible via the OpenSSH client
configuration file so as to avoid complicating commands, e.g.
--rsh="ssh..." for rsync.

Second, I'd probably use HostKeyAlias to avoid issues related to having
different /host/ keys seen at different ports on the same IP (127.0.0.1
/ ::1).

Third, I'd probably have the entry for the notebook use a ProxyCommand
that would try to connect to the port on localhost and then fall back to
a TCP connection. That way, the same host and config could be used for
both methods. And it would be abstracted away in the OpenSSH client
config file to avoid command line ... mess.

> Yes. And? Of course if you have set up your laptop to disallow B
> logging in then B cannot log in. But if you want B to be able to log
> in, or to transfer files via rsync, then let B log in!

As you indicated, we seem to have been talking about two different things.

I was more focused on the security impact of allowing Alice log into
Bob's machine but not allowing Malroy log into Bob's machine when both
Alice and Malroy initiate their connections from a common system.

> So far you have not mentioned even one.

I have, but you've not understood them because we seem to have been
talking two completely different contexts.

> We seem to be talking completely past each other.

Agreed.

> Perhaps you should try what I suggest and see how it works, and
> whether the potential problems you seem to be secretly forseeing are
> actually problems.

Understanding that you aren't suggesting that someone split their
activities across multiple accounts (see above), many of the concerns
are null and void.

I touched on the issues with multiple host keys on the same IP above.

I've also touched on command line complexity and what the OpenSSH client
config file can do to help with that.

> ssh tunnelling in this context simply means that you can set up the
> two systems so that you can ssh from the desktop to the laptop even
> if the laptop is behind a NAT router, and you cannot access it from
> the net and use it for things like rsync files from the desktop to
> the laptop. That was the problem I thought you were trying to solve,
> but your solution had undesirable features.

You seem to have conflated the OP and myself. I'm not the person asking
for a solution.

You responded to my response to the OP indicating that logging in and
disabling keys after a system is stolen is more problematic than first
meets the eye.

I suggested the OP use the from="..." stanza in the authorized_keys file
so that keys are only allowed to be used from the specified location(s),
be it IPs and / or networks. That way if (when) the key is compromised
it still can't be used from a non-authorized location.

> What I am giving you is a way to accomplish what I thought you wanted
> without those undesireable features, which I use daily, and have
> never run into problems. But you seem to be misinterpreting what I
> say and forseeing problems.

As you indicated, we were talking about two different things.

[William Unruh]

> On 9/16/20 12:54 PM, William Unruh wrote:

.....

>> No, that is not what I mean. Set up a user named sshtunnel on both
>> systems, laptop and desktop. SEt it up so that sshtunnel can log into
>> desktop with public key. Then run the autossh .... as user sshtunnel
>> You NEVER again use the user sshtunnel. In particular you do not use
>> sshtunnel to log onto the desktop. You use your grant2 to log on and
>> do everything you want.
>
> That's considerably different than what I thought you were saying.

>
> I'm now understanding you to be using this other user purely as an
> account that an SSH connection is established with / as and that said
> SSH connection is /only/ being used for port forwarding to enable
> connection to the SSH daemon on the other end. In effect, (ab)using SSH
> as a VPN via port-forward.

Not sure why that is an abuse, but OK.

>
> First, I'd do as much of this as possible via the OpenSSH client
> configuration file so as to avoid complicating commands, e.g.
> --rsh="ssh..." for rsync.
>
> Second, I'd probably use HostKeyAlias to avoid issues related to having
> different /host/ keys seen at different ports on the same IP (127.0.0.1
> / ::1).

Yes, that could be problematic I guess. I tend to always use IPV4 so it
did not even cross my mind.

>
> Third, I'd probably have the entry for the notebook use a ProxyCommand
> that would try to connect to the port on localhost and then fall back to
> a TCP connection. That way, the same host and config could be used for
> both methods. And it would be abstracted away in the OpenSSH client
> config file to avoid command line ... mess.

Setting up and alias in bashrc or putting it into rc.local makes the
mess a one time only problem.

>
>
> I suggested the OP use the from="..." stanza in the authorized_keys file
> so that keys are only allowed to be used from the specified location(s),
> be it IPs and / or networks. That way if (when) the key is compromised
> it still can't be used from a non-authorized location.

The problem with a laptop is that it is liable to connect from all over
the world. I may be in Germany one day and in Taiwan a few days later,
and in Texas the next week and all of them behind a NAT router.
Ie, there is no location or port for my laptop.
Which is one of the reasons I want the reverse tunnel into the laptop.

[Grant Taylor]

On 9/16/20 1:58 PM, William Unruh wrote:
> Not sure why that is an abuse, but OK.

It's decidedly not using an encrypted remote interactive terminal
connection.

That being said, I'm known for abusing tools like this. I believe in
making them do my bidding.

I /might/ contemplate a more traditional VPN with routing instead of
relying on port forwarding. I would probably end up using SSH's ability
to be an L3 routed VPN. (WAY more than just port forwarding.)

> Yes, that could be problematic I guess. I tend to always use IPV4 so
> it did not even cross my mind.

I take it that you don't ssh to 127.0.0.1 very often to see the issue
with 127.0.0.1:22 having a different host key than 127.0.0.1:7952 or any
other ports forwarded to other systems.

> Setting up and alias in bashrc or putting it into rc.local makes the
> mess a one time only problem.

It may make it one time problem while entering commands at the shell
prompt. But it doesn't do anything for other commands, e.g. rsync, that
may need the same data, or running commands from within programs, e.g.
vim's !... command. All of those not directly in the shell environments
will still suffer from needing the additional data.

Conversely putting as much as possible in the OpenSSH client
configuration file means that everything will benefit from it.

> The problem with a laptop is that it is liable to connect from all
> over the world. I may be in Germany one day and in Taiwan a few days
> later, and in Texas the next week and all of them behind a NAT router.
> Ie, there is no location or port for my laptop. Which is one of the
> reasons I want the reverse tunnel into the laptop.

That's a valid potential problem. Though my experience is that a
minority of the users have the same problem. Most will travel within a
state or country. As such, it's possible to still apply some
restrictions while allowing the normal travel.

[Chris Green]

OP here, all interesting stuff! :-)

This (connecting from all over) is my situation with a laptop. To
improve security of my home system the firewall is set up to only
allow connections from a couple of specific IP addresses which are out
on the 'public' internet and where I have ssh access. I thus use them
as proxies:-

#
#
# <desktop> may be remote or local (particularly from <laptop>), if it's remote
# connect via <proxy host>. The RemoteForward port is for muttfox to copy
# files back to /srv/mutt for viewing HTML E-Mail with firefox on <laptop>.
#
Match host <desktop> exec "hostNotLocal <desktop>"
Hostname <home system's hostname from outside>
ProxyJump <proxy host>


host <desktop>
RemoteForward 50873 localhost:873
ForwardX11 true

So, when I'm at home I connect directly across the LAN, when away from
home I connect via the default proxy host machine. The RemoteForward
isn't just for what the comment says, it's also used for viewing image
files on the laptop when reading E-Mail using mutt/ssh.

The hostNotLocal script is just a tiny little script using ping to
test if I'm on the home LAN or not.

My original (and the other thread here) question was because I have
changed from using password authentication to Public Key and, as a
consequence turned off 'ControlMaster auto' which meant I started
getting the warning message which is subject of this thread.

After lots of thought (and help and suggestions here) I have decided
that turning ControlMaster back on is the way to go, for reasons as
follows:-

The RemoteForward is used to copy HTML and image files back from
the desktop to the laptop when reading E-Mail using mutt. The
copy is driven by entries in ~/.mailcap.

At the laptop end I have a 'daemon' using inotify which watches the
directory to which the files are copied and pops up the
appropriate viewing utility. (HTML to firefox is similar but
works via Firefox's 'remote' magic)

Thus I want the RemoteForward to be there 'all the time' even if I
move from using one terminal to another to run mutt. In fact it's
not unusual for me to run multiple mutt sessions as I may search
through old mail while answering a new one.

Having ControlMaster set means that just the first ssh connection
opens the RemoteForward and will not allow disconnection (i.e.
will 'hang') if exited when another connection is open. This is
actually exactly what I want!

Any approach without ControlMaster has a problem. If (as at my
'best so far' solution with warning messages turned off) the ssh
connection which actually creates the RemoteForward is exited then
mutt won't work in other ssh connections. This is (as I've noted
above) a not entirely unlikely happening.

Running the RemoteForward from a non-interactive ssh might work
but has the minor disadvantage that the connection might be left
open after I'd logged out from all the interactive ones.

So, after all the thinking/discussion I've returned (basically) to my
original solution! :-)


--
Chris Green
·