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?
If you're still using telnet to administer anything that offers SSH, you should probably choose another field to work in.
(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
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 ?
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
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”.
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.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Rather than more complaining, I thought I'd say my favorite option. I like using the ~/.ssh/config file and the use of a master connection. In mine, I have:
host *
controlmaster auth
controlpath ~/.ssh/ssh-%r@%h:%p
controlpersist yes
This creates a master socket on my client. When I first connect, I need to use my passphrase. But when I exit, the SSH tunnel stays up. Futher connections via SSH and sftp and scp use this connection, multiplexed. So no more asking from my passphrase. When I'm finished for the day, I close down the connection with
ssh -O exit host
replacing "host"
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.
Traffic pattern matching over SSL. A web session over an SSL connection looks very different than an ssh tunnel session over SSL, not to mention the length of life of the socket. It's trivial to have the firewall identify the ssh connection over port 443 and disconnect it in the first few seconds of the session based purely on the pattern of the traffic regardless of content.
The Master (Angelo Rossitto) in Mad Max Beyond Thunderdome, "Not shit, energy!"
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!
To be fair, I'm sure there are sixteen year olds reading /.
I don't expect every article to be useful to me. Not sure why you would expect that.
I haven't read the article - I think I'm familar enough myself with ssh - but as long as the info is accurate, I'd image it's a useful tutorial for folk getting into Linux.
Using sshuttle, the applications don't even need to support SOCKS; it proxies all traffic over SSH.
Dilbert RSS feed
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."
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Get real SSH tips from people complaining (rightly or not) that it doesn't contain any actual advice.
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...
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: /dev/sda1 | nc localhost 2222
$ cat
# 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!
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