現象

踏み台サーバであるAから別サーバのBにSSHで接続しようとしたときに

PrivateIP、PrivateDNSを指定すると接続可能
PublicDNSを指定すると接続可能
PublicIPを指定すると接続不可能

という状況でした。NetworkACLは特に設定しておらず
AB間のSecurityGroupは許可し合っているはずなのに…。

原因

PrivateIPで接続可能である理由

接続先（サーバB）のSecurityGroupのInboundには
サーバAからのSSH接続を許可する内容を設定してありましたが
送信元としてサーバAが属する SecurityGroup を記載していたのが原因でした。

公式ドキュメントには以下のように記載されています。

ルールの送信元または送信先としてセキュリティグループを指定する場合、
ルールはセキュリティグループと関連付けられるすべてのインスタンスに影響します。
着信トラフィックは、ソースセキュリティグループに関連付けられたインスタンスの
プライベート IP アドレスに基づいて許可されます
（パブリック IP アドレスまたは Elastic IP アドレスは考慮されません）。

結果として、サーバBのInboundで許可されていたのはサーバAのPrivateIPのみ。
PrivateIP/DNSを使えば問題なく接続できたのはこのためですね。

SSH接続先としてPublicIPを指定した際には
PublicIP間の通信となり、セキュリティグループに阻まれたと考えています。
サーバBのInboundセキュリティグループにサーバAのPublicIPを直接書くと
PublicIP指定でも接続できるようになりました。

PublicDNSで接続可能である理由

Discussion Forumsの記載内容によると

When you use the public DNS name from within the same EC2 region, you will actually get the current private IP address.

-> 同じリージョンにあるEC2のPublicDNSを解決すると、PrivateIPが得られる。
実際にEC2インスタンスを立てて試してみました。

同じリージョンで解決を行った場合はPrivateIPが得られる

# @Singapore
$ nslookup ec2-52-78-50-129.ap-southeast-1.compute.amazonaws.com 
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
Name:   ec2-52-78-50-129.ap-southeast-1.compute.amazonaws.com
Address: 10.0.8.105 # <- PrivateIP

違うリージョンで解決を行った場合はPublicIPが得られる

# @Sydney
$ nslookup ec2-52-78-50-129.ap-southeast-1.compute.amazonaws.com
Server:		10.0.0.2
Address:	10.0.0.2#53

Non-authoritative answer:
Name:	ec2-52-78-50-129.ap-southeast-1.compute.amazonaws.com
Address: 52.77.49.128 # <- PublicIP

つまり、PublicDNSがPrivateIPに変換され
同一ネットワーク内のPrivateIP同士の通信が行われるため
セキュリティグループでの指定通りに接続できたと考えています。

まとめ

PublicIPでSSH接続ができない問題について解説しました。

問題が概ね解決したあとに、以下のような記事を見つけました。
AWSのセキュリティグループにセキュリティグループを指定した時の落とし穴

こちらがかなり参考になり、解決に至ったのですが
そもそも今回の問題を端的に表すキーワードがなく
ググラビリティが非常に低いため、面を増やすためにこの記事を書いた次第です。