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
(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"
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
Thank heavens for Ghostery.
You misspelled "NoScript".
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
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
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 :-)
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.
I stopped taking NoScript seriously when they thought it was a good idea to deliberately disable AdBlock and obfuscate the code that did so.
Comment removed based on user account deletion
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.
Comment removed based on user account deletion
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.
Why is it that Firefox sets network.proxy.socks_remote_dns to false by default? I know of several scenarios where setting it to true works better than setting it to false. I don't know of any situation where the default value is actually better.
Do you care about the security of your wireless mouse?
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.
No seriously though, NoScript doesn't prevent plain-HTTP tracking, which is gaining more and more popularity again these days and is used by Facebook.
"When information is power, privacy is freedom" - Jah-Wren Ryel
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/
Can you elaborate?
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 -
A good review of the issue was documented on the website of yet a different extension: DownThemAll! - Can I trust NoScript any longer?
Basically, NoScript got upset that AdBlock made it possible to block ads on their site. (Note: by default, the NoScript site gets opened on every update.) So NoScript issued an update that crippled AdBlock's ability to block anything. This was discovered and NoScript, under pressure, changed to automatically add a forced white-list for their own site. Eventually, that was changed to allow opt-out, and then removed entirely. But the trust is still damaged; I haven't used NoScript since then.
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.