SSH

Gerard Lally · 01-21-2015, 07:42 PM

I'm fairly sure this isn't a Slackware issue at all, but I am more than a little perplexed as to where exactly the blame lies. Late last week I suddenly found myself no longer able to log in to a Slackware server that has been up and running for 3 years at Business A (it's now at Slackware 14.1). And just today I found myself unable to log in to yet another Slackware server that has been up and running for 5 years at Business B (now at 13.37). Have I been hacked? I use a public/private key pair for login at both locations, with root and password login disabled in /etc/sshd_config and sshd running on a non-standard port.

For access while on the road I keep the private keys on a USB flash drive inside a 16-digit password-protected Jetico BestCrypt archive. I inadvertently left this USB device attached overnight to a PC at Business A last week but the archive was not open.

I have been unable to get to either location in person to see what's going on. However, I still had the first terminal open today to Business B which remained open when the login failure occurred on the second terminal I was opening, so I was able to check a few things. Permissions at ~/.ssh on remote host are 700 and at ~/.ssh/authorized_keys 600. Permissions at the local end for the private key are 700. File ownership for the entire /home/serveradmin directory is serveradmin:serveradmin. I have tried logging in from Windows and Slackware, with the same problem on both.

Below is a sample session from Windows (scrubbed):

Code:

C:\Users\Gerard>ssh -v -p 22xxx -i keys\server-openssh serveradmin@xxx.xxx.xxx.xxx
OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22xxx.
debug1: Connection established.
debug1: identity file server-openssh type 1
debug1: identity file server-openssh-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA bf:fc:4a:3a:1b:9e:4f:c1:66:59:59:83:41:75:da:18
debug1: Host '[xxx.xxx.xxx.xxx]:22xxx' is known and matches the ECDSA host key.
debug1: Found key in /.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: server-openssh
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

The only thing I have been doing on both servers recently is setting them up as backup servers on the LAN and over VPN, using rsnapshot. This hasn't involved any SSH changes at all, as I have been using rsnapshot to pull Windows backups, with rsyncd at the client end running as a daemon, so no SSH needed. Any ideas? I really don't think I have been hacked as I am religious about access to these servers and they are vanilla Slackware installs, with perhaps one or two Slackbuilds on top.

pcninja · 01-21-2015, 08:02 PM

Unlike many of the other people I've seen here, I am not a linux expert. My only guess is that, you have two different versions of the sshd package and that might be causing conflicts.

Gerard Lally · 01-21-2015, 08:20 PM

Quote:

Originally Posted by pcninja

Unlike many of the other people I've seen here, I am not a linux expert. My only guess is that, you have two different versions of the sshd package and that might be causing conflicts.

Each server runs the sshd daemon that came with the official Slackware release.

I have been logging in without issue for years from multiple SSH clients as well - ssh on Slackware 13 and 14, NetBSD 6 and 7, Crux 3, Windows 2003, Windows 7 and Windows 8.1. Having multiple versions of the server daemon and clients has not caused me a single problem for at least 5 years. I suspect it hasn't suddenly become the cause of my current predicament, but thanks for your reply anyway.

evo2 · 01-21-2015, 08:22 PM

Hi,

have you checked what sshd is logging on the machine you still have a terminal on? It should provide much more useful information than the ssh client output.

Evo2.

Gerard Lally · 01-21-2015, 08:32 PM

Quote:

Originally Posted by evo2

Hi,

have you checked what sshd is logging on the machine you still have a terminal on? It should provide much more useful information than the ssh client output.

Evo2.

Hi,

unfortunately the terminal that was still open died when my unreliable 3G broadband temporarily lost its connection. But this is a good idea; I really need to get there in person tomorrow to check this log.