SSH-problem : shut out

jonaskellens · 09-21-2009, 01:40 PM

These are my settings in /etc/ssh/sshd_config

Code:

Port 2273
AllowUsers myadmin
LogLevel INFO
PermitRootLogin no
RSAAuthentication yes
HostbasedAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
X11Forwarding no

After a reboot of the server I'm unable to ssh into the server :

Code:

[jonas@jonas ~]$ ssh -2 -p 2273 -l myadmin -i .ssh/id_rsa_myadmin domain.tld
Permission denied (publickey,gssapi-with-mic).

I have copied the public key into ./ssh/authorized_keys2 on the server.

What did I do wrong ??

mjsurette · 09-21-2009, 02:16 PM

Quote:

Originally Posted by jonaskellens

These are my settings in /etc/ssh/sshd_config

Code:

Port 2273
AllowUsers myadmin
LogLevel INFO
PermitRootLogin no
RSAAuthentication yes
HostbasedAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
X11Forwarding no

After a reboot of the server I'm unable to ssh into the server :

Code:

[jonas@jonas ~]$ ssh -2 -p 2273 -l myadmin -i .ssh/id_rsa_myadmin domain.tld
Permission denied (publickey,gssapi-with-mic).

I have copied the public key into ./ssh/authorized_keys2 on the server.

What did I do wrong ??

Perhaps file permissions? Private keys should be 0600 and everything else should be 0644. No links allowed either.

As a side note authorized_keys2 has been depricated since v3.0, authorized_keys is recommended.

Mike

nuwen52 · 09-21-2009, 02:37 PM

If it isn't permissions, try running ssh with the -v option. That will often give you extra insights into what ssh is trying to do when it fails.

jonaskellens · 09-23-2009, 03:13 AM

Quote:

Originally Posted by nuwen52

If it isn't permissions, try running ssh with the -v option. That will often give you extra insights into what ssh is trying to do when it fails.

Code:

OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to my_server [XX.XXX.XXX.40] port 2273.
debug1: Connection established.
debug1: identity file .ssh/id_rsa_voipcenter type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: checking without port identifier
debug1: Host 'my_server' is known and matches the RSA host key.
debug1: Found key in /home/jonas/.ssh/known_hosts:17

debug1: found matching key w/out port
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa_voipcenter
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Offering public key: id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).

What does that tell us ?!

mjsurette · 09-23-2009, 03:41 AM

Quote:

Originally Posted by jonaskellens

Code:

OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to my_server [XX.XXX.XXX.40] port 2273.
debug1: Connection established.
debug1: identity file .ssh/id_rsa_voipcenter type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: checking without port identifier
debug1: Host 'my_server' is known and matches the RSA host key.
debug1: Found key in /home/jonas/.ssh/known_hosts:17

debug1: found matching key w/out port
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa_voipcenter
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Offering public key: id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).

What does that tell us ?!

I don't see it offering the public key named id_rsa_myadmin.

Make sure that id_rsa_myadmin.pub is in the authorized_keys on the server, that you're trying to log in from the right account on the client, and of course the permissions are right on both client and server.

I just noticed that you said that you couldn't log in after a reboot of the server. Does this mean that you could before? What changed?

Mike

jonaskellens · 09-23-2009, 04:38 AM

Quote:

Originally Posted by mjsurette

I don't see it offering the public key named id_rsa_myadmin.

Make sure that id_rsa_myadmin.pub is in the authorized_keys on the server, that you're trying to log in from the right account on the client, and of course the permissions are right on both client and server.

In my first post I used the name my_admin for the key. In fact the key is named "id_rsa_voipcenter", and this key-name you see in the output I posted above.

On my laptop I'm logged in as normal user 'jonas' and with the -l option I give the username of the user to log in :

Code:

ssh -v -2 -p 2273 -l admin-voipcenter -i .ssh/id_rsa_voipcenter myserver.domain.tld

Quote:

I just noticed that you said that you couldn't log in after a reboot of the server. Does this mean that you could before? What changed?

Before I could log in as root and with password-authentication. Then I edited /etc/ssh/ssd_config to allow only the user 'admin-voipcenter' and disallow root-login :

Code:

AllowUsers admin-voipcenter
PermitRootLogin no
RSAAuthentication yes
HostbasedAuthentication no

I restarted ssh-deamon (/sbin/service sshd restart) and was still able to login with RSA-key based authentication.
Or so I thought... after a reboot of the server (not just the deamon) I could no longer login through ssh...

That's the whole story.

Is there any way that I can gain access to the server without physically moving ??

mjsurette · 09-23-2009, 05:26 AM

Quote:

Originally Posted by jonaskellens

In my first post I used the name my_admin for the key. In fact the key is named "id_rsa_voipcenter", and this key-name you see in the output I posted above.

On my laptop I'm logged in as normal user 'jonas' and with the -l option I give the username of the user to log in :

Code:

ssh -v -2 -p 2273 -l admin-voipcenter -i .ssh/id_rsa_voipcenter myserver.domain.tld

Before I could log in as root and with password-authentication. Then I edited /etc/ssh/ssd_config to allow only the user 'admin-voipcenter' and disallow root-login :

Code:

AllowUsers admin-voipcenter
PermitRootLogin no
RSAAuthentication yes
HostbasedAuthentication no

