From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH docs] pvecm: explain role of ssh in PVE stack
Date: Wed, 25 Nov 2020 10:04:57 +0100 [thread overview]
Message-ID: <1606293462.dawuwcrib0.astroid@nora.none> (raw)
In-Reply-To: <20201117113557.112265-1-o.bektas@proxmox.com>
On November 17, 2020 12:35 pm, Oguz Bektas wrote:
> add a section describing how SSH tunnels are used in conjunction
> with PVE. (for #2829)
>
> Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
> ---
> pvecm.adoc | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/pvecm.adoc b/pvecm.adoc
> index 3820c17..10de0a1 100644
> --- a/pvecm.adoc
> +++ b/pvecm.adoc
> @@ -869,6 +869,41 @@ pvecm status
> If you see a healthy cluster state, it means that your new link is being used.
>
>
> +Role of SSH in {PVE} Clustering
> +---------------------------
> +
> +{PVE} utilizes SSH tunnels for various operations:
s/operations/features
> +* Proxying terminal sessions on the GUI
* Proxying noVNC guest console access when client is connected to a different
node than the guest is running on
* Proxying noVNC host shell access when client is connected to a different
node than the target node
the latter also includes the 'upgrade' shell, not sure whether we want
to mention that separately.
> +* VM/CT Migrations (if not configured 'insecure' mode)
* Guest migration in 'secure' mode
> +* Storage replications
* Storage replication
> +
> +For example when you connect another nodes shell through the interface, a
> +non-interactive SSH tunnel is started in order to forward the necessary ports
> +for the VNC connection.
this is not correct. we don't use SSH to forward any ports, we use it to
get a secure tunnel to the process running on the other node. the
'listen on port' part happens entirely on the node where the client
connects to.
e.g., if I open a vncterm shell on node2 while being connected to node1,
the following will run on node1:
0 0 1505381 1505380 20 0 24140 7136 poll_s S ? 0:00 | \_ /usr/bin/vncterm -rfbport 5900 -timeout 10 -authpath /nodes/node2 -perm Sys.Console -notls -listen localhost -c /usr/bin/ssh -e none -t IPOFNODE2 -- /bin/login -f root
0 0 1505385 1505381 20 0 15784 6232 poll_s Ss+ pts/1 0:00 | \_ /usr/bin/ssh -e none -t IPOFNODE2 -- /bin/login -f root
and only the login shell will run on node2 (over SSH). for xtermjs and
spice it's different again (websocket / spiceproxy).
maybe the following:
For example, when using the noVNC shell for node B while being connected
to node A, noVNC connects to a terminal proxy on node A, which is in
turn connected to the login shell on node B via a non-interactive SSH
tunnel.
> +Similarly during a VM migration an SSH tunnel is established between the target
> +and source nodes. This way the local `qemu` socket can be used for the migration.
this is only half of the picture (the other is online and offline
storage migration and/or replication, which also happens over SSH and as
aprt of migration)
> +
> +IMPORTANT: In case you have a custom `.bashrc` or similar file that gets
> +executed on login, `ssh` will automatically run it once the session is
> +established. This can cause some unexpected behavior (as commands may be
> +executed as a side-effect).
> +
> +In order to avoid such complications, it's recommended to add a check in
> +`/root/.bashrc` to make sure the session is interactive, and only then run
> +`.bashrc` commands.
> +
> +You can add this snippet at the beginning of your `.bashrc` file:
drop this sentence, end last paragraph with ':' ?
> +
> +----
> +# If not running interactively, don't do anything
> +case $- in
> + *i*) ;;
> + *) return;;
> +esac
> +----
> +
> +
> Corosync External Vote Support
> ------------------------------
>
> --
> 2.20.1
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
>
next prev parent reply other threads:[~2020-11-25 9:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 11:35 Oguz Bektas
2020-11-25 9:04 ` Fabian Grünbichler [this message]
2020-11-25 9:33 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1606293462.dawuwcrib0.astroid@nora.none \
--to=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.