LinuxQuestions.org - [SOLVED] ssh does not work for another user

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - ssh does not work for another user (https://www.linuxquestions.org/questions/linux-newbie-8/ssh-does-not-work-for-another-user-914261/)

ssh does not work for another user

I have user1, user2, user3, and host1.
I've created private/public key for all 3 users.

All 3 users have same authorized_keys file, which contains all 3 public keys.
All 3 users have same 700 permission for their home directory and .ssh directory.
All 3 users (plus other accounts on other host) can ssh to user1 and user2, but not user3

host1:user1>ssh user1@host1 -- OK
host1:user1>ssh user2@host1 -- OK
host1:user1>ssh user3@host1 -- FAILED
host1:user2>ssh user1@host1 -- OK
host1:user2>ssh user2@host1 -- OK
host1:user2>ssh user3@host1 -- FAILED
host1:user3>ssh user1@host1 -- OK
host1:user3>ssh user2@host1 -- OK
host1:user3>ssh user3@host1 -- FAILED

I'm not able to figure out what's wrong with user3. Any idea?

Here is the log

Code:

host1> ssh -vv user3@host1

Sun_SSH_1.1.3, SSH protocols 1.5/2.0, OpenSSL 0x0090704f

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Applying options for *

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: ssh_connect: needpriv 0

debug1: Connecting to host1 [10.93.64.197] port 22.

debug1: Connection established.

debug2: key_type_from_name: unknown key type '-----BEGIN'

debug2: key_type_from_name: unknown key type '-----END'

debug1: identity file /users/home/user1/.ssh/id_rsa type 1

debug1: identity file /users/home/user1/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3

debug1: match: Sun_SSH_1.1.3 pat Sun_SSH_1.1.*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-Sun_SSH_1.1.3

debug1: use_engine is 'yes'

debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers

debug1: pkcs11 engine initialization complete

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: i-default

debug2: kex_parse_kexinit: i-default

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible

Unknown code 0

)

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: i-default

debug2: kex_parse_kexinit: i-default

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc

debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: en-CA,es-MX,en,en-US,es,fr,fr-CA,i-default

debug2: kex_parse_kexinit: en-CA,es-MX,en,en-US,es,fr,fr-CA,i-default

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-ctr hmac-md5 none

debug2: mac_init: found hmac-md5

debug1: kex: client->server aes128-ctr hmac-md5 none

debug1: Peer sent proposed langtags, ctos: en-CA,es-MX,en,en-US,es,fr,fr-CA,i-default

debug1: Peer sent proposed langtags, stoc: en-CA,es-MX,en,en-US,es,fr,fr-CA,i-default

debug1: We proposed langtags, ctos: i-default

debug1: We proposed langtags, stoc: i-default

debug1: Negotiated lang: i-default

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: Remote: Negotiated main locale: C

debug1: Remote: Negotiated messages locale: C

debug1: dh_gen_key: priv key bits set: 116/256

debug1: bits set: 1617/3191

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'host1' is known and matches the RSA host key.

debug1: Found key in /users/home/user1/.ssh/known_hosts:6

debug1: bits set: 1552/3191

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug1: newkeys: mode 1

debug1: set_newkeys: setting new keys for 'out' mode

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: newkeys: mode 0

debug1: set_newkeys: setting new keys for 'in' mode

debug1: SSH2_MSG_NEWKEYS received

debug1: done: ssh_kex2.

debug1: send SSH2_MSG_SERVICE_REQUEST

debug2: service_accept: ssh-userauth

debug1: got SSH2_MSG_SERVICE_ACCEPT

debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive

debug1: Next authentication method: gssapi-keyex

debug2: we did not send a packet, disable method

debug1: Next authentication method: gssapi-with-mic

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible

Unknown code 0

)

debug2: we did not send a packet, disable method

debug1: Next authentication method: publickey

debug1: Trying public key: /users/home/user1/.ssh/id_rsa

debug2: we sent a publickey packet, wait for reply

debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 6ecd0 hint 0

debug2: input_userauth_pk_ok: fp 97:ca:15:49:9d:7b:41:40:4d:b1:4f:ef:27:2a:e8:b5

debug1: read PEM private key done: type RSA

debug1: Authentications that can continue: 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

Password:

debug1: Authentications that can continue: 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

Password:

debug1: Authentications that can continue: 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

Password:

debug1: Authentications that can continue: keyboard-interactive

debug2: we did not send a packet, disable method

debug1: No more authentication methods to try.

Permission denied (keyboard-interactive).

debug1: Calling cleanup 0x34894(0x0)

host1>

Check if user3 is allowed in /etc/sshd_config

jlinkels

Here is my /etc/ssh/sshd_config. I don't see anything specific to individual user. Any idea?

Code:

#

# Copyright 2004 Sun Microsystems, Inc.  All rights reserved.

# Use is subject to license terms.

#

# ident "@(#)sshd_config        1.8    04/05/10 SMI"

#

# Configuration file for sshd(1m)



# Protocol versions supported

#

# The sshd shipped in this release of Solaris has support for major versions

# 1 and 2.  It is recommended due to security weaknesses in the v1 protocol

# that sites run only v2 if possible. Support for v1 is provided to help sites

# with existing ssh v1 clients/servers to transition.

# Support for v1 may not be available in a future release of Solaris.

#

# To enable support for v1 an RSA1 key must be created with ssh-keygen(1).

# RSA and DSA keys for protocol v2 are created by /etc/init.d/sshd if they

# do not already exist, RSA1 keys for protocol v1 are not automatically created.