I restarted ssh-deamon (/sbin/service sshd restart) and was still able to login with RSA-key based authentication.
Or so I thought... after a reboot of the server (not just the deamon) I could no longer login through ssh...

That's the whole story.

Is there any way that I can gain access to the server without physically moving ??

The server is doing the denying, so you'll have to fix it there. It could be tcpwrappers, especially if after you restarted the daemon you were on the same network and now you're not. Check /etc/hosts.allow and /etc/hosts.deny on the server. If it's a long drive and you can ssh into another machine on the network, you might be able to use it as an intermediary and save yourself that drive.

The next trick to try is to start up the server with the -d option. This is the debugging mode which leaves it in the foreground and prints out error messages. It will only accept one connection and then quit.

Let me know how it goes.

Mike

jonaskellens · 09-23-2009, 09:39 AM

Quote:

Originally Posted by mjsurette

The server is doing the denying, so you'll have to fix it there. It could be tcpwrappers, especially if after you restarted the daemon you were on the same network and now you're not. Check /etc/hosts.allow and /etc/hosts.deny on the server.

I did not put anything in hosts.allow or hosts.deny. So I guess "ALL:ALL" is written in the hosts.allow-file.
I did not change network... I was, and still am, on my home network.

Quote:

Originally Posted by mjsurette

If it's a long drive and you can ssh into another machine on the network, you might be able to use it as an intermediary and save yourself that drive.

This machine I'm trying to log on to through ssh is the gateway-server (ClarkConnect). There is no other Linux-server on the network...

If I open the Telnet-port on the firewall (through the ClarkConnect-GUI) would I be able to send commands through Telnet ?
Is there a Telnet-command to edit files (I would then edit etc/hosts.allow and explicitly put my hostname in it) ??

schneidz · 09-23-2009, 09:44 AM

Quote:

Originally Posted by jonaskellens

If I open the Telnet-port on the firewall (through the ClarkConnect-GUI) would I be able to send commands through Telnet ?
Is there a Telnet-command to edit files (I would then edit etc/hosts.allow and explicitly put my hostname in it) ??

telnet gives you terminal access just like ssh but less secure; hopefully the telnet deamon is running on that server else you would have to go there and turn it on.

hopefully we can get some debug info to help.
on the server:

Code:

sudo /sbin/service sshd stop
sudo /sbin/sshd -d -d -d

in another terminal:

Code:

sudo tail -f /var/log/messages

on the client:

Code:

ssh -v -v -v user@server.net

jonaskellens · 09-25-2009, 03:58 AM

So I'm physically at the server.

I have granted password-access in /etc/ssh/sshd_config -file...

There's something strange :

Code:

[root@box ~]# passwd admin-voipcenter
passwd: Unknown user name 'admin-voipcenter'.

No user ?

Code:

[root@box .ssh]# cat /etc/passwd | grep admin
winadmin:x:415:415:Samba Administrator:/var/samba:/sbin/nologin

[root@box ~]# ls -l /home
drwx------ 3         1004     1004 4096 sep 21 18:25 admin-voipcenter
drwxr-xr-x 2 jonaskellens allusers 4096 sep 21 11:34 jonaskellens

I have created admin-voipcenter as follow :

Code:

/usr/sbin/useradd admin-voipcenter
passwd admin-voipcenter

There is a ./ssh/authorized_keys with the public key...

Would there be a reason that key-authentication fails because of an 'unknown user' ??

chrism01 · 09-25-2009, 07:29 AM

Yep, user admin-voipcenter does not exist as you can see from /etc/passwd and also the uid instead of the name is showing as the owner on the home dir. The latter means there's no matching entry in /etc/passwd. The dirs are all owned by uid, but the system shows you the acct name if and only if it can get a matching uid from /etc/passwd.

mjsurette · 09-25-2009, 07:44 AM

Quote:

Originally Posted by jonaskellens

So I'm physically at the server.

I have granted password-access in /etc/ssh/sshd_config -file...

There's something strange :

Code:

[root@box ~]# passwd admin-voipcenter
passwd: Unknown user name 'admin-voipcenter'.

No user ?

Code:

[root@box .ssh]# cat /etc/passwd | grep admin
winadmin:x:415:415:Samba Administrator:/var/samba:/sbin/nologin

[root@box ~]# ls -l /home
drwx------ 3         1004     1004 4096 sep 21 18:25 admin-voipcenter
drwxr-xr-x 2 jonaskellens allusers 4096 sep 21 11:34 jonaskellens

I have created admin-voipcenter as follow :

Code:

/usr/sbin/useradd admin-voipcenter
passwd admin-voipcenter

There is a ./ssh/authorized_keys with the public key...

Would there be a reason that key-authentication fails because of an 'unknown user' ??

It appears that the user admin-voipcenter has been removed. Note the numeric username and group name in the 'ls -l /home' listing. The jonaskellens user is identified properly.

If you re-add the user admin-voipcenter you'll have to specify the uid and gid of 1004 so that it can read the old home directory. At the same time you should specify the home directory itself too.

If this user is for remote login only you don't need a local password and can run

Code:

passwd admin-voipcerter -d

The proper place for the public key is in the file

Code:

 /home/admin-voipcenter/.ssh/authorized_keys

Code:

./ssh/authorized_keys

is a whole different place. I hope that was a typo.

Once that's fixed, you should be fine.

Mike