Slashdot Mirror
Getting the Most Out of SSH
jfruh writes "If you have to administer a *nix computer remotely, you hopefully ditched Telnet for SSH years ago. But you might not know that this tool does a lot more than offer you a secured command line. Here are some tips and tricks that'll help you do everything from detect man-in-the-middle attacks (how are you supposed to know if you should accept a new hosts public key, anyway?) to evading restrictions on Web surfing."
What are your own favorite tricks for using SSH?
Yep I shoulda looked before I clicked...nothing non-obvious here folks, move along.
Here's an actual handy tip: You can make your RSA keyfiles also act as shellscripts for the connection, so you only need to carry 1 file to open the connection from any *nix machine.
To do it, just prefix your keyfile (say it's called ssh_my_server) like this:
#! /bin/sh
ssh user@hostname -i ssh_my_server
exit
----------BEGIN RSA PRIVATE KEY--------
(key goes here, use 4096-bit key for extra l33tness)
Make the file executable and now you can open the connection just by cd'ing to it and running it.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Comment removed based on user account deletion
It does matter though. Didn't use screen? Lost a connection? Your processes are terminated. Linux sucks in that regard, you need to know about the hangup "feature" that immediately kills your processes when the terminal dies.
Yes, but this isn't even explained in the article!
I am the developper of libssh (www.libssh.org).
SSHFS is slow because it's a packet based TCP-encapsulated file transfer protocol. All requests are initiated by the client and somewhat replied to by the server in an asynchronous design, but in practice no sftp server really has an asynchronous implementation. Opening a file, querying its length and downloading 8KiB require at least 3 or 4 RTT.
Compare with NFS, UDP based and mostly kernel-land and fully asynchronous.
Crypto is the main overhead in libssh and I suspect in openssh too, mainly because the crypto libs used do not probe for AES extensions or accelerators by default. And last but not least, OpenSSH's Channel window handling (similar to TCP windows) is not optimal for bulk transfers at high speed.
There are also some remote filesystem features missing in SFTP, like server-send feedback, locks and friends.
Telnet isn't, it only works "by accident" because the protocol is similar enough to plain text to work sometimes.
Bullshit. It was designed that way. And I can prove it, unlike your assertion.
http://tools.ietf.org/html/rfc15
brandelf -t FreeBSD
Emails are cached in a lot of intermediate servers and stuff. The logs are routinely backed up. Undelivered emails get forwarded to all sorts of addresses and admins. Even if nobody was maliciously scooping on you, the passwords could land on some random person's hands.
It *is* more secure over the phone in that sense.
And it's not a common practice to log down telnet traffic. Anyone who gets your telnet password is probably sniffing maliciously.
Not to say it's a sane policy to use telnet, but there are these differences in "levels" of safety (both levels are of course very very low). To a security conscious person it may be equivalent, but practically you have less chance a random John Doe will get your password this way. Maybe it matters, don't ask me....
Don't quote me on this.