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?
Seriously, anyone who uses SSH knows about things like proxying your connection via the connection and X11 forwarding. This is nothing new. This is just InfoWorld getting backlinks and traffic from Slashdot once again. Hell, I knew about these things when I was 16 and so did every other guy I knew who ever had used SSH.
If you're still using telnet to administer anything that offers SSH, you should probably choose another field to work in.
SSH Tunneling by far: http://www.debian-administration.org/article/38/Tunneling_connections_securely_with_SSH
I hope the list of tricks includes skipping the banner ad while trying to look at the page containing the tricks...
(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'd always have liked that I could transfer a file or an stdout/stdin stream directly in the middle of an open ssh session. Also the file transfer / stream should be carried over nested ssh connections.
Imagine that you could just pipe the output from a command into some magical ssh command in a remote machine and your ssh client would ask where you would like to pipe the stream in your local machine.
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".
there's a 2600 article on how to use ssh to run commands in a very INTERESTING way.... check out the past 6 issues, cant remember which one.
Buanzo Consulting - 15 Years of GNU/Linux experience, for you.
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”.
SSh tunneling is teh sex.
Love many, trust a few, do harm to none.
Anybody that knows what they're doing already knows this, but since /. is quickly becoming a refuge for retards, other uses for SSH also include:
1.) File transfers between 2 hosts (via scp or sftp)
2.) Tunnelling (aka the "poor man's VPN"...great for accessing hosts behind a Unix-based firewall securely without having to setup additional DNAT rules)
My favorite is to use SSH remote port forwarding (-R) to allow my machines to connect back home from an unknown (and possibly changing) IP and then allow me to ssh back to them. And key authentication all the way along!
And, by the way, SSH tunneling is not TCP port forwarding!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Also... screen? When there's tmux???
Having multiple sessions over the same connection speeds up repeat connections: http://blogs.perl.org/users/smylers/2011/08/ssh-productivity-tips.html It's well worth setting up.
Basically they go into some detail about the ascii art representation, and at the end acknowledge that you need to securely get the keys to know what to expect. If you have a secure means of getting the ascii art, you have a secure means of getting the key. The only exception I can think of is if you have someone cell-phone picturing the local console, which could be helpful.
The real useful thing would be for people to do DNSSEC and SSHFP records.
XML is like violence. If it doesn't solve the problem, use more.
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"
Multi-threaded SSH is a pretty nifty patch for getting more out of your ssh connections.
Comment removed based on user account deletion
Comment removed based on user account deletion
I had forgot about this for a while due to VPN shenanigans, but tunneling your web traffic through an SSH is a great way to secure your web sessions if you don't have a VPN setup. I have also found that using Cygwin/SSH to secure your RDP can also be pretty boss if you have to work on M$ machines from remote very often.
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
Get real SSH tips from people complaining (rightly or not) that it doesn't contain any actual advice.
there, fixed that for ya.
i want the old slashdot back. i could put up with the general
technical ability around here dropping, but when slashdot assumes
we're all managers, that pisses me off.
here's who infoworld is aimed at
http://search.dilbert.com/search?w=trade+magazine&view=list&filter=type%3Acomic
...well-regarded in the OpenBSD community.
That is to say, both of them agree.
How about an article discussing the pros and cons of various types of encryption including speed. Actually, what is the fastest encrypted file transfer protocol (don't say ftp in a vpn)? SCP seems to really fall down here.
the 1970s was cool and all
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Speedwise, ssh -2 still holds up my Mac 840AV up for several minutes to login :-)
First off there is this beauty called ssh-agent, which allows for SSO functionality; ssh-agent requests can be forwarded and tunelled through multiple ssh hops (although agent forwarding places some extra trust in the other machine's admin). You can use ssh-agent as a PAM authentication module, so that you don't have to use your password for sudoing etc.
A poor man's VPN can be done by placing pppd at both ends of the ssh connection. In newer version, ssh can do this automatically via tun device redirection.
Little is known about the 'ssh command line' activated via ~C where you can add/remove/edit port forwards for current session.
SSH keys support certification authority scheme similar to SSL keys.
And finally a lot of magical and wonderful things can be created by mastering the ssh daemon configuration (especially wrt authorized_keys).
The has also been a WIkibook on OpenSSH out for a year or so. The prose may not be the best but the tips are there.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Feel free to check out a little perl utility I wrote for creating aliases or shortcuts for remote ssh logins. If you have a lot of hosts to manage it can make your life easier:
http://www.cpan.org/authors/id/L/LD/LDAVIS/remote-ssh-access-1.7
Download the file, name it "remote-ssh-access". To read the perl documentation just use "perldoc remote-ssh-access"
It's true no man is an island, but if you take a bunch of dead guys and tie 'em together, they make a good raft.
> The example assumes you have a sudo user set up with appropriate restrictions,
> because allowing a root login over SSH is considered an unsafe practice.
Yeah, because an attacker that has succesfully cracked your sudo account will NEVER come up with the idea to alias your su/sudo command so that it mails him the password.
Comment removed based on user account deletion
example -- http://ansible.github.com
OP should be -1 overrated. You jerks who keep saying things like "everyone is doing X because I am" or "this isn't knew" or "this isn't important" really need to STFU. There are people coming into the world all the time who haven't learned what you learned or had the same experiences that you do. Much of what you learned from is burried now under mountains of information and its very often not clear where people should start from. So sit down, shut up and let others learn, otherwise all you will do is scare them away so that they never will. Not everything is some conspiracy to generate ad revenue.
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.
Real trick here, if you're using ssh -L often use: -c arcfour, that cipher is very fast.
On the last example , they tunnel http thru the ssh, but leave the DNS queries exposed.
Author forgot to set Firefox to tunnel DNS requests, alot of danger is still exposed via DNS.
Author is a noob, who just discovered ssh, and now cant shut up about it.
Hashie
@ TrYPNET.net
Comment removed based on user account deletion
Couple of good ones there.
Didn't mention my two favourites:
1) Loop a -R and a -L to handily crash the server
2) Use tunnelling to gain access to services that you, as a plain old unprivileged local user, aren't supposed to have access to
Good old Infoworld, doesn't know the difference between Monkey-in-the-Middle and Man-in-the-Middle
AccountKiller
Add the output to your DNS and set VerifyHostKeyDNS to "yes" or "ask" in your ssh_config.
Remember to update your DNS if/when your machine gets a new SSH hostkey.
alias sudo="echo make it yourself #" ; # https://pipedot.org/~stderr & http://soylentnews.org/~stderr
And it's not a common practice to log down telnet traffic. Anyone who gets your telnet password is probably sniffing maliciously.
Yeah, that is the most likely scenario. But I work in embedded design. And even though we've screamed to have two networks in the office it hasn't happened. So that means DUT and the office computers are on the same net. I've had to work on ethernet drivers that were malfunctioning. So I downloaded Ethereal (now Wireshark) to debug.
And was immediately and completely horrified at what I saw.
The very next thing I did was to set up a proxy server at home and get zebedee working (windows environment - ssh would have been difficult) and proxy everything I do.
Weaselmancer
rediculous.
While on the topic, note the new book by Michael Lucas:
http://www.michaelwlucas.com/nonfiction/ssh-mastery
...well-regarded in the OpenBSD community.
That is to say, both of them agree.
Ever seen an OpenBSD hackathon? I have. I'd guess 75 people were there, and that's just the devs who could make it.
A$$hole.
"Tongue tied and twisted, just an Earth bound misfit
If you seriously haven't figured it out yet, InfoWorld is obviously paying slashdot editors to post articles. I don't know how it could possibly be any more obvious.
Host medium to high powered and have pulseaudio installed using a decent distro like Debian (Ewebuntu is broken). Enable network sound.
Client old laptop with minimal install that includes pulseaudio. For Debian you need to enable ForwardX11Trusted. Login to the Host box using "ssh -XC vlc". Now enjoy movies without stuttering sound or dropped frames on a box that would struggle to run W95. 32MB of RAM will work fine.
My personal favorite "trick":
Add the above to ~/.ssh/config, and from then on I can SSH to machines inside my company's firewall by first connecting to a secured bastion host, just by running ssh internalmachine.example.com. If you do a lot of work from home, or have specially secured machines at the office that require intermediate connections, you can set up proxying and make it automatic and easy to connect to them.
Dewey, what part of this looks like authorities should be involved?
www.commandlinefu.com - Some more shameless advertising for a site I have nothing to do with apart from frequenting quite often!
Probably one of the cooler tricks I saw the other day was being able to ssh into a remote box and push the signal from your pc mic onto the remote machines speakers and vice versa!
Lot's of fun was had in our office that day!
man ssh
Here are some interesting projects you can progress with after reading this article.
I was also a bit surprised to see basic stuff and some repetition in the article there, but trick #3 was really nice for me:
ssh-keygen -R remote-hostname
This will remove the entry for remote-hostname in the known_hosts file, for example if you know the key changed or (don't do that) if you think you're in a MITM attack and don't care.
now that will fix many countless fiddling around the known_hosts file...
Semantics is the gravity of abstraction
I think it's worth mentioning to anybody who enjoyed this article that Michael W. Lucas has a fresh SSH book out called 'SSH Mastery'. Initially an ebook, but becoming available right about now in a paper version too.
Amazon will have it, or if you're shopping for OpenBSD stuff anyway (as you should, OpenSSH which is almost certainly the ssh and sshd on your system, is essentially an in-tree development at OpenBSD), www.openbsd.org/books.html and tentacles of the ordering system will show you where to get it.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
My guess is the editors have so many stories to choose from, they've got some keyword filters set up and pick out of that lot. That would explain why there are so many stories along the same lines, which gets kind of repetitive.
ssh root@10.0.0.245 "tcpdump -l -n -s 0 -w -not port 22" wireshark-i -
I often use -D in combination with the FoxyProxy add-on for Firefox.
Set up some nice URL filters to send some traffic through the SOCKS proxy, while other traffic just uses the default connection.
No more switching back and forth Firefox's proxy settings.
Yes, it can be done. I read about it back in 2007. "Tunneling BitTorrent over SSH"
No sig for you! Come back one year!
I had a friend suggest to me something a ways back that I thought was pretty clever.
If you're ssh'ing to your box for a proxy from say, work, you might not be able to get out since outbound connections might be disallowed by your company's firewall (or what have you). Even if outbound connections on 22 (or whatever oddball port you're running your ssh server on) are allowed, weird traffic like that might raise some eyebrows and get you in trouble.
My friend's idea was to have ssh running on port 443 on your proxy box provided you don't have a web server using ssl running. Pretty much any firewall that has a website behind it has 80 and 443 open. In addition, 443 is ssl encrypted so when your encrypted ssh traffic goes through it, it hopefully won't raise much suspicion.
--
It's an excellent book-- short, concise, clear and nicely explained. Delivered by Amazon today. Thanks for the information.
Everything I've ever learned the hard way was based on a statistically invalid sample.