SSH productivity tips

[nuclear_eclipse]

You'd be far better off learning screen or tmux than by using shared connections. Knowledge of that will improve your offline options as well, will transfer to any ssh client (including Putty), and IMO is far more useful than having two separate terminal/ssh windows.

[barrkel]

My problem with nested terminal emulators is that they reimplement the scroll buffer (by necessity). This in turn breaks the native buffer scrolling keyboard shortcuts of the outermost terminal. For some servers, this is worth the pain; for others, it's not.

[senko]

I tend to edit files locally and rsync (the changes) to the server, running rsync over ssh. I do this fairly often (edit - save - rsync - check), and avoiding time to set up a new ssh connection is a huge speed boost to my use case (since the delta is usually quite small).

Even if I don't need to be logged in to the server at all, I still do it so it keeps the master connection open, and then speed up the rsyncs.

[shabble]

shared connections with ControlMaster etc are really handy for things like scp or sshfs.

Using TRAMP for emacs to tab-complete remote filenames is really nice, and much faster if you have a control connection already established.

I've not come across the ControlPersist option before - it's something I'm going to have a poke with to see if it can replace my scripts that fire off a bunch of common host control connections in the background, and use autossh to resume them when I get a net connection or wake the laptop from sleep.

[spudlyo]

Connection sharing and terminal multiplexers aren't mutually exclusive. Let's say that in order to get to 4-5 hosts (which you run screen on) you have to jump through a certain SSH bastion host which you specify using the ProxyCommand directive. You're going to want connection sharing on that bastion host, to make subsequent connections to hosts beyond much faster. If you have to jump through two bastion hosts to get where you have to go (yes I actually have to do this) connection sharing is a must.

Even without a bastion host, connection sharing allows for faster scp from your home box to the target host you're running screen on.

[losvedir]

Agreed. I actually did a Cmd+F "tmux" and "screen" after skimming the article to make sure I didn't miss it somehow.

A terminal multiplexer is an absolute must if your connection is likely to be interrupted. Closing the laptop, moving to a different room and picking up right where you left off is great.

[cabacon]

I don't know - I like having the control master around for when I've done something like startup an interactive process, then realize that I also want to pop onto the machine to look in some file. I don't always start screen when I login somewhere, and I don't particularly like screen well enough to make it my default first action when I log in somewhere. I also tend to prefer to be able to see all my logins simultaneously, rather than having them be screen windowed or tabbed.

I thought it was a nice overview of some things I use a lot (control master, and nicknames in .config) and included some things I didn't know, like the control persistence and some of the nickname wildcarding. It shouldn't be dismissed just because it isn't about screen/tmux.

[fdb]

Any good resources for learning screen? So far I've only mastered:

"Ctrl-a d" and "screen -r"

I'd love to hear how you use screen, for example. Do you use multiple sessions or windows? Split screen?

[zobzu]

No, screen/tmux does not solve the same issues shared connection do.

In fact, they've little to do which each other. Screens allow you to keep your session running and reattach to it. Control (shared connection) allow you to keep the connection running instead of opening multiple ones.

This is much much faster for example if you're using SCP, or have scripts opening different tunnels, and so on.

[EAMiller]

Here's a minor one - handy, and I find most folks don't know it. To escape a frozen SSH connection:

<return>~.

[kisielk]

<return>~? gives you the help screen that lists all the SSH escape sequences.

[jsvaughan]

I was surprised that this didn't mention SSH compression, which makes a noticeable difference on a slow connection:

ssh -C [email protected]

you can also specify a compression algorithm

(man ssh) -C Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11 and TCP connections). The compression algorithm is the same used by gzip(1), and the “level” can be controlled by the CompressionLevel option for protocol version 1. Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The default value can be set on a host-by-host basis in the configuration files; see the Compression option.

[pavel_lishin]

> If connecting to a server seems to sit there for a few seconds not doing anything, try adding this line to your config: > GSSAPIAuthentication no > And if that works, ask the server’s sys-admin to disable it in the server config, for the benefit of all users ‒ exactly the same line as above, but in /etc/ssh/sshd_config.

It would be nice if they described what this actually did - I'm hesitant to run options off, especially ones related to authentication.

[paxswill]

It turns GSSAPI [1] off, which is typically used with Kerberos. Unless you know you're using it (and in most cases you will know if you are), it's safe to turn it off.

[1] http://en.wikipedia.org/wiki/Generic_Security_Services_Appli...

[shabble]

The other really common case with delayed connections is that the sshd is waiting on a timeout while it tries to look up the rdns for your connecting IP.

    UseDNS no # disable rdns lookups in sshd logs. See man sshd_config

There's a possible security benefit to having it enabled, in that it'll try to resolve your rdns, and then confirm your forward dns matches it, but I'm not sure how much of a benefit that is, in practice.

[lloeki]

> "SSHFS works on Linux and OSX. I haven’t found anything equivalent for Windows users."

There's Dokan SSHFS, (Dokan is a similar endeavor than Fuse FS, only for Windows). For a commercial product, there's apparently ExpanDrive.

[elb0w]

Just a warning with shared sessions. If you use in shell vi be aware that killing your first connection will kill that other shell you are working in.

[njharman]

This. I did this so often I stopped using shared sessions.

[shabble]

Going a bit OT here, but I'm pretty sure there are a fair few Mac users here: has anyone noticed the ssh-agent/OSX Keychain integration behaving differently in Lion compared to previous versions?

In the past, I'm sure that waking the laptop from sleep, or unlocking the screensaver also unlocked the login keychain, and with it updated ssh-agent with my priv key, but recently I've been having to manually unlock it, which is getting to be quite a pain.

(ssh-agent remains running the whole time, ssh-add -l shows the identity when the login chain is unlocked, but is empty otherwise)

[tzs]

Yes, I've noticed something similar, although I do not let it store my ssh password on the login keychain. First time I ssh after a reboot, it asks me, I enter it.

Pre-Lion, it was then good until the next reboot. In Lion, it occasionally asks me to re-enter it. As you noticed, this seems to correlate with coming back from sleep or screen lock. It doesn't seem to happen every time, though, so I'm not sure what is going on.

According to ps, it is using the -l option to ssh-agent. The man page and the usage message of ssh-agent do not admit the existence of such an option. Perhaps that has something to do with it.

[chewbranca]

Nice trick using a proxied netcat command to forward ssh connections through a server. Was not aware of that, and I spend a lot of time running through a front ssh server, thanks!

[gnaritas]

Not sure I understand the point of it, it's trivial to do that without netcat.

  ssh -t server1 ssh server2

Will bounce you right to the second server. I'll generally alias this as the second servers name.

[dredmorbius]

For interactive multiple file transfers using SSH as an underlying transport, both lftp and mc are pretty darned good. 'lftp fish://user@hostname/path' sets up the basic connection. From there, it's like using a full-screen ftp client (lftp also supports ftp, sftp, and multiple other protocols).

mc can access remote filesystems and do complex file and directory management with ease.

Of course, there's always rsync as well.

[mixmastamyk]

I like to keep my server's filesystem mounted locally (via nautilus/gvfs+bookmarks) and edit files using a local application. I also keep a few terminals open as well to run commands, restart things, commit changes, etc.

Fast, easy to use, and nothing special has to be configured at the server besides installing sshd.

[there]

before you enable agent forwarding (and btw it's "ForwardAgent yes" not "AgentForwarding yes") you may want to enable confirmation in ssh-agent:

http://jcs.org/macssh

[kkovacs]

Hi guys, posted a related poll at http://news.ycombinator.com/item?id=2895035 - please vote! Thanks.