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?

Comments

Hopefully?

[Enry]

If you're still using telnet to administer anything that offers SSH, you should probably choose another field to work in.

Re:Hopefully?

[CubicleZombie]

I've worked in organizations where, because you can tunnel over SSH, it was banned and blocked over the network. Everything had to be done with Telnet instead. I'm not joking. That is probably what started my loathing of net admins.

Re:Hopefully?

[Galactic Dominator]

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

Re:Hopefully?

[sydneyfong]

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

Wow

[frodo from middle ea]

Wow, ssh tunneling, and a few command line options , and screen, that's your ultimate SSH guide ?
I am impressed, not!

How about
- ssh master connection, for svn+ssh ?
- ssh agent forwarding
- opening ssh ports using knocking
- auto blacklisting with something like sshblack

I think the above are more advanced options than the ones mentioned in the article, no ?

Re:InfoWorld at it again

[buchner.johannes]

My favorite trick is
1) have a server on the internet, let someone ssh -R their port 22 there
2) connect to that server too with ssh -L putting their port 22 on the local port 8022
3) Now you have a peer-to-peer ssh (with -Y), and you can run graphical applications remotely.

Re:InfoWorld at it again

[GameboyRMH]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:InfoWorld at it again

[MasterMan]

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!

Re:Really lame

[Anonymous Coward]

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.

Re:InfoWorld at it again

[nschubach]

In my opinion, I think it might be a better idea to kill the errant job if the controller/user gets disconnected than to continue with a job that may need a followup command that may never come, possibly leaving the server in an unusable state. So you have a choice of trusting the user or having the user say explicitly, "trust me, this is what I want to happen (screen/nohup)... even if I get disconnected."

This Article's True Purpose

[preaction]

Get real SSH tips from people complaining (rightly or not) that it doesn't contain any actual advice.

Re:InfoWorld at it again

[miknix]

What about unlimited encrypted storage?

you need TCP forwarding enabled in your sshd_config, then

ssh -L localhost:2222:localhost:2222 localhost
$ echo "data you wanna save" | nc localhost 2222

# or if you want to backup your hdd, try:
$ cat /dev/sda1 | nc localhost 2222

# the data will be forwarded forever in the loopback link at no cost until you read it back:
$ nc localhost 2222 > hdd-backup.bin

# profit!