Scenario:
I would like the ability to be able to use the cli on a client that has remotely connected to me via my ssh server in my office and use their terminal to work remotely if I am in another remote location.
Ex.
The client reverse ssh's to my remote ssh server in my office.
ssh -R 10002:localhost:22 client@my-remote-ssh-server
I remotely ssh into my ssh server from another client site.
ssh -L 3400:localhost:3400 admin@my-remote-ssh-server
and from there I would be connected to the tty of the remote client from wherever I am.
Is this possible?
ssh -t user@some.domain.com /usr/bin/screen -xRR
or
ssh -t remote_host screen -r
??
Are you talking about a remote host serial port?
It sounds like
- session A connects to UNIX box
- Session B connects to UNIX box
- session B controls the terminal on session A
- session B has access to session A's desktop/UNIX box
- session B can then becomes session B's use on the remote box
IF so try this idea (for ubuntu but it works for linux)
Remote Access to the Ubuntu Linux Desktop - Techotopia
I guess! I prefer VNC, but not every host can X/GUI. The screen does have detach/reattach: Manpage of SCREEN
Many thanks for the reply. We are talking linux(cli) to client(cli). I have always been able to do this to a gui but what I want is access to the cli.Let me clarify:
A (you(linux), remote) ------ S (server(linux, office) ----- C (client(linux), remote)
1 <---------- C sets up reverse ssh session
2 ----------> A sets up ssh session
3 ----------> A wants cli access to C cli
?
---------- Post updated 01-10-13 at 10:45 AM ---------- Previous update was 01-09-13 at 04:35 PM ----------
The reason that I ask this question is that some of the sites they dont allow ssh access into their network. So typically I have them ssh to my server and up unto this point, I "vnc" to the Gnome desktop and open up a terminal in that manner to be able to work. I wanted to avoid accessing the GUI and be able to access the cli directly. Would "-S" option work using SSH? Is that what I need to be using?
Once they ssh to your network creating a tunnel, you can telnet in on the encrypted tunnel end (or X, vnc or whatever -- even ssh). Use localhost so it is not relatively wide open. Access requires access to their tunnel's target server and the id/pw and port for the telnet from there. I am not sure why it would get more complex.