SSH as service - more use cases

In previous post I described the most straightforward use case of SSH service usage: access VM at routable tenant private network.

 The more interesting case could be to access a VM1_UUID that lays on not routable network: Tenant1 Subnet100
figure 1

Achieving SSH connectivity requires SSH gate (SSH jump host) to have a network interface on Tenant1 Subnet100. SSH service have to allocate neutron port on Tenant1 Subnet100 network and attach new port to SSH gate. Dynamic port attachment requires some underground SSH gate network configuration. SSH Service daemon can access SSH gate VM with SSH management key and update network configuration.
figure 2

Now traffic may flow to VM1_UUID even without router involvement. Authentication is performed gradually. We may use same concept of SSH configuration file with proxy command. 
figure 3


Generic SSH service

Both routable and no routeable VM connection schemes lays on boundary of specific tenant.

The more generic case of SSH service may take advantage of SOCKS.

 SOCKS-based client establishes secure connection with SOCKS proxy
SOCKS Proxy:
  • Is an OSI level 5 tunneling active endpoint  
  • Establishes IP connection to remote peer on behalf of a client
  • Forwards traffic back and forth between the client and the server.
Why using SOCKS protocol?
  • Normally it is used as a secure internet access
  • Now enables secure service-on-demand multiplexing
The SOCKS reverse proxy, after authenticating the request, will forward it to the desired SSH jump host (via the Router that will also NAT the request)

Comments

Post a Comment

Popular posts from this blog

Distributed SNAT - local gateway mode

Image
In this post I am going to dive into proof of concept (POC) implementation details of local gateway SNAT mode. Instead of being transferred to network node SNAT traffic will utilize additional local gateway interfaces to skip one hop for 'north-south' traffic.  POC implementation was based on neutron stable/mitaka branch that is pretty outdated these days. However implementation concept not changes a lot. SNAT implementation at DVR SNAT feature in Distributed virtual router (DVR) implementation remains centralized: figure 1 Figure 1 shows single VM deployed at Compute node.  Data plane address of Compute node: 182.0.0.2 Data plane address of Network node: 182.0.0.3 External network 172.24.2.x VM's address on private network: 10.0.0.4 Traffic flows as following: Packet with destination address outside of cloud VM enters internal bridge (br-int) Target MAC address lays in a Router namespace with on interface with IP address: 10.0.0.1 Router identi
Read more

Distributed SNAT - examining alternatives

Image
SNAT feature remains one of the most common network features in cloud network deployment that still has no agreed distributed solution. While Distrubuted Virtual router solves local connectivity for floating IP and simplifies east-west VM communication SNAT is still deployed at Network node and remains a traffic bottleneck. figure 1 Above figure has 2 deployed tenants 'green' and 'orange'. SNAT is performed centrally at network node. Possible solutions The are number of proposed solution to decentralize SNAT. Each solution has its own benefits and drawbacks. 1. SNAT per (tenant, router) pair The most straightforward solution is to perform SNAT at compute node router instance.  However while DVR deployment is copying internal subnet router address across compute nodes router's IP address on external network can not be copied. Such a deployment will consume extra external address per (router, tenant) pair. figure 2 Maximum address consumption
Read more

SSH as a service

Image
This post starts a series of posts devoted to newly created SSH cloud service Motivation for SSH service SSH was and remains a handy tool for all network administrators. At cloud deployment w e need a way to remotely SSH a VM in the cloud that is not connected to the internet from outside of the cloud. Such task requires VPN. Among disadvantages of VPN I can mention:   VPN does not support internal, non-routable networks  VPN is less secured since it allows access to all devices on all routable networks in the cloud  Requires a special client   Error-prone – client might set the VPN server as its default GW which will direct all its outgoing traffic to the cloud Tenant administrator wants to setup service that will handle network connectivity, hide address details from outside user and at the same time save cloud floating IP addresses from being attached/detached according to current tenant users immediate request. User  wants to access virtual machine VM3
Read more