Server Administration

  Home arrow Server Administration arrow Page 2 - SSH Case Studies: More on Pine and SSH
SERVER ADMINISTRATION

SSH Case Studies: More on Pine and SSH
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating:  stars stars stars stars stars / 0
    2012-07-25

    Table of Contents:
  • SSH Case Studies: More on Pine and SSH
  • 11.3.2 Mail Relaying and News Access

  •  
     

    SEARCH CODEWALKERS

    SSH Case Studies: More on Pine and SSH - 11.3.2 Mail Relaying and News Access


    (Page 2 of 2 )

    Pine uses IMAP to read mail but not to send it. For that, it can either call a local program (such as sendmail) or use an SMTP server. Pine can also be a newsreader and use NNTP (the Network News Transfer Protocol, RFC-977) to contact a news server.

    An ISP commonly provides NNTP and SMTP servers for its customers, but obviously does not want to allow arbitrary people to use them. Modern extensions to the NNTP and SMTP protocols include authentication, and ISPs are starting to use and require them. Before such mechanisms were available, however, the usual method of restricting access to these services was via network address: the ISP would allow access from addresses within its own network (and hence hopefully only from its customers). Many ISPs have not yet switched to direct authentication for these services, and are still using address-based authorization; so, if you’re connected to the Internet from elsewhere and try to use your ISP’s mail server, the attempt might fail. Access to your usual servers might be blocked by a firewall, or the mail server might reject your mail with a message about “no relaying,” and the news server rejects you with a message about “unauthorized use.”

    You are authorized to use the services, of course, so what do you do? Use SSH port forwarding! By forwarding your SMTP and NNTP connections over an SSH session to a machine inside the ISP’s network, your connections appear to come from that machine, thus bypassing the address-based restrictions. You can use separate SSH commands to forward each port:

    $ ssh -L2025:localhost:25 smtp-server ...
    $ ssh -L2119:localhost:119 nntp-server ...

    Alternatively, if you have a shell account on one of the ISP’s machines running SSH but can’t log into the mail or news servers directly, do this:

    $ ssh -L2025:smtp-server:25 -L2119:nntp-server:119 shell-server ...

    or neatly automate it this way:

    [~/.ssh/config]
    Host mail-news-forwarding
    Hostname shell-server
    LocalForward 2025 smtp-server:25
    LocalForward 2119 nntp-server:119

    $ ssh mail-news-forwarding

    This is an off-host forwarding, and thus the last leg of the forwarded path isn’t protected by SSH. [9.2.4] But since the reason for this forwarding isn’t so much protection as it is bypassing the source-address restriction, that’s OK. Your mail messages and news postings are going to be transferred insecurely once you drop them off, anyway. (If you want security for them, you need to sign or encrypt them separately, e.g., with PGP or S/MIME.)

    In any case, now configure Pine to use the forwarded ports by setting thesmtp-serverandnntp-serverconfiguration options in your ~/.pinerc file:

    smtp-server=localhost:2025
    nntp-server=localhost:2119

    Even if your ISP uses direct authentication, you might choose to use SSH anyway if it does so poorly. For instance, some badly deployed services require password authentication but do not provide encryption for the connection! In this case, you would forward over SSH in order to protect your password.

    One possible complication: the SSH feature has a global on/off switch, applying to every remote mailbox. That is, ifssh-open-timeoutis nonzero, Pine tries to use this style of access for every remote mailbox. If you have multiple mailboxes but only some of them are accessible via SSH/imapd, this leads to annoyance. Pine falls back to a direct TCP connection if SSH fails to get an IMAP connection, but you have to wait for it to fail. If the server in question is behind a firewall silently blocking the SSH port, this can be a lengthy delay. If you’re in this situation, you can disable SSH access for specific mailboxes using the/norshswitch, like this:

    {imap.example.com/user=smith/norsh}inbox

    That’s not a typo: the switch is/norshrather than/nossh. This is just an historical artifact of the software: originally, Pine supported this style of mailbox access via rsh. In fact, there are still configuration variables—rsh-path,rsh-command, andrsh-open-timeout—that function entirely analogously; so much so, that in the first edition of this book, we described how to use SSH with older versions of Pine by simply setting rsh-command to “ssh”. Anyway, /norsh turns off the use of both the ssh or rsh features of Pine for the mailbox in question.

    11.3.3 Using a Connection Script

    The Pine configuration option ssh-path can point not only to ssh, but also to any other program: most usefully, a script you’ve written providing any needed customizations. If your needs are complex, you might have to do this. For example, the ssh-path setting is global to all mailboxes, but perhaps the imapd executable is in different locations on different servers you want to access. You can solve this problem with a script which takes the four ssh-command arguments from Pine, and does the right thing depending on which server is specified:

    ssh-path=/home/smith/bin/my-pine-ssh-script
    ssh-command="%s %s %s %s"

    where the script my-pine-ssh-script is:

    #!/bin/sh

    ssh=$1
    server=$2
    user=$3
    method=$4

    prefix="exec $ssh -qax $user@$server exec"

    case $server in
    mail.work.com) $prefix /usr/sbin/imapd ;;
    imap.isp.net) $prefix /usr/local/sbin/imapd ;;
    *) exit 0
    esac

    The default action ofexitwill cause Pine to skip SSH access quickly for servers other than the two mentioned.

    Please check back next week for the next part of the series.


    DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.
    blog comments powered by Disqus

    SERVER ADMINISTRATION ARTICLES

    - SSH Case Studies: Gateway Hosts
    - SSH Case Studies: More on Pine and SSH
    - SSH Case Studies: Pine and IMAP
    - SSH Case Studies: More on the Passive Mode
    - SSH Case Studies: Network Address Translation
    - SSH Case Studies: The Passive Mode
    - SSH Case Studies: The FTP Protocol
    - SSH Case Studies: Batch Jobs, FTP and SSH
    - SSH Case Studies: Agents and Authentication
    - SSH Case Studies
    - Server Responses to Client Communication
    - Authentication in Client/Server Communication
    - Client/Server Communication
    - Understanding Awk in the UNIX Shell
    - Stream Editor in the UNIX Shell

    Developer Shed Affiliates

     



    © 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap