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.bek...@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
>
>
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
