Tag Archives: ssh

SSH Public Key Authenication

Last week I had an occasion to test public key authentication from OpenVMS to Linux. With the dayjob we have an implementation where data will be sent in batch via sftp to a Linux box. To get a better idea of “the entire process” thought I should take my Debian box and test authenticating to it. Once I got through all the quirks it wasn’t that difficult.

The biggest challenge has been getting past access violations when executing ssh commands on some OpenVMS servers. What I found on HP’s ITRC forum referenced UIC in RIGHTSLIST needing to match what’s in SYSUAF, for a user executing SSH commands. Even though OpenVMS TCPIP version 5.6 ECO 1 release notes comment about this as being fixed we have experienced it with ECO 2. None the less updating the RIGHTSLIST resolves the problem.

As for set up it wasn’t to bad. Here’s the steps (summary) I used.

OpenVMS

  1. Enable the SSH Client in TCPIP$CONFIG.
  2. Create a sub folder for the user of [.SSH2], making sure your logged in as the account in question.
  3. Set default to that directory and create a key using ssh_keygen. (In order to use ssh_keygen you must first execute sys$manager:tcpip$define_commands.com.)
  4. Create an IDENTIFICATION. file with a line of.
    KeyID <private key name>
  5. Push the public key (.PUB) to the Linux box.

Linux

  1. Log in as the user you’ll be connecting with, create a .ssh subfolder if it does not already exist.
  2. Take the public key (.PUB) from the OpenVMS box and put it in the authorized_keys file.
    $ ssh-keygen -i -f openvms.pub >> authorized_keys
    
    note:  keep in mind where default is in relation to .ssh/authorized_keys the above would assume
    your in ~/.ssh when executing ssh-keygen.
    

This was with the default config for sshd on Debian GNU/Linux 5.0 (lenny). Something to also keep in mind is from a security perspective ensuring access to the key files is limited to the user would be a good practice on both systems.

SSH bots

Checking logs the other day I noticed another instance where ssh bots trying to get access to my home server. Monitoring auth.log for less that a minute revealed 11 failed attempts.

$ tail -f /var/log/auth.log | grep Failed
Oct  8 20:53:37 boss sshd[27267]: Failed password for invalid user peru from 68.216.125.39 port 43047 ssh2
Oct  8 20:53:40 boss sshd[27269]: Failed password for invalid user china from 68.216.125.39 port 43974 ssh2
Oct  8 20:53:44 boss sshd[27271]: Failed password for invalid user uk from 68.216.125.39 port 44570 ssh2
Oct  8 20:53:48 boss sshd[27273]: Failed password for invalid user ok from 68.216.125.39 port 45358 ssh2
Oct  8 20:53:52 boss sshd[27276]: Failed password for invalid user navy from 68.216.125.39 port 46298 ssh2
Oct  8 20:53:55 boss sshd[27278]: Failed password for invalid user spring from 68.216.125.39 port 47694 ssh2
Oct  8 20:53:59 boss sshd[27280]: Failed password for invalid user summer from 68.216.125.39 port 49883 ssh2
Oct  8 20:54:03 boss sshd[27282]: Failed password for invalid user autumn from 68.216.125.39 port 50796 ssh2
Oct  8 20:54:07 boss sshd[27284]: Failed password for invalid user winter from 68.216.125.39 port 51960 ssh2
Oct  8 20:54:10 boss sshd[27286]: Failed password for invalid user snow from 68.216.125.39 port 52885 ssh2
Oct  8 20:54:14 boss sshd[27288]: Failed password for invalid user skyrix from 68.216.125.39 port 53493 ssh2

It’s probably not a bad idea to add some security. For now we’ll enable the MaxStartups function in sshd_config. I’d prefer to run Fail2Ban but have some dependancy problems with python. I’ll have to look into that or other options.

SSH – helping you stay secure when away from home

This past weekend Kay and I took a trip to Osage Beach, MO for a long weekend with family. We left Friday evening and stopped in St. Louis to stay at a friends place, finishing up on Saturday morning. We were staying through Tuesday afternoon and even though Kay took both days off I only had Tuesday. So again that left me with working remote, but that’s what I do every day so no big deal as long as I had a internet connection.

For work being remote doesn’t have many security concerns as I VPN into the network. But when dealing with personal business away from the comforts of the home network is a different story. That is where SSH can come in very handy.

Anytime your using a public internet connection your at risk to someone sniffing traffic to get information. A good rule of thumb is if your at an internet cafe, Starbucks, local hot spot, etc never enter login credentials without the url starting with https. Most of us by now have come to look for the lock at the bottom of the browser when purchasing products but one place that’s forgotten is email. Most who access email do so via POP or IMAP, both of which have secure capabilities but some hosts don’t enable it or us users don’t bother to check. That means your username and password, that more than likely is automatically entered for you, is subject to capture as it’s not encrypted. This is where SSH can be your friend.

If you have shell access to a machine/server on the internet and ssh is runing you can forward the POP requests, including the SMTP (sending of emails), to add a layer of security to your sharing of the internet with the 10s or 100s of others using the same hotspot. The -L switch in the SSH client allows for forwarding of ports and this is what you’d use. Some details from the info page:

-L [bind_address:]port:host:hostport
 Specifies that the given port on the local (client) host is to be
 forwarded to the given host and port on the remote side.  This
 works by allocating a socket to listen to port on the local side,
 optionally bound to the specified bind_address.  Whenever a con-
 nection is made to this port, the connection is forwarded over
 the secure channel, and a connection is made to host port
 hostport from the remote machine.  Port forwardings can also be
 specified in the configuration file.  IPv6 addresses can be spec-
 ified with an alternative syntax:
 [bind_address/]port/host/hostport or by enclosing the address in
 square brackets.  Only the superuser can forward privileged
 ports.  By default, the local port is bound in accordance with
 the GatewayPorts setting.  However, an explicit bind_address may
 be used to bind the connection to a specific address.  The
 bind_address of ``localhost'' indicates that the listening port
 be bound for local use only, while an empty address or '*' indi-
 cates that the port should be available from all interfaces.

You’ll want to make sure your root, or have admin privs, on the machine your running the ssh client and execute the following from a command line:

ssh -L 110:<your mail server name>:110 <ip of your remote server> -l <account on the remote box>

This logs you into your remote server and forwards port 110 traffic, to your mail server, from the machine your on to your remote server encrypting the connection. If you wanted to do this for sending emails substitue the 110 for 25 and if you wanted to do them both at the same time use:

ssh -L 110:<your mail server name>:110 -L 25:<your smtp server>:25 <ip of your remote server> -l <account on the remote box>

This comes in very handy for me since, I’ve noted in the past, emails sent from my domain sometimes are seen as spam. So I can ensure when I’m on the road, connected to the internet via XYZ ISP, that I don’t have to change any email setup just execute the command before opening my email client.

Cheers !!!