2

I'm still trying to understand how tunneling works, but I have some instances on AWS that I enabled SSH tunneling to view some web apps for monitoring applications running on the machine and I'd like to know if I can do my normal work on a tunnel session profile

I already SSH into the machine often to do work, and I created another Putty profile session that's very similar to the original Putty one, but it's for tunnel forwarding. I followed AWS' instructions here and it was pretty straightforward. The difference is the new tunnel one obviously has dynamic profiling enabled. Is it okay if I do all my normal work on this tunnel-enabled session profile? Or should I be separating them out into 1 session for normal work, and another session up for the tunnel forwarding?

Improve this question

2 Answers 2

Reset to default
0

There's no working difference from a "tunnel enabled" session or a "normal" ssh session. The only thing is that it's also carrying the tunnel with it.

It's often typical to see the options -f -N added to fork the process to the background and not execute remote actions on the target. This might be helpful to let you leave the tunnel open without worrying about an accidental exit or other factors at play.

Improve this answer
2
  • Great, can you elaborate a bit on the -N option? Is a remote command any command I run/execute during the SSH session? Or is a remote command something from the tunneling session?
    – simplycoding
    Apr 27, 2018 at 15:09
  • Straight from the man page: -N Do not execute a remote command. This is useful for just forwarding ports. It opens the SSH tunnel, but just for tunneling, no commands can be executed (it doesn't start a TTY or shell session). This is best used with -f to fork the process to the background and just let it be. You can then open new sessions as you need for working from.
    – Andrew
    Apr 27, 2018 at 16:13
0

No it does not normally require different profile, you can tunnel and work on remote cli on same session and profile.

However, with special configuration it is possible to restrict tunneling and cli usage in many ways through sshd/authorized keys configuration:

SSH server instances listening on different ports:

  • tunneling only possible through specific TCP port
  • terminal access only possible through specific TCP port

SSH access restrictions using authorized_keys:

  • tunneling only possible with specific RSA key used to login
  • terminal only possible with specific RSA key used to login

SSH access restrictions using user/group matching:

  • tunneling only allowed for specific user accounts
  • terminal only allowed for specific user accounts

While above is possible it most often is not implemented like that and when one has cli access he also could workaround tunnelin restrictions by implementing mock tunneling protocol, for example through piping data through normal ssh cli session. This wont require anything special, standard binaries available on most servers will be just enough.

You might also want to take a look at this answer talking about SSH protocol channels: https://unix.stackexchange.com/a/86162/27083

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .