Tips for Remote Unix Work (SSH, screen, and VNC) | Hacker News Reader

Tips for Remote Unix Work (SSH, screen, and VNC)

shebang.brandonmintern.com

218 pointsBrandonM62 comments

One thing the author is missing is the ssh-copy-id command, which will copy a ssh key to he authroized_keys file and set the correct permissions. No need for complicated and fragile ssh host "mkdir .." commands

I tried to leave a comment, but twas asking complicated things about registering.

Thanks for the suggestion... that is much simpler. I added that to the post. Sorry about commenting being so difficult; I'm using Posterous, so it's not by my design.

It's worth mentioning that ssh-copy-id might have problems with specifying port number. Here is workaround for that:

$ ssh-copy-id ‘-p xx -i ~/.ssh/id_rsa.pub login@example.com’

Thank you! I've done this dozens of times and never knew, none of the tutorials I've looked up reference it.

One thing to keep an eye on for Unix remote work is Red Hat's SPICE remote desktop protocol. It was originally meant to support remoting to virtual machines and the server thus built into QEMU, but there's also a standalone server now that appears as an X server to X clients, called xspice. xspice is still young and immature, but already packaged in Fedora.

SPICE also keeps coming up as a possible solution to the lack of built-in network translucency in Wayland, the technology many would like to see replace X down the road.

Especially with NoMachine's NX 4 going closed source (previous versions were partially open, allowing others to replace the closed parts and produce a fully open stack), I'm looking to SPICE as a replacement.

There are existing NX implementations that work really well, though, e.g. OpenNX (client) + FreeNX (server). While xspice has potential, for now (and forward, should xspice not "get there") NX is a viable option.

Definitely, I use NX myself daily at the moment. The Windows client sucks (slow, no free resize as in the Linux client, lots of clipboard problems), but Linux-to-Linux is quite awesome.

One problem is that NX 3 doesn't support newer X extensions like COMPOSITE and DAMAGE, though. NX 4 does, but is no longer open. So the future viability is kind of starting to break down already, if you ask me.

Windows NX client treats me well. The lack of free resize hasn't bothered me yet as my workstation is really just a thin client with Outlook, so I just maximize the NX session.

xpra is also worth looking at. I's much faster than X forwarding or VNC, and it's much simpler to set up than NX. On Debian and Ubuntu, it's just an apt-get away. The usage is straightforward

On the remote machine which will export the application(s):

xpra start :100

export DISPLAY=:100

xterm

On your local machine, you would use something like:

xpra attach ssh:serverhostname:100

You can even detach the windows(s) from one computer and reattach from another, like GNU Screen.

http://xpra.org/

Thanks, I had heard about that shortly after the initial release but since lost sight of it. Sure reads like the authors have made a lot of progress and the repo looks pretty active, too. Will give it a try.

Perfect! I've been looking for something like this a long time. Thanks so much for mentioning it.

From the article: ...you can leave the password blank (if you secure your laptop with encryption, a locking screensaver, and a strong password, your SSH key doesn’t require a password)..., but what if that is still not enough security for you or your policy prohibits you from using key pairs for authentication, or maybe you are not using a server that often and just don't want to set up key pairs.

Enter the ControlMaster mechanism (see man ssh_config):

  Host *
  ControlMaster auto
  ControlPersist yes
  ControlPath /tmp/ssh-%r@%h:%p
  ServerAliveInterval 600

So now you type in your password for your first session only, and every other session will be slaved to it (this includes directory/file auto completion over ssh in zsh and other nice nibbles like it does with public/private key pairs).

Normally, your SSH auth agent is responsible for letting you unlock your key once and use it with multiple sessions.

ControlMaster's biggest advantage is using a single encryption channel for multiple connections. Especially handy if you need to jumphost through a vpn machine.

Doesn't ssh-agent do automatic pass-back, vpn or not?

sshfs!

When I want to work with a server, I very often use "sshfs <servername>:<remote_dir> <local_path>" to mount it to my local drive. (By default <remote_dir> is your remote home directory, so you can omit it if that's what you want).

Then you avoid all that mucking around with ssh while working. Probably a bit more inefficient, but you can use rsync if you're pushing a lot of data around.

Available on homebrew as "brew install sshfs".

Be sure to read the info as you install sshfs via homebrew. Getting fuse4x working right requires a couple extra steps.

I haven't been able to get it running on 10.7.2, although the last time I tried was a month or so ago. Is it actually usable/workable/stable now?

(I don't want to clutter my laptop with various versions of PHP, Apache, etc. that I need for work, so I run a VM - as of late, I've been using ~/projects/workProject1 as my working folder, mounting it via VirtualBox's shared folders, but the read/write speed on the VM is pretty atrocious. Which is sometimes great for testing, but not so great when I accidentally type "git status" in the VM instead of the host machine, and wait a full minute before realizing my mistake.)

Works great for me on 10.7.2. sshfs --version says: sshfs 2.3.0, fuse4x 0.8.13, FUSE 2.8.6.

I just followed the homebrew directions, I don't remember doing anything funky to get it installed.

I forgot about sshfs! I don't seem to use it as much anymore, but I first encountered it about 6 years ago and thought it was pretty amazing.

There is a downside to sshfs, though, and it's related to the classic Joel on Software post, "The Law of Leaky Abstractions" (http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...). A relevant quote from that article is:

Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions.

It sucks to be using your editor of choice to modify a file mounted on an sshfs filesystem and have something not quite work right. Something as simple as having the latency be higher than the local filesystem can make saves (and even autosaves) ruin the user experience. And you're pretty well hosed when the connection drops; you're almost guaranteed to lose at least some work.

That is why these days I tend to avoid sshfs and simply SSH+screen to a remote machine, where I can then run vim using a .vimrc file that matches the one on my home machine. I get exactly the same editing system no matter where I'm logged in, and instead of hiding connection problems somewhere that you can't control, it's very clear what will happen when a disconnection occurs.

Of course, if it's across a local or very reliable network, all of my arguments disappear and sshfs is an excellent tool.

Screen is vital enough for me that I've modified the MOTD on my servers to include a reminder to use it (I don't log into them that often)

Using gvfs from Nautilus is also quite an easy and effective way to do this.

VNC can be used to "remote control" a system. NX can be used to WORK on that system.

I have written thousands of lines of code with NX, Eclipse and latencies of ~100ms! There is no way to do something similar with VNC or anything else.

http://freenx.berlios.de/ FreeNX is a great service. Also NoMachine NX Client is a great client. If you use them once, you can't even hear about VNC and other remote control services.

Too bad there's no NX server for Windows yet...

You can have it connect to a windows terminal server. It works quite well and is actually better than plain terminal server.

I wish there was NX for mac, since I try my best in life not to use ms technology.

I like how it can be configured to not completely take over your desktop; remote windows and local windows can coexist, like Xsession forwarding but much more performant.

Since learning about https://github.com/apenwarr/sshuttle here on HN, I rarely need to use ssh tunnels on my local machine. Instead, I keep multiple sshuttle sessions running in the background for the private networks I access.

Nice article. A really cool ssh feature is the integrated SOCKS proxy which you start with the -D option. Just run

    ssh -D1080 me@remote.host

and it will start a SOCKS proxy on port 1080 and will forward all requests via the remote host. Change the proxy definition in your browser (foxyproxy ftw.) and you are done.

It is really useful if you want to access virtual named hosts behind remote servers or just want to specify the uri instead of fiddling around with ports.

It's even more useful than that! Some coffee shops restrict traffic over port 80, but don't touch 22. So set up a SOCKS proxy and you have free internet. Tethering to T-Mobile and getting sick of them downsampling images for you? Start up a SOCKS proxy -- they can't downsample what they don't see. Or just in general, if you're on any WiFi network that you don't trust, set up a SOCKS proxy and tunnel everything through it.

> Send the files .. without .. scp

> cd && tar czv src | ssh example.com 'tar xz'

Why would you not want to use scp?

  scp -r src/ example.com:~/target/

does the same thing. Add -C for compression.

That's faster from my experience than piping. Even faster, use rsync with the ssh option.

alias scp="rsync --progress --partial"

and voila! You can resume big file transfers now.

I'm not into overwriting commands, what if you share you bashrc on a machine without rsync?

Install rsync;)

Two points:

1. The scp command is not quite the same because it's not maintaining all the file metadata the way that tar is.

2. The examples were mostly intended to be illustrative, showing that you can do things like cd around on the remote machine before receiving/sending the data across the SSH pipe.

My VNC server example near the bottom of the post was a more useful example of the type of thing you can do with SSH that doesn't have another easy solution.

I can recommend Nomachine for remote desktop work, it is blazingly fast even for crappy X applications which redraw often.

http://www.nomachine.com

Thanks for the link. I've actually been pleasantly surprised by Xvnc over an "ssh -C" tunnel. Additionally, there are some parameters you can set for the vncserver (man Xvnc... one example is "-deferUpdate") that can significantly improve performance for bad connections or awful X applications.

NoMachine once generated high expectations in the Linux world. Their focus nowadays seems to be on commercial users.