# Uncomment ONLY ONE of the following Protocol statements.



# Only v2 (recommended)

Protocol 2



# Both v1 and v2 (not recommended)

#Protocol 2,1



# Only v1 (not recommended)

#Protocol 1



# Listen port (the IANA registered port number for ssh is 22)

Port 22



# The default listen address is all interfaces, this may need to be changed

# if you wish to restrict the interfaces sshd listens on for a multi homed host.

# Multiple ListenAddress entries are allowed.



# IPv4 only

#ListenAddress 0.0.0.0

# IPv4 & IPv6

ListenAddress ::



# Port forwarding

AllowTcpForwarding no



# If port forwarding is enabled, specify if the server can bind to INADDR_ANY.

# This allows the local port forwarding to work when connections are received

# from any remote host.

GatewayPorts no



# X11 tunneling options

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes



# The maximum number of concurrent unauthenticated connections to sshd.

# start:rate:full see sshd(1) for more information.

# The default is 10 unauthenticated clients.

#MaxStartups 10:30:60



"sshd_config" [Read only] 160 lines, 5202 characters

#MaxStartups 10:30:60



# Banner to be printed before authentication starts.

#Banner /etc/issue



# Should sshd print the /etc/motd file and check for mail.

# On Solaris it is assumed that the login shell will do these (eg /etc/profile).

PrintMotd no



# KeepAlive specifies whether keep alive messages are sent to the client.

# See sshd(1) for detailed description of what this means.

# Note that the client may also be sending keep alive messages to the server.

KeepAlive yes



# Syslog facility and level

SyslogFacility auth

LogLevel info



#

# Authentication configuration

#



# Host private key files

# Must be on a local disk and readable only by the root user (root:sys 600).

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key



# Default Encryption algorithms and Message Authentication codes

#Ciphers        aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

#MACS  hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96



# Length of the server key

# Default 768, Minimum 512

ServerKeyBits 768



# sshd regenerates the key every KeyRegenerationInterval seconds.

# The key is never stored anywhere except the memory of sshd.

# The default is 1 hour (3600 seconds).

KeyRegenerationInterval 3600



# Ensure secure permissions on users .ssh directory.

StrictModes yes



# Length of time in seconds before a client that hasn't completed

# authentication is disconnected.

# Default is 600 seconds. 0 means no time limit.

LoginGraceTime 600



# Maximum number of retries for authentication

# Default is 6. Default (if unset) for MaxAuthTriesLog is MaxAuthTries / 2

MaxAuthTries    6

MaxAuthTriesLog 3



# Are logins to accounts with empty passwords allowed.

# If PermitEmptyPasswords is no, pass PAM_DISALLOW_NULL_AUTHTOK

# to pam_authenticate(3PAM).

PermitEmptyPasswords no



# To disable tunneled clear text passwords, change PasswordAuthentication to no.

PasswordAuthentication yes

PasswordAuthentication yes



# Use PAM via keyboard interactive method for authentication.

# Depending on the setup of pam.conf(4) this may allow tunneled clear text

# passwords even when PasswordAuthentication is set to no. This is dependent

# on what the individual modules request and is out of the control of sshd

# or the protocol.

PAMAuthenticationViaKBDInt yes



# Are root logins permitted using sshd.

# Note that sshd uses pam_authenticate(3PAM) so the root (or any other) user

# maybe denied access by a PAM module regardless of this setting.

# Valid options are yes, without-password, no.

PermitRootLogin no



# sftp subsystem

Subsystem      sftp    /usr/lib/ssh/sftp-server





# SSH protocol v1 specific options

#

# The following options only apply to the v1 protocol and provide

# some form of backwards compatibility with the very weak security

# of /usr/bin/rsh.  Their use is not recommended and the functionality

# will be removed when support for v1 protocol is removed.



# Should sshd use .rhosts and .shosts for password less authentication.

IgnoreRhosts yes

RhostsAuthentication no



# Rhosts RSA Authentication

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts.

# If the user on the client side is not root then this won't work on

# Solaris since /usr/bin/ssh is not installed setuid.

RhostsRSAAuthentication no



# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication.

#IgnoreUserKnownHosts yes



# Is pure RSA authentication allowed.

# Default is yes

RSAAuthentication yes

Did you try comparing the logfiles against a successful login? I got suspicious at

Code:

debug2: key_type_from_name: unknown key type '-----BEGIN'

debug2: key_type_from_name: unknown key type '-----END'

and those lines don't appear when I do it. See if diff ~user1/.ssh/id_rsa ~user3/.ssh/id_rsa turns up any diffs besides the actual key material? Guessing here.

I do get those lines in both successful login and failed login.

Did you apply a password to the keys when you created them for user3 ?
if so try removing the password from the keys..

http://www.madboa.com/geek/openssl/#key-removepass

or you could try regenerating the keyset for that user..
during key generation when it asks for a password just hit <enter>

Quote:

regenerate keys

For each user that needs new SSH keys generated, you first need to delete the old keys, which can be accomplished by deleting the key files:

# rm /home/username/.ssh/id_rsa
# rm /home/username/.ssh/id_rsa.pub

Generating the new keys is easy. Make sure you’re logged in as the user whose key you want to replace to use this command:

$ ssh-keygen

I'm making the case simpler. I've made the following files the same for all 3 users:

authorized_keys2
id_rsa
id_rsa.pub

and the result is the same.

SOLVED:

user1, user2, and user3 are all sudo accounts. The password for user3 happen to be expired. I did not notice the password expired because I never login to these accounts directly.

After reset user3's passsword, it works.