1

I'm using authorized_keys to restrict the usable commands for an user. The owner of the ~/.ssh and the file is the root and set to

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

This was working quite well, till I discovered, that at some point, the user now can use again all commands. The file authorized_keys does contain:

command="mysql -u arg1 -p arg2",no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa public_key

I don't know what I'm doing wrong, also I tried it in debug mode and checked the logs. But he simply allows all commands.

The user-login should be password-only, so no key system.

Debug-Log:

Connection from XX.XX.XX.XXX port 26048
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63
debug1: no match: PuTTY_Release_0.63
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug1: permanently_set_uid: 103/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth]
debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user restricteduser service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "restricteduser"
debug1: PAM: setting PAM_RHOST to "XXX.XXXX.XXXXXXXX.XX"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user restricteduser service ssh-connection method password [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: PAM: password authentication accepted for restricteduser
debug1: do_pam_account: called
Accepted password for restricteduser from XX.XX.XX.XXX port 26048 ssh2
debug1: monitor_read_log: child log fd closed
debug1: monitor_child_preauth: restricteduser has been authenticated by privileged process
debug1: PAM: establishing credentials
User child is on pid 24137
debug1: SELinux support disabled
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 2001/2001
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: SELinux support disabled
debug1: session_pty_req: session 0 alloc /dev/pts/11
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.
debug1: server_input_channel_req: channel 0 request [email protected] reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req [email protected]

Regards ProcTrap

Improve this question

1 Answer 1

Reset to default
4

It's not being ignored specifically; the client simply does not attempt public-key authentication. Note how your log says that the first and only authentication attempt was using the password mechanism:

debug1: userauth-request for user restricteduser service ssh-connection method password [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: PAM: password authentication accepted for restricteduser
debug1: do_pam_account: called
Accepted password for restricteduser from XX.XX.XX.XXX port 26048 ssh2

And when public keys aren't used, the server doesn't have anything to match the authorized_keys contents against...so it doesn't touch that file at all.

If you want to enforce authorized_keys usage, turn off password authentication for that user, in /etc/ssh/sshd_config using a Match User ... group.

Alternatively, set a forced command for that user, again in /etc/ssh/sshd_config using Match. (There is even an example for CVS.)

Improve this answer
7
  • Is there not a chance to let him access without any pub. keys but only through the pw connection ? I don't want any key-system, only a simple password login.
    – proc
    Sep 12, 2014 at 20:09
  • @ProcTrap: See the last paragraph of what I wrote.
    – u1686_grawity
    Sep 12, 2014 at 20:10
  • I'm not really getting what you mean, because I'm already running a "forced command" as in my authorized_keys file. I removed the "public_key" but this doesn't seem to work. Or are you talking about changing something in the etc/ssh/sshd_config ? Because I can't see an example in there for Match.
    – proc
    Sep 12, 2014 at 20:16
  • 1
    @ProcTrap: See the other paragraphs of what I wrote. Your authorized_keys file is completely irrelevant for authentication that doesn't use keys. Yes, you have to edit /etc/ssh/sshd_config.
    – u1686_grawity
    Sep 12, 2014 at 20:21
  • Ty, now I need to figure out, what I've to do, to restrict this single user. Some help is welcome, especially because it's a high risk to put something wrong in there :)
    – proc
    Sep 12, 2014 at 20:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .