SSH woes

bluethundr

bluethundr

Hello!

I am attempting to SSH into this new FreeBSD box I just setup.

What I did was scp my root user RSA key (behind a good firewall) from my CentOS box to the new machine.

From my CentOS box:
Code: 
[root@lcent5-1:~]$:scp ~/.ssh/id_rsa.pub root@$BSD2:~

Then on the new BSD machine catted it into my authorized_keys file:

Code: 
[root@lcent5-1:~]$:ssh $BSD2
Password:
Last login: Tue Aug 17 00:46:28 2010 from 192.168.1.42
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
	The Regents of the University of California.  All rights reserved.

#########################################################
#               SUMMITNJHOME.COM                        #
#               TITLE:       FreeBSD 2 BOX              #
#               LOCATION:    SUMMIT BASEMENT            #
#                                                       #
#########################################################


lbsd8-2# cat id_rsa.pub >> ~/.ssh/authorized_keys

PermitRootLogin is enabled and so is the RSAAuthentication, PubkeyAuthentication, and AuthorizedKeysFile file.

Code: 
#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

Permissions on the authorized_keys file look ok to me!

Code: 
lbsd8-2# ls -l ~/.ssh/authorized_keys 
-rw-------  1 root  wheel  824 Aug 17 00:47 /root/.ssh/authorized_keys

I made sure to su to root with a dash:

Code: 
[root@lcent5-1:~]$:su - root


But for some odd reason I see a PAM authentication error for my user account (not root) in /var/log/messages on the BSD box:

Code: 
Aug 17 00:54:43 lbsd8-2 sshd[2360]: error: PAM: authentication error for illegal user bluethundr from 192.168.1.42

And here is the verbose output for an SSH command:

Code: 
[root@lcent5-1:~]$:ssh -vvv $BSD2
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.44 [192.168.1.44] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2p1 FreeBSD-20090522
debug1: match: OpenSSH_5.2p1 FreeBSD-20090522 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-
cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-
group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-
cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-
cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 532/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 17
debug1: Host '192.168.1.44' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:17
debug2: bits set: 509/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x9790e58)
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1

And incidentally I can't ssh at ALL from my user account:

Code: 
[root@lcent5-1:~]$:su - bluethundr
[bluethundr@lcent5-1:~]$:ssh $BSD2
Password:
Password:

In /var/log/messages on the BSD machineI see yet more PAM authentication errors. But AFAIK I don't even have PAM enabled!

Code: 
Aug 17 00:54:43 lbsd8-2 sshd[2360]: error: PAM: authentication error for illegal user bluethundr from 192.168.1.42

Code: 
lbsd8-2# grep -i PAM /etc/ssh/sshd_config
# Change to no to disable PAM authentication
# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will 
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
#UsePAM yes

It's commented out! And of course as I've been experimenting to get this to work I have been restarting SSH.

Any help to get my SSH hummin' would be greatly appreciated!
 
Use:
% ssh root@$BSD2

Also, I would agree that remote root login is undesirable. If you insist on having a remote root login, change your sshd_config to have:
Code: 
PermitRootLogin without-password

This will only allow remote root login with the keys listed in your authorized_keys and disallow root password logins.
 
SirDice said:
Do NOT allow root to log in directly. Use a 'normal' user account to login and use su or security/sudo.
Click to expand...

I agree with this, there is really no reason to login with a root account. Most things can be done with privilege escalation.
 
bluethundr said:
Code: 
lbsd8-2# grep -i PAM /etc/ssh/sshd_config
# Change to no to disable PAM authentication
# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will 
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
#UsePAM yes

It's commented out! And of course as I've been experimenting to get this to work I have been restarting SSH.
Click to expand...

Even though it's commented out, by default it seems to be enabled # Change to no to disable PAM authentication

Also this maybe of no relevance to this problem but from your verbose output this has got me worried

Code: 
debug1: identity file /root/.ssh/identity type -1
debug3: Not a RSA1 key file /root/.ssh/id_rsa.

I think there is a problem (may not be the issue, but it needs to be investigated)

Code: 
AuthorizedKeysFile      .ssh/authorized_keys

The following is described in a Gentoo bug report > http://bugs.gentoo.org/308939

This seems to be the resolution, give this a try:

Try this instead: AuthorizedKeysFile %h/.ssh/authorized_keys

And yeah, I can't see it documented anywhere. Also, this bug's severity is not
minor but rather critical. If you rely on keys only, you are locked out of your
boxes without console access. :-(((
Click to expand...

Please report back on this.
 
You must log in or register to reply here.
Back
Top