ssh-ing to a port

Question

Consider the following two commands:

create-smtp-message | ssh -p 25 serveraccount

create-smtp-message | ssh serveraccount telnet localhost 25

According to my understanding of ssh(1), they should both do the same thing. Instead, the second will send the output of create-smtp-message to port 25 of the server from serveraccount (i.e., it works), whilst the first just hangs.

I'm guessing this is just me misunderstanding what ssh does when it is given the -p flag, but in case there is some configuration error: the client at which analogous commands were issued is osx-tiger with openssh ssh (OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006), the server runs a Debian Sarge (really? must upgrade that!) with openssh sshd (OpenSSH_3.8.1p1 Debian-8.sarge.6, OpenSSL 0.9.7e 25 Oct 2004). Authorisation is using DSA, as specified in the .ssh/config file.

Answer 1

Your first example is telling ssh to connect to the ssh daemon (server side process) on a non-standard port, in this case, 25. If the sshd daemon is not listening on this port, the connection attempt will time out or error with a protocol problem, as you're experiencing.

The second is telling ssh to make a normal connection to "serveraccount" (which happens over port 22) and remotely execute a telnet command to localhost:25. The output of create-smtp-message becomes stdin to your telnet command, thus allowing your SMTP server to receive your message.

Answer 2

ssh requires an sshd on the other side to contact. The -p option specifies on what port this contact will take place, if not the default port. This is there not so someone can ssh to the smtp server, or the web server. However, thats the mistake the first line attempts, and it fails because those ports are not an sshd that can process and decrypt ssh's encrypted protocol. Remember the -p option is there only so that the paranoid can move their sshd port to some non-obvious number.

ssh is not a clone of telnet, but a secure replacement for what was the main but insecure application of telnet -- creating a remote terminal connection.

One of the legacy uses of telnet, for which it is still useful, is creating a dumb terminal connection to any port in a system. You can then send and receive characters verbatim to that port. In your line 2, you've used ssh to encrypt a session with a remote host, and then on the remote host youve invoked telnet on that host to send the information from the session to the smtp server.

Ssh, on the other hand, tries to wrap everything in encryption -- not clear text -- and needs an sshd to communicate with, which is the only way the decryption will take place.

What you possibly want to find out about is port forwarding of unencrypted traffic ports using ssh encryption, but that is an advanced application and it is not clear that you need it. Your 2nd line is probably good enough for your stated purposes.