Putty - and its lack of shell characters

[HermanAB]

Uhmmmm, Linux to Windows?

You should enable RDP on Windows and use rdesktop from Linux.

[Irony]

it is always localhost if you are tunneling. You create a tunnel from localhost: port to remotehost: port so then you use whatever client you want to connect to localhost: port, allowing ssh to handle the forwarding.

So localhost is sort of like http in that the wording is redundant in that it is always the word localhost that is used?

[Irony]

Uhmmmm, Linux to Windows?

You should enable RDP on Windows and use rdesktop from Linux.

Yes I've enable remote desktop on windows.

I can connect to the xp laptop from my ubuntu machine via vncviewer but not vinagre - that is not the problem, the problem is that I am still working out the details of SSH.

I've discovered PAC - http://sourceforge.net/projects/pacmanager/ - whilst I am comfortable at command line, I can never remember the commands so gui is easier. Unlike putty PAC works and gets to the shell giving;

username@server's password: 
Last login: Fri May  7 15:22:22 2010 from client.home

username@server ~
$

[Irony]

The problem is thus this, I issue the command;

vncviewer localhost:5900

And get the error;

vncviewer: ConnectToTcpAddr: connect: Connection refused
Unable to connect to VNC server

Perhaps it is because I am currently connecting locally?

[Irony]

So this is the situation.

I can Ultra VNC Client connect via Putty from my Desktop (Windows 7) machine to my Laptop (XP Home) with Ultra VNC Server and COPssh.

but on rebooting into Karmic on the Desktop machine I cannot;

Remote Desktop Client/vncviewer connect via PAC from my Desktop (Karmic) machine to my Laptop (XP Home) with Ultra VNC Server and COPssh.

PAC ssh connects successfully but on issuing localhost:5900 in either Remote Desktop Client or vncviewer nothing happens, they just hang as though waiting for something.

Any suggestions?

[Irony]

Success!

It occurred to me that in PAC I hadn't set source and destinations ports or mentioned localhost, i.e. 5900:localhost:5900

I couldn't figure out how to do this in PAC (there are no manuals), so on a hunch I opened up Putty and it worked and got to shell - I don't think it worked before because I had not set up copssh correctly on the laptop - I thus deleted copssh making sure to delete it in the registery and delete the user it had created and any stray files I could find.

I then set it up again and I also used Ultra VNC on the laptop as before I had tightvnc which never popped up with a refuse or allow box.

In the process I learned that copssh creates a user key when a user is created and so I now have some idea of keys. I also found that using ssh requires that only port 22 needs to be opened, not 5900 which is confusing as 5900 is specified in the commands...

[junapp]

5900 is likely mentioned in the vnc instructions. You are tunneling in on port 22 - making it unnecessary to have 5900 open. If you were not using ssh to create the tunnel you could open 5900 and vnc directly to it. Having ssh handle all the connections and forwarding is considered the better approach than leaving 5900 open to the world. I wouldn't equate your thought on 'http' being the same as 'localhost'. It doesn't always have to be localhost (on the remote end).

http://en.wikipedia.org/wiki/Tunneli...hell_tunneling

[Irony]

I'm still puzzled as to why it is that if I am using port 22 with ssh yet the command for vncviewer is localhost:5900 - what has 5900 to do with it as port 5900 is closed both on my router and firewall.

[bodhi.zazen]

Port 5900 is your VNC connection.

You using ssh to tunnel port 5900. This encrypts your network traffic and increases security.

So, you start the ssh connection, over port 22, and ssh tunnels localhost:5900 to your ssh server, tunneling the connection.

Thus on the client you connect to localhost:5900 and ssh does the rest.

http://en.wikipedia.org/wiki/Tunneling_protocol

[Irony]

The main problem with SSHing is that it makes VNCing very slow particularly when I connect to my wireless laptop.

The slowness renders the method useless when flicking back and forth between say desktop 1 with the VNC and desktop 2 with say firefox - it then takes VNC a few minutes to start moving.

Its manageable if I just stick to one desktop but I cannot fireup any other programs on the same screen - this of course means that I cannot solve problems by for example looking at firefox and then going to VNC.

In short it is not a practical method.