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?
Is there any other way to get rid of this (very minor) annoyance?
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.
On 2020-09-14, Chris Green <cl@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.
William Unruh <unruh@invalid.ca> wrote:
On 2020-09-14, Chris Green <cl@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 onYes, I use autossh from a headless BeagleBone Black computer. However
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.
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 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.
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:-This is where and why I'd prefer to use a ProxyCommand wrapper script.
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.
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
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.
William Unruh <unruh@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 runYes, that would work I suppose, but it's getting more complex. :-)
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.
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 <gtaylor@tnetconsulting.net> wrote:
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.
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.
Not sure what you mean.
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.
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"?
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.
--
Grant. . . .
unix || die
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/
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 far you have not mentioned even one.
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.
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.
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.
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.
Not sure why that is an abuse, but OK.
Yes, that could be problematic I guess. I tend to always use IPV4 so
it did not even cross my mind.
Setting up and alias in bashrc or putting it into rc.local makes the
mess a one time only problem.
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.
On 9/16/20 1:58 PM, William Unruh wrote:
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 211:15:06 |
Calls: | 6,619 |
Calls today: | 1 |
Files: | 12,168 |
Messages: | 5,317,308 |