all lists on lists.proxmox.com
 help / color / mirror / Atom feed
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
> 
> 
> 




  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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal