Forgot your password?
typodupeerror
Encryption Security Unix Technology Linux

Getting the Most Out of SSH 284

Posted by Soulskill
from the for-remote-controlling-your-nuclear-submarine dept.
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?
This discussion has been archived. No new comments can be posted.

Getting the Most Out of SSH

Comments Filter:
  • by MasterMan (2603851) on Monday March 26, 2012 @01:49PM (#39476511)
    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.
    • by buchner.johannes (1139593) on Monday March 26, 2012 @02:03PM (#39476683) Homepage Journal

      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.

    • by Anrego (830717) *

      Indeed. And that was the closest thing to an "ultimate hack". Everything else was basic intro to Linux type stuff.

      That and the randomart stuff was very poorly explained. Personally I think that feature is pointless anyway. If you are in a position where you feel you might actually get a MiM attack.. copy the key onto a USB stick.

    • The 16 tricks are pretty high level, while some people still don't know that 'PermitRootLogin' in sshd_config is set to 'yes' by default...
    • by jellomizer (103300) on Monday March 26, 2012 @02:15PM (#39476811)
      Well to be fair not everyone had SSH when they were 16 years old...

      I was 16 once, and I would try to figure out how to do all the cool new trick that my new systems has... As we get older we get in a groove (mostly due to the fact that we are paid to do a particular job, and if we spend too much time finding something new and cool would prevent us from getting things done by are estimated time)

      And after 8+ hour of work when we get home the last thing we want to do is more work.
    • by GameboyRMH (1153867) <gameboyrmh@@@gmail...com> on Monday March 26, 2012 @02:15PM (#39476813) Journal

      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.

      • by Anrego (830717) *

        Wow. Thanks!

        And yeah.. that was more useful and more worthy of being called an "ultimate hack" then everything in this lame article combined.

    • by Albanach (527650) on Monday March 26, 2012 @02:24PM (#39476897) Homepage

      Hell, I knew about these things when I was 16 and so did every other guy I knew who ever had used SSH.

      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.

      • by Anrego (830717) *

        Problem is the article is all over the place. It lists basic "intro to linux 101" stuff right next to "security paranoid enterprise server admin" stuff (which is does a very bad job of explaining anyway).

        There are plenty of good "intro to SSH" articles and plenty of good "advanced SSH tricks" articles out there. This is just trash.

    • I know about a lot of stuff like this too, but when I was 16 the internet didn't really exist the way it is today. I remember using telnet and rsh for everything for example.

    • Well good for you. You're a 1337 h4x0rz, I guess. There are still some people in the world who are just getting their feet wet.

    • 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

    • by miknix (1047580) on Monday March 26, 2012 @03:37PM (#39477765) Homepage

      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:
      $ cat /dev/sda1 | nc localhost 2222

      # 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!

  • Hopefully? (Score:5, Insightful)

    by Enry (630) <enry.wayga@net> on Monday March 26, 2012 @01:51PM (#39476545) Journal

    If you're still using telnet to administer anything that offers SSH, you should probably choose another field to work in.

    • Re:Hopefully? (Score:5, Interesting)

      by hcs_$reboot (1536101) on Monday March 26, 2012 @01:56PM (#39476605)
      well I occasionally use 'telnet host 25' to test the smtp port
      • Re:Hopefully? (Score:5, Insightful)

        by buchner.johannes (1139593) on Monday March 26, 2012 @02:01PM (#39476645) Homepage Journal

        Telnet has a protocol. Look at socat and netcat. Socat supports ssl, you can check your smtps server port.

      • by vlm (69642)

        Port 110 is trivially tested by hand... port 80 also.

    • Re:Hopefully? (Score:5, Interesting)

      by CubicleZombie (2590497) on Monday March 26, 2012 @02:10PM (#39476749)
      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.
      • by bzipitidoo (647217) <bzipitidoo@yahoo.com> on Monday March 26, 2012 @03:03PM (#39477339) Journal

        And in 2002, when I was contracting for the government, I needed some data that was stored on a government server. They set up a user account for me and rather than email the password to me, called to tell it to me over the phone, because they felt that was more secure than email.

        The joke was that I was to connect via telnet. They didn't have ssh on that server. They didn't even have some kind of secure telnet that would at least try to encrypt the password. Just plain old telnet, with the password transmitted in the clear.

        • Re:Hopefully? (Score:5, Informative)

          by sydneyfong (410107) on Monday March 26, 2012 @03:29PM (#39477645) Homepage Journal

          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....

      • Wait wha? I mean, I can see blocking it on outgoing ports in the firewall so that you can't tunnel to the outside world, but blocking it internally? Besides, it's trivial to set SSH to listen on port 23 and viola. New tunneling setup.

      • by Tassach (137772)

        Sounds like a case of throwing out the baby with the bathwater, but in a really secure environment, SSH *is* a huge can of worms, especially when combined with Corkscrew [wikipedia.org].

        I once worked for a large company with a draconian firewall policy and no remote access solution. SSH connections were forbidden in both directions. So, I came up with a ssh reverse tunnel solution.

        On a box inside the firewall, run this script as a daemon:

        #!/bin/bash
        while true
        do
        nohup ssh -O ProxyCommand=/us

    • by lcam (848192)

      There may be reasons to use telnet over SSH. Challenge the assumption that it's always better to encrypt communications rather then let someone listen in.

      That being said, your presumption is normally right; ISP administrators who block SSH and only allow file transfer by FTP fall into the same category. They should be fired.

      • Telnet is wide open to a MITM attack - besides just sniffing the password, suppose you have a shell open - then a MITM hijacking your TCP session could write an arbitrary rlogin file.

        My professor for the computer security class at my college demoed this exact scenario - its not a safe protocol.
    • by Darinbob (1142669)

      Ha, I'm still using rlogin!

    • by jd (1658)

      Hardware encryption is still not widely available and Linux support for it where it does exist isn't great (drivers belong in the kernel, especially drivers you need a high level of security for, but there's so much antipathy towards encryption in the kernel that hardware drivers that merely happen to involve encryption have a very hard time of it).

      As such, SSH is more CPU-intensive (unnecessarily, since a chip could offload the CPU-intensive part of the workload), which means there will be times when SSH i

      • by Enry (630)

        CPU-based encryption is hard, but there's ports like HPN-SSH that works to keep the connection fast while making sure the authentication still happens in a secure manner.

        My team maintains a system that has a few hundred people logged in at any time, both for interactive connections to our HPC cluster, but also to send data in and out. All of it goes over SSH and the CPUs are rarely breaking a sweat to keep up - it's usually the storage that is lagging.

        • by jd (1658)

          Agreed. Those tend to be thinner on the ground, though, which is incredibly annoying. There's also a lot less awareness of acceleration patches and ports, which I suspect has led to a lower adoption level than would have otherwise been the case. I can't remember the last person I talked to who was aware that such software even existed.

  • How's that again? (Score:5, Informative)

    by 93 Escort Wagon (326346) on Monday March 26, 2012 @01:53PM (#39476571)

    (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!

    • by Speare (84249)

      (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!

      Just because you use SSH doesn't mean you administer the machine.

      I get a cheap ISP, it offers shell access to help me set up my scripts or website. I usually access it through the hostname I've attached with my DNS record: ssh shell.mydomain.com One day, they

      • At what point do I shrug and trust the new machine, vs calling up the ISP to get some info on the latest fingerprint change?

        At no point. That is because there is no way for them to tell you the new key (or even that the key changed) whitout the possiblity it was forged. You shouldn't trust an email either.

        The wrong thing here is that they are changing the keys. They shouldn't. If they have several servers pretending to be one, they should configure them to share the key and IP address.

    • Yes, that is the point of the warning, but now that I've been warned, what's the proper next step?

      "OK, so I'm connecting to a server that I don't admin using SSH, and I don't already have the public key stored. So how do I know there's not a MITM attack going on?"

  • 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.
    • by allo (1728082)

      this is possible.

      first thing to look into:
      [enter]~?
      the ssh escape-key is ~, but only after a newline. and look out for deadkeys. ~? is a short help on this. There you can manage sub-connections and other stuff.
      ~. is very useful for terminating a ssh-process, which is still waiting for a network timeout.

      And multiplexing a single ssh-connection: read the manpage of ssh for "ControlMaster". then a unix-socket which contains username and hostname in the filename is used to use a single ssh-connection for multip

  • Wow (Score:5, Interesting)

    by frodo from middle ea (602941) on Monday March 26, 2012 @02:01PM (#39476653) Homepage
    Wow, ssh tunneling, and a few command line options , and screen, that's your ultimate SSH guide ?
    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 ?

    • Re:Wow (Score:4, Insightful)

      by mlts (1038732) * on Monday March 26, 2012 @02:40PM (#39477043)

      I'd love to see stuff like that as well as:

      OpenSSH signed certificates (Not X.509) and TrustedUserCAKeys options and their usage. This way, I can hand a new cow-orker signed ssh host keys and assuming he or she knows enough not to just blindly replace a key if it isn't right, will minimize the chance of a MITM attack.

      Revoking SSH keys.

      Using SSHGuard to lock out brute force attempts.

      Proper configuration of the sshd_config file. Stuff like only allowing root in via RSA keys (or blocking root access entirely.)

      Auditing logs to know that key "A" ssh-ing to root is from user Alice, and key "B" is from Bob, so that one can tell who just wiped out the wrong filesystem come an inquiry.

      Running sshd as a user, not as root.

      Getting a backup program like NetBackup to form a ssh tunnel, do the backup, then close down the connection cleanly.

    • by Qzukk (229616)

      Or the key agent, or ~, or...

    • This is intermediate at best. I need to spend more time on IRC if I can expect to stay in the game.
  • Really lame (Score:5, Informative)

    by Anrego (830717) * on Monday March 26, 2012 @02:02PM (#39476671)

    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”.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      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

    • Re:Really lame (Score:5, Informative)

      by Anonymous Coward on Monday March 26, 2012 @02:32PM (#39476971)

      I am the developper of libssh (www.libssh.org).
      SSHFS is slow because it's a packet based TCP-encapsulated file transfer protocol. All requests are initiated by the client and somewhat replied to by the server in an asynchronous design, but in practice no sftp server really has an asynchronous implementation. Opening a file, querying its length and downloading 8KiB require at least 3 or 4 RTT.
      Compare with NFS, UDP based and mostly kernel-land and fully asynchronous.
      Crypto is the main overhead in libssh and I suspect in openssh too, mainly because the crypto libs used do not probe for AES extensions or accelerators by default. And last but not least, OpenSSH's Channel window handling (similar to TCP windows) is not optimal for bulk transfers at high speed.
      There are also some remote filesystem features missing in SFTP, like server-send feedback, locks and friends.

    • by Qzukk (229616)

      (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?)

      What happened is that advances in communication at the kernel has made everything else MUCH faster. System calls like sendfile() basically tell the kernel to dump everything in the file to that port and don't bother me until you're done, which eliminates all of the syscall context switching overhead for read()ing data from the file to a

  • SSh tunnel (Score:2, Funny)

    by Krneki (1192201)
    SSh tunneling is teh sex.
    • by manoweb (1993306)
      But a PPP over SSH gives you a complete VPN, not only a bunch or redirected ports.
      • OpenVPN beats both solutions.

      • plus the problems of layering multiple TCP layers above each other. Also, PPP is not needed anymore: ssh can establish VPN connections using tun devices quite fine ("-w")
        • by manoweb (1993306)
          That problem is more theoretical than practical. Back in the day I was doing videoconferencing H.263/SIP and all that stuff with PPP over SSH and I had no problem at all. And it works when there is a very strict (and stupid) firewall setting that does not allow but port 80 TCP destinations like at my University in the late 90's. Just one open TCP port and you have a full VPN that works well; other VPN systems were not quite as easy to put together.
  • 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!

  • by Anonymous Coward

    Also... screen? When there's tmux???

    • Re: (Score:3, Insightful)

      by tscheez (71929)

      I'd never used tmux. i've officially learned more from /. comments than the actual articles. Thanks!

  • Having multiple sessions over the same connection speeds up repeat connections: http://blogs.perl.org/users/smylers/2011/08/ssh-productivity-tips.html [perl.org] It's well worth setting up.
  • by Junta (36770) on Monday March 26, 2012 @02:09PM (#39476735)

    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.

  • My fav (Score:4, Interesting)

    by Anonymous Coward on Monday March 26, 2012 @02:10PM (#39476753)

    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"

  • by CarsonChittom (2025388) on Monday March 26, 2012 @02:15PM (#39476815) Homepage

    Michael Lucas, author of (amongst other things), Absolute OpenBSD, has a new book out called SSH Mastery: OpenSSH, PuTTY, Tunnels, and Keys [michaelwlucas.com]. It seems to be very informative and well-regarded in the OpenBSD community [undeadly.org].

  • by linuxtelephony (141049) on Monday March 26, 2012 @02:22PM (#39476879) Homepage

    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.]

    • by Erpo (237853)

      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.

      Such a policy would require the server to take the client's word for it that the private key was encrypted with a passphrase.

      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.]

      Agreed. If someone is removing the passphrase from their private key, there is some other problem that needs to be solved. Personally, I like ecryptfs for my home directory and LUKS for my backup drive with the LUKS passphrase inside my login keyring.

    • by lindi (634828)
      Passphrases on SSH keys help if somebody steals your backups but for almost anything else they are not very useful. If you somehow get access to the encrypted key of some user you very often also have access to their ~/.bashrc. Then you can easily trojan PATH that so that their passphrase is emailed to you next time they type it.
  • by preaction (1526109) on Monday March 26, 2012 @02:34PM (#39476983)

    Get real SSH tips from people complaining (rightly or not) that it doesn't contain any actual advice.

  • the 1970s was cool and all

  • Speedwise, ssh -2 still holds up my Mac 840AV up for several minutes to login :-)

  • 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 [cpan.org]

    Download the file, name it "remote-ssh-access". To read the perl documentation just use "perldoc remote-ssh-access"

  • Personally I like (Score:4, Interesting)

    by Rich (9681) on Monday March 26, 2012 @03:38PM (#39477781) Homepage

    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.

"Tell the truth and run." -- Yugoslav proverb

Working...