I've tried it several times over the years and still find standard vnc4server works great where nomachines seemed slower to me, and harder to install, you had to download directly from their web site.

Then you must have setup something wrong. NX has ALWAYS been consistently faster than a typical VNC setup. You also don't have to use NoMachine's implementation - use FreeNX (server) + OpenNX (client).

There are also tmux and NX.

Thanks for the suggestions. I've been meaning to check out tmux, and just today I tried to install FreeNX to replace VNC. I hope my post at least provides a useful starting place and some creative ideas (e.g. SSH+auto-screen) for someone who is just getting into remote work.

I am a tmux advocate and you can get screen based hot keys if you need but it feels cleaner and it's also under a BSD licence.

+1 for tmux. We use it here and it works great for remote pairing. Some of the guys also pimped out their setup with tmuxinator. https://github.com/aziz/tmuxinator

For a discussion of the advantages (and perhaps disadvantages) of tmux over screen: http://unix.stackexchange.com/questions/549/tmux-vs-gnu-scre...

tmux is also still being developed, and screen is not. And you dont have to patch to get vertical splits.

The ssh port forwarding command can also be simplified using "ssh -ND 9999 user@example.com" The -N opens up just a shell connection and is optional for when you dont need to execute commands in that shell. The -D dynamically forwards all requests to localhost:9999 to the server. I use this all the time to tunnel out of networks and it works well with the socks proxy configuration in firefox or your computer's proxy configs

Another nice ssh tunnel feature is remote port forwarding. Instead of forwarding your local port to the remote server you can forward a remote port to your local system. Instead of -L8080:localhost:80 you can just use

  ssh -R8080:localhost:80 remote.host

which will make your local running web server accessible via the remote port. Of course you can specify instead of localhost other arbitrary hosts which will be exposed via the connection.

This is really useful for some firewall punching (if you can access the ssh server or have at least a http proxy which supports CONNECT) and exposing private services remotely.

This is really useful for some firewall punching (if you can access the ssh server or have at least a http proxy which supports CONNECT) and exposing private services remotely.

It would also get you fired from most places I've worked.

Nice article. You could expand on it by mentioning the config file.

For example, I have a remote proxy server, a different remote web server, github and so on, all with different user names and ports. I can alias each with their own setup, including adding an entry for a tunnel.

  Host    mymac
  ForwardX11      yes
  ForwardX11Trusted yes

  Host webserver
  HostName webserver.org
  User username

  Host myproxy
  HostName xx.xxx.xxx.xxx
  User aname
  Port 1934

Don't forget autossh. It auto-reconnects when your connection dies. This combined with screen makes working on flaky wireless much more bearable.

And on a mac, this will work to create a tunnel over ssh, then start the default vnc viewer and finally close the connection when the vnc viewer is closed:

ssh -C -f -L 5901:localhost:5900 example.com sleep 10; open vnc://localhost:5901;

One line. Add is as an alias, configure ssh keys and you can connect to your home machine from anywhere securely.

It's a very bad habit to use -p for every invocation of mkdir, and it's not appropriate in any of the examples where it's used. For one thing, it will never complain if you get the path wrong (provided you have the necessary permissions) which is particularly undesirable when doing remote work.

I rarely use -p. Please point out where it was inappropriate.

Instead of an SSH tunnel, I route a web address and use a VirtualHost to access local ports.

For example, I route http://blah.example.com to my home server, then use VirtualHost to route blah.example.come to port 8080

For me, the article just ends with the phrase "For each computer that you connect to," but all the rest of the html is still there. Very weird. Google cache works fine.

emacs --daemon/emacsclient is pretty awesome for remote work, and it cuts down on startup performance issues when emacs is configured to interpret .el files via NFS.

It's a lifesaver for me. I normally run my emacsclient on my local X display, but in low-bandwidth situations I run nox emacsclients in terminals over SSH. I still get multiple buffers and the same emacs server session.

is there a better way to do ssh/auto-screen, for example a setting for ~/.ssh/config to do the same thing?

I have this at the end of my ~/.bash_profile:

    # run under screen if we are connected via ssh
    if [ "$SSH_CONNECTION" ] ; then
        rm -f .ssh/auth-sock
        if [ -e "$SSH_AUTH_SOCK" ] ; then
            ln -s "$SSH_AUTH_SOCK" .ssh/auth-sock
        fi
        export SSH_AUTH_SOCK=~/.ssh/auth-sock
        screen -d -R
        logout
    fi

Note: Don't do this if your screen session is setup to launch new shell windows as login shells...

I bought Expandrive.

What happened to the site?

Reply on news.ycombinator.com