A trick I learned recently: create .ssh/config<p>File format: as many of the following blocks as you like<p><pre><code> Host $ALIAS <-- whatever you want here
Hostname www.example.com
User someuser
Port 1234
</code></pre>
You can now ssh to that server as that user by doing "ssh $ALIAS" on the command line, without needing to specify the port or user with the usual command line arguments, or necessarily spell out the entire host name.
A few commenters do not seem to be aware that
it is perfectly possible to use passphrase-protected
keys for automated tasks (cronjobs and the like).<p>The excellent (though unfortunately named) keychain[0]
utility provides a ready and powerful abstraction for
<i>both</i> ssh-agent and gpg-agent.<p>[0] <a href="https://github.com/funtoo/keychain" rel="nofollow">https://github.com/funtoo/keychain</a>
From the article:<p><pre><code> > No more password prompts
</code></pre>
Is that - you ask - because he's using ssh-agent? No, it's because he doesn't tell you you should be using a password-protected key. Some kung fu.
The situation with beginner-friendly SSH tutorials
is, in a much lesser degree perhaps, comparable to
the crypto texts: Good will alone does more harm than
good.<p>This treatment ssh does not mention ssh-agent and,
more importantly perhaps, implies that there is a certain
virtue in having private keys unprotected by sturdy
passphrases lying around.<p>There is not; most emphatically not.
The article mentions ECDSA, but doesn't mention Ed25519, which is supported since OpenSSH 6.5:
<a href="https://lwn.net/Articles/583485/" rel="nofollow">https://lwn.net/Articles/583485/</a><p>As a bonus Ed25519 keys unconditionally use bcrypt for protecting the private key
This is why reading the man pages is useful; you'd get all this and more, including:<p><pre><code> - X11 Forwarding
- Reverse forwarding (bind listening sockets on the remote machine,
redirecting to a local service)
- SSH-Based VPNs</code></pre>
Best trick I learned in the past few years is SSH control sequences.<p>Disconnected from your host but not timed out yet? Press Enter, ~, . and the client will quit.
> Sharing Connections<p>I've tried this before, and what effectively always happened (to me) is that as soon as I started copying a file, I couldn't continue working in Vim anymore until the file was done transmitting because the copying would eat all the bandwidth. There may be a flag or setting around this, but I've never found it. When I open two connections, it is usually fine.
Another recommendation: start an SSH server on port 443 on a server somewhere. Then if you're stuck somewhere on an untrusted network, one that blocks most outgoing ports or one that throttles non-HTTP ports, you can use SSH for tunneling and/or setting up a quick SOCKS proxy to get yourself encrypted, unblocked, full speed internet access.
I just learned about remote file editing with vim and scp thanks to this article, it's the only thing I didn't know about and... wow, it's amazing. This will make my life much easier every time I have to remotely edit some config files on my servers.<p>As for the rest of the article, really nice stuff. Nice tricks for ssh newbies. I wish he also talked about setting up a nonce system with ssh or move sshd to a non-default port to prevent attackers spamming port 22, or even remove password authentication altogether.
While we are busy dispensing wisdom:
Do use<p><pre><code> PermitRootLogin without-password
</code></pre>
instead of 'yes' in /etc/ssh/sshd_config if you absolutely must have ssh root access.
One problem I have with SSH is DPI. Deep Packet Inspection seems to be behind the SSH block in place at a local library I work at. SSH out in any form just isn't possible there, even via a browser-based console (such as that used by Digital Ocean, for example). There doesn't seem to be a suitable solution to get around it offered anywhere.<p>My own fix was to use 3G to do the SSH work via a tethered phone and to use the wifi adapter to run the bulk of any other web traffic. It'd be great to have a workaround for DPI, though, if anyone has any experience there.
I can recommend Mastering SSH - it's a nice, short read.<p><a href="http://www.amazon.com/SSH-Mastery-OpenSSH-PuTTY-Tunnels-ebook/dp/B006ZO9ULK/" rel="nofollow">http://www.amazon.com/SSH-Mastery-OpenSSH-PuTTY-Tunnels-eboo...</a>
Some good tips here - I like Controlmaster/Controlpath.<p>Note that on the tip of ~/.ssh/known_hosts providing ssh auto completion, adding SSH server config to ~/.ssh/config will also enable auto completion.
About the "Lightweight Proxy" (ssh -D), if you want it to be transparent to the application (not require SOCKS support), you can use my tun2socks[1] program. This is useful if you can't or don't want to set up an SSH tunnel (which requires root permissions on the server). The linked page actually explains exactly this use case. It even works on Windows ;)<p>[1] <a href="https://code.google.com/p/badvpn/wiki/tun2socks" rel="nofollow">https://code.google.com/p/badvpn/wiki/tun2socks</a>
Another useful (albeit ugly) hack is accessing a NATed host which doesn't even have a port forwarded, via an intermediate SSH host <i>outside</i> the target network: <a href="http://superuser.com/questions/277218/ssh-access-to-office-host-behind-nat-router/277220#277220" rel="nofollow">http://superuser.com/questions/277218/ssh-access-to-office-h...</a><p>(disclaimer: tooting my own horn here, but it is a mighty useful trick)
I have a setup similar to this:<p><pre><code> laptop - user (userid: me)
F - firewall (userid: me)
A - machine 1 in colo (userid: colo)
B - machine 2 in colo (userid: colo, machine I want to access)
C - machine 2 in colo (userid: colo)
.
.
100s of machines.
</code></pre>
Trust (ssh password less login) is setup between me@laptop and me@F, and me@laptop and colo@A, and between all colo machine (A,B,C..). So colo@A can ssh colo@B w/o password.<p>I am able to log into colo@A via F w/o password as I copied the ssh key there manually. (path me@laptop -> colo@F -> colo@A)<p>QUESTION: Is it possible to ssh to other machines (B,C..) via A while assuming full identity of colo@A? (Path would be me@laptop -> colo@F -> colo@A -> colo@B/C/..) With my current config when I try to ssh to B it knows request is originating from 'laptop' and still asks me for password.
While the socks proxy does not require any root (local or remote), it is only useful for programs that support it - which are not many.<p>However, apenwarr's sshuttle <a href="https://github.com/apenwarr/sshuttle" rel="nofollow">https://github.com/apenwarr/sshuttle</a> is a briliant semi-proxy-semi-vpn solution that, in return for local root and remote python (but not remote root), gives you transparent VPN-style forwarding of TCP connections (and DNS requests if you want). It works ridiculously well. Try it, if you haven't yet.
Very interesting article;<p>I have a shell script that helps with setting up trusted keys: trusted keys help if you need to run automated tests, that involve several machines, or simply if you would like to skip typing in a password on each connection.<p><a href="http://mosermichael.github.io/cstuff/all/projects/2011/07/14/ssh-friends.html" rel="nofollow">http://mosermichael.github.io/cstuff/all/projects/2011/07/14...</a>
Is sshfs a serious replacement for nfs? I've got a Buffalo Nas at home that I use Samba for, but Samba is too slow to watch hi-def videos over. NFS seems to be a pain in the neck to get working on that particular device, and I hate using it on a laptop. I guess I should probably just try it, but I can't see SSHFS as being any faster than Samba.
for me best trick with ssh so far is to use ssh as proxy command:
ssh -o ProxyCommand="ssh -W %h:%p user@ssh_jump_host.somedomain.net -p some_non_22_port" user@some_host_inside.lan -D 1234<p>above creates dynamic tunel (for use as socks proxy) through jumphost to reach http hosts available only to some_host_inside.lan machine