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?
(how are you supposed to know if you should accept a new hosts public key, anyway?)
Seriously? If you don't know enough about what's going on with the machine at the other end to make that decision... that's the whole bloody point of the warning!
#DeleteChrome
Tip 16 and friends (the keyart stuff) is very poorly explained. You don’t know that the key is secure, but you magically know that the randomart is? That’s the bit they forgot to mention. It’s a visual representation of the key that _you have to have seen before to be able to verify_. Personally if you are going to go to the trouble.. I say throw the key on a USB stick and be done with it.
The screen stuff maybe worth mentioning the more modern alternative tmux.
SSHFS is better than NFS
For quick one-off stuff .. maybe. Cryptographic overhead is still startlingly effective at slowing things down, even on fast hardware (random: can anyone explain why.. you’d think it shouldn’t make any difference at this point.. I’m guessing it has something to do with network framing?).
Tip 4 (logging in with server-specific keys ) seems like the kind of thing that very few people will ever need to do.. and if they do.. they’ll google it. Kinda silly putting it in an article like this.
Tip 2 (ssh tunnel) is probably the only thing in here that _might_ be considered an “ultimate” hack (everything else is pretty much Linux 101).
Tip 1 (Evading silly web restrictions) is great. Alternate title: “my job is important, but damnit I need my facebook/twitter fix”.
That's what nohup is for
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
I generally prefer the apps on my desktop rather than the remote apps. "ssh -D 8080 " will start a SOCKS4/SOCKS5 server running on your local port 8080 and proxy the connections out the remote side. This allows all of your SOCKS enabled applications on your local workstation to make use of the tunnel without having to setup a one to one port mapping.
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!
Using sshuttle, the applications don't even need to support SOCKS; it proxies all traffic over SSH.
Dilbert RSS feed
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
smtps was deprecated years ago (not that I agree). You should use:
openssl s_client -starttls smtp -connect host:(25|587)
Something socat doesn't appear to support (that's a first).
To be honest I don't know, but these man pages show
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument must be "yes", "without-password", "forced-commands-only" or "no". The default is "yes".
Slashdot, fix the reply notifications... You won't get away with it...
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.
My mistake, then. I'd heard they'd gone the same route as OS X (incorrectly, it appears). Apologies to all.
Nope, you heard correctly. The bit you're mistaken about is that OS X also has a root user. In both cases, the account is "locked" (no matchable password is set). Set a password for the root user and it works as normal.
Igor Presnyakov stole my hat
Host gate1
Hostname 128.141.81.163
User joe
Host local12
Hostname 192.168.1.12
User joe
ProxyCommand ssh -e none gate1 exec netcat -w 5 %h %p
You can now ssh to "local12" just by typing "ssh local12", whether you are on the LAN or not.
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done