SSH Connection to Raspberry Pi over WAN

[Feathers McGraw]

Oshunluvr,

On the Pi I have two config files:
/etc/ssh/ssh_config
/etc/ssh/sshd_config

Do I change port 22 to whatever in both of those, and then edit ~/.ssh/config on my laptop?

[Feathers McGraw]

Changed the port in /etc/ssh/sshd_config and restarted sshd.

Added the following to my ~/.ssh/config :

Host samhobbs.co.uk
User admin
Port ****

Changed the port on my router's firewall.

Everything works!

[SteveRiley]

Anyway, is it really that simple to fool your ISP? Do they monitor certain ports and not others?

I periodically scan the forums at www.dslreports.com and similar sites to find out what people report about Comcast, my ISP. Their T&Cs regarding servers can be interpreted in different ways. The conventional wisdom is that if you don't exhibit obvious misbehavior, they'll pretty much leave you alone. Especially if you're a long-time customer with a good track record of paying the monthly bill on time. Since SMTP and SSH tend to attract a lot of abuse, the extra steps I've taken to reduce my attractiveness to bad guys seems wise.

I noticed that with a dynamic IP address and dynamic DNS my outgoing mail was rejected by outlook, gmail etc. I paid £5 for a static IP and had no further problems. I think IPs in dynamic pools may be blocked by some email providers.

Yes, that's right.

How exactly do you end up on a block list anyway?

Various ways... running an open relay, sending high volumes of mail from dynamic IP pools, having your MX record resolve to a dynamic pool, not having a PTR record for your mail server. These are the more common things the block list maintainers look for.

[Feathers McGraw]

The conventional wisdom is that if you don't exhibit obvious misbehavior, they'll pretty much leave you alone.

Yeah the research I did at the time indicated that most ISPs operate like this - you're fine until they notice you, and they won't notice you unless you cause them a problem (by using too much bandwidth etc). Fair enough really.

That makes sense, thanks for explaining why you've set things up the way you have.

What exactly is an open relay? Is that just a forwarding point from one mail server to the next, or somewhere that allows anyone to send mail (from foo@yourdomain.com)?

That's the first I've heard of PTR records. I read this:

http://aplawrence.com/Blog/B961.html

and then tried this:

feathers-mcgraw@62-West-Wallaby-Street:~$ dig samhobbs.co.uk

; <<>> DiG 9.9.2-P1 <<>> samhobbs.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6341
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;samhobbs.co.uk.                        IN      A

;; ANSWER SECTION:
samhobbs.co.uk.         849     IN      A       195.166.151.235

;; Query time: 38 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Oct  5 11:38:53 2013
;; MSG SIZE  rcvd: 59

feathers-mcgraw@62-West-Wallaby-Street:~$ dig -x 195.166.151.235

; <<>> DiG 9.9.2-P1 <<>> -x 195.166.151.235
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16620
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;235.151.166.195.in-addr.arpa.  IN      PTR

;; ANSWER SECTION:
235.151.166.195.in-addr.arpa. 43200 IN  PTR     samhobbs.plus.com.

;; Query time: 58 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Oct  5 11:39:06 2013
;; MSG SIZE  rcvd: 88

If my PTR record was set up properly, the answer section for dig -x should show samhobbs.co.uk, right? The article indicates that my ISP controls the PTR record, I'm not sure if I'm able to change it.

I guess that's one more reason to use a relay?

Feathers

[SteveRiley]

What exactly is an open relay? Is that just a forwarding point from one mail server to the next, or somewhere that allows anyone to send mail (from foo@yourdomain.com)?

Say you have a server hosting mail for foo.com. If someone can connect to your mail server and send mail from alice@bar.net to bob@qux.org, then your server is an open relay: neither the sender nor the receiver have addresses in foo.com. This was one of the original techniques spammers used years ago. Nowadays, it'll land you on a block list within hours.

To not be an open relay, the server must block such attempts. You do this by configuring it to require that one of the addresses be in the foo.com domain. There's plenty of material on the web that documents correct Postfix settings for this. The iRedMail script sets it properly, and so does Ubuntu's mail-stack-delivery package.

You can test your setup by telneting to your mail server on whatever port it listens for incoming connections and engaging it in a brief SMTP conversation. Below, the bold items are my typing. You'll see that neither the sender nor the receiver are in my domain, and that the server therefore rejects my attempt:

steve@t520:~$ [B]telnet rileyz.net 2525[/B]
Trying 24.19.53.43...
Connected to rileyz.net.
Escape character is '^]'.
220 m92p.rileyz.local ESMTP Postfix (Debian/GNU)
[B]ehlo example.com[/B]
250-m92p.rileyz.local
250-PIPELINING
250-SIZE 15728640
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
[B]mail from:alice@bar.net[/B]
250 2.1.0 Ok
[B]rcpt to:bob@qux.org[/B]
554 5.7.1 <bob@qux.org>: Relay access denied

Press Ctrl+RightBracket to get the telnet> prompt, and then enter quit.

If my PTR record was set up properly, the answer section for dig -x should show samhobbs.co.uk, right? The article indicates that my ISP controls the PTR record, I'm not sure if I'm able to change it.

Right -- you don't own your IP address, your ISP does. They control allocation. So while it's possible to have any number of A records that all resolve to the same IP address, only one PTR record can exist for that address. The PTR record is maintained in the DNS server of the entity that owns that address range.

I guess that's one more reason to use a relay?

Different receiving mail servers handle the existence of PTRs in different ways. Almost every server these days requires some kind of response; some actually compare what's in the EHLO statement to the rDNS result and require that they match. Wikipedia's brief discussion of PTR/reverse DNS checks is a good place to start learning more.

The beauty of using a relay service (like Dyn) is that they take care of this for you.

[Feathers McGraw]

Thanks for the explanation.

Just checked, and it's all good - I also get a relaying denied response.

Shame I can't change the PTR, I may have to look into Dyn or a similar service if I have any problems sending mail.

Feathers