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?
well I occasionally use 'telnet host 25' to test the smtp port
Slashdot, fix the reply notifications... You won't get away with it...
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".
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.
Also... screen? When there's tmux???
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.
:wq
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"
I wish it was possible to require SSH keys for some (or even all) users to have a passphrase, and enforce this requirement on the server.
As it stands right now, even if you generate a key for someone with a pass phrase, they can remove it easily on the client side and the server has no way of knowing. This means you could have passwordless logins to remote systems. Not good.
At least with modern systems and key agents you can get passwordless ease of use once you log into your local account, and if someone happens to get your private key they don't immediately have instant access to the machines you can log into. You should have a little time to secure the machines. [Think lost/stolen laptop or backup drive.]
. 62,400 repetitions make one truth -- Brave New World, Aldous Huxley
Any clued network admin will eventually get wind of a ssh connection going to the same box from someone's workstation, especially if there is a lot of traffic going to and from it. Then, depending on how much they like/dislike the person with the tunnel, they will either ignore it, mention to be careful about PPP over SSH in passing, randomly kill the connection, block the destination IP at the router, block ssh from going outside from that workstation, or just sit there, watch statistics, then present HR with a case that a user is doing something they shouldn't by constantly sending encrypted traffic to a box that isn't owned by the company or anyone relevant. That right there is good enough to get someone sacked in most companies, especially ones with more paranoid and clueless PHBs.
Of course, one can ssh to a different port, but most IDS/IPS systems can detect a bunch of encrypted traffic over a TCP port and send a note to the admins, or just automatically lock the workstation out from the rest of the network.
So, the guide of using ssh as a tunnel is just plain stupid, and a good way to get fired for gross misconduct (which means no unemployment).
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.
tar cf - somedir | ssh remote@remotehost 'tar xf -'
A nice way to get things moved around. a similar trick is:
tar cf - somedir | (cd /a/local/path; tar xf - )
Which lets you copy things around a local file system.