

SSH productivity tips - bigiain
http://blogs.perl.org/users/smylers/2011/08/ssh-productivity-tips.html

======
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.

~~~
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?

~~~
ordinary
You're missing out. After (or maybe alongside) those two keys, I find the most
useful ones are:

    
    
      Ctrl-a c (to create a new terminal)
      Ctrl-a 1 (to go to the first terminal)
      Ctrl-a 2 (second, etc)
    

If you're an emacs user, you might also want to change the command key away
from something as essential as the default bind for beginning-of-line. I
myself use Ctrl-T. In .screenrc, that would be:

    
    
      escape ^Tt
    

The screen manpage is also very good.

~~~
dredmorbius
Add to that list C-a " to view the list of screens. C-a A can be used to
assign names to those screens. C-a [0-9] can be used to navigate directly to a
specific screen. C-a C-a will swap the current and previous screen. C-a S
splits the screen vertically C-a <tab> navigates to the next visible screen
(there's no back-navigation). C-a q collapses all splits leaving the current
screen visible. C-a d detaches from the screen session.

There are some other features, but with these you're using much of the power
of screen. Takes a few days to get used to, but it's one of those "how did I
ever live without this" tools.

------
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 me@myhost.com

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...](http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface)

~~~
cabacon
And GSI-Openssh too: <http://grid.ncsa.illinois.edu/ssh/>

------
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.

~~~
jbronn
Your comment about the mysterious `-l` option got me interested and I did some
investigation. It looks like a custom option added by Apple to indicate it was
started by `launchd`. Here's a link to the relevant patch on their opensource
site:

[http://www.opensource.apple.com/source/OpenSSH/OpenSSH-95.1....](http://www.opensource.apple.com/source/OpenSSH/OpenSSH-95.1.5/patches/DVG-4748610+4897588_ssh-
agent_via_launchd.patch)

------
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.

~~~
zobzu
with netcat you don't have to use agent forwarding. its better in many cases
because you have use different keys for the jump host and the destination host
for example. trusting the jump host by using the same key is not very good
security wise, as compromising the jumphost would mean compromising all hosts
on the network for all users. using agent forwarding is equally bad of course.

nc solves that.

Likwise if you use this for scp, it works with nc, but it wont with a double
ssh.

~~~
gnaritas
Ah, interesting, thanks.

------
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.

