You can try to use VNC X server. It uses non-privileged port to communicate and it may be run without any root privileges. To avoid the building of VNC find out what port of it the distro being in use contains (there is a number of options TigerVNC
, OpenVNC
, RealVNC
, e.t.c.).
For example the Fedora 17 has tigervnc-server-minimal package that has everything you need to start a VNC server:
/usr/bin/Xvnc
/usr/bin/vncconfig
/usr/bin/vncpasswd
/usr/share/man/man1/Xvnc.1.gz
/usr/share/man/man1/vncconfig.1.gz
/usr/share/man/man1/vncpasswd.1.gz
Download it, extract the binaries and put them into your ~/bin folder for convenience.
First you need to run vncpasswd
once at each system to set a password to access your vnc server instance.
Then start the server itself by the command Xvnc
and note what display it started (it will print out the info on standard output).
Then you will be setting up a TCP port forwarding with putty
to the port with number 5900+<display number>
, e.g. for the display :1
you should create a tunnel to port 5901:
putty -ssh -L5901:127.0.0.1:5901 user@host
Then start the VncViewer and connect to the display localhost:1
at your Windows box.
When you are finished don't forget to stop Xvnc server, so it is not wasting the resources at server:
killall Xvnc
The case of aura is a bit more complex as you can't log in directly. If one of your servers allow to set the tunnels to any machine in the LAN, then just create the proper tunnel, say:
putty -ssh -L5901:<ip-of-aura>:5901 user@host
Otherwise, you start the ssh session with aura with port forwarding from the remote shell at aisa or lethe:
ssh -L5901:127.0.0.1:5901 aura
This is definitely not normal. Given your symptoms, I think you're experiencing an IP address conflict. There are two machines on your network with the same IP address, and one of them is the server you're trying to reach. Sometimes you're reaching the expected machine and all is well. Sometimes you're reaching another machine which has a different SSH key and your connection is rejected.
When there's an IP address conflict, it's common that a router locks in the route to one IP address until a cache expires, then queries the route again and updates it to match whoever responds first, producing somewhat random results. There's nothing preventing the switchover from happenning in the middle of a TCP connection.
Sophisticated routers raise an alert when IP conflicts happen, so your network administrator may already be tracking this. If you're root your server, you can resolve it by picking an unassigned IP address. If you're getting your IP address through DHCP, contact the DHCP administrator.
Best Answer
This is because history of your commands from current session are flushed on disk during logging off. And if you has been disconnected, when you connect again you will get last flushed history.
You can also manually flush history to disk by running:
Refer to
man history
: