Mailing List Archive: OpenSSH: Dev

Can not login with key-exchange is chrooted sftp environment

Index | Next | Previous | View Threaded

rudupa at easylink

Jul 6, 2012, 10:02 AM

Post #1 of 3 (607 views)
Permalink

Can not login with key-exchange is chrooted sftp environment

Hi,

We need to allow log in based on public key generated using ssh-keygen (rsa key) for SFTP with chroot (internal sftp). I am not able to log in with just key exchange. I can login using password.

I am able to log-in with out password for an ssh session unlike sftp session.

Is there a way to login with key-exchange only for internal-sftp with chroot?

Here is the trace

OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /usr/apps1/.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
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /usr/apps1/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /usr/apps1/.ssh/id_dsa.
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
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /usr/apps1/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
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,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc [at] lysator,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc [at] lysator,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 [at] openssh,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 [at] openssh,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,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 [at] lysator
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 [at] lysator
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 [at] openssh,hmac-ripemd160,hmac-ripemd160 [at] openssh,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 [at] openssh,hmac-ripemd160,hmac-ripemd160 [at] openssh,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib [at] openssh
debug2: kex_parse_kexinit: none,zlib [at] openssh
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: 127/256
debug2: bits set: 999/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /usr/apps1/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /usr/apps1/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'hsot' is known and matches the RSA host key.
debug1: Found key in /usr/apps1/.ssh/known_hosts:1
debug2: bits set: 1026/2048
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: /usr/apps1/.ssh/id_rsa (0x9bd8ae8)
debug2: key: /usr/apps1/.ssh/id_dsa (0x9bd8640)
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
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: Offering public key: /usr/apps1/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: /usr/apps1/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
Couldn't read packet: Connection reset by peer

Thanks,
Raghu
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

keisial at gmail

Jul 6, 2012, 1:30 PM

Post #2 of 3 (567 views)
Permalink

Re: Can not login with key-exchange is chrooted sftp environment [In reply to]

On 06/07/12 19:02, Raghu Udupa wrote:
> Hi,
>
> We need to allow log in based on public key generated using ssh-keygen (rsa key) for SFTP with chroot (internal sftp). I am not able to log in with just key exchange. I can login using password.
>
> I am able to log-in with out password for an ssh session unlike sftp session.
>
> Is there a way to login with key-exchange only for internal-sftp with chroot?
Are you using programs from different suites for shell session vs sftp?
Both types of session are selected after the authentication, so I find
strange that one would work while the other doesn't.

> Here is the trace
>
> OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to host port 22.
> debug1: Connection established.
> debug3: Not a RSA1 key file /usr/apps1/.ssh/id_rsa.
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug3: key_read: missing keytype
> debug3: key_read: missing whitespace
(snip)
> debug3: key_read: missing whitespace
> debug2: key_type_from_name: unknown key type '-----END'
> debug3: key_read: missing keytype
> debug1: identity file /usr/apps1/.ssh/id_rsa type 1
> debug3: Not a RSA1 key file /usr/apps1/.ssh/id_dsa.
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug3: key_read: missing keytype
> debug3: key_read: missing whitespace
(snip)

> debug3: key_read: missing whitespace
> debug2: key_type_from_name: unknown key type '-----END'
> debug3: key_read: missing keytype
> debug1: identity file /usr/apps1/.ssh/id_dsa type 2

What's the first line of those files?
I would expect them to be something like -----BEGIN RSA PRIVATE KEY-----
or -----BEGIN DSA PRIVATE KEY-----, but it seems it's not.

Thus my suspicion that they are in a format of a different suite.
If sftp can't load the key, it would obviously not be able to login.

(snip)
> debug1: Authentications that can continue: publickey
> debug3: start over, passed a different list publickey
> 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: Offering public key: /usr/apps1/.ssh/id_rsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue: publickey
However, here it is sending a key... (which is rejected by the server)
> debug1: Offering public key: /usr/apps1/.ssh/id_dsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue: publickey
and the second one is rejected, too.
> debug2: we did not send a packet, disable method
> debug1: No more authentication methods to try.
> Permission denied (publickey).
> Couldn't read packet: Connection reset by peer
>
> Thanks,
> Raghu
What's in the server logs for the rejection? The interesting stuff
about rejected keys (eg. the file is group-writable) is logged there.
Although if you can get an interactive session, it be right. Can
you login through sftp if you disable the chroot?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

rudupa at easylink

Jul 6, 2012, 2:40 PM

Post #3 of 3 (573 views)
Permalink

RE: Can not login with key-exchange is chrooted sftp environment [In reply to]

Thanks Angel. It was permissions issue. Authorized-keys as well as .ssh were owned by root.

It is working now.

Regards,
Raghu

-----Original Message-----
From: �ngel Gonz�lez [mailto:keisial [at] gmail]
Sent: Friday, July 06, 2012 4:31 PM
To: Raghu Udupa
Cc: 'openssh-unix-dev [at] mindrot'
Subject: Re: Can not login with key-exchange is chrooted sftp environment

On 06/07/12 19:02, Raghu Udupa wrote:
> Hi,
>
> We need to allow log in based on public key generated using ssh-keygen (rsa key) for SFTP with chroot (internal sftp). I am not able to log in with just key exchange. I can login using password.
>
> I am able to log-in with out password for an ssh session unlike sftp session.
>
> Is there a way to login with key-exchange only for internal-sftp with chroot?
Are you using programs from different suites for shell session vs sftp?
Both types of session are selected after the authentication, so I find
strange that one would work while the other doesn't.

> Here is the trace
>
> OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to host port 22.
> debug1: Connection established.
> debug3: Not a RSA1 key file /usr/apps1/.ssh/id_rsa.
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug3: key_read: missing keytype
> debug3: key_read: missing whitespace
(snip)
> debug3: key_read: missing whitespace
> debug2: key_type_from_name: unknown key type '-----END'
> debug3: key_read: missing keytype
> debug1: identity file /usr/apps1/.ssh/id_rsa type 1
> debug3: Not a RSA1 key file /usr/apps1/.ssh/id_dsa.
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug3: key_read: missing keytype
> debug3: key_read: missing whitespace
(snip)

> debug3: key_read: missing whitespace
> debug2: key_type_from_name: unknown key type '-----END'
> debug3: key_read: missing keytype
> debug1: identity file /usr/apps1/.ssh/id_dsa type 2

What's the first line of those files?
I would expect them to be something like -----BEGIN RSA PRIVATE KEY-----
or -----BEGIN DSA PRIVATE KEY-----, but it seems it's not.

Thus my suspicion that they are in a format of a different suite.
If sftp can't load the key, it would obviously not be able to login.

(snip)
> debug1: Authentications that can continue: publickey
> debug3: start over, passed a different list publickey
> 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: Offering public key: /usr/apps1/.ssh/id_rsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue: publickey
However, here it is sending a key... (which is rejected by the server)
> debug1: Offering public key: /usr/apps1/.ssh/id_dsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue: publickey
and the second one is rejected, too.
> debug2: we did not send a packet, disable method
> debug1: No more authentication methods to try.
> Permission denied (publickey).
> Couldn't read packet: Connection reset by peer
>
> Thanks,
> Raghu
What's in the server logs for the rejection? The interesting stuff
about rejected keys (eg. the file is group-writable) is logged there.
Although if you can get an interactive session, it be right. Can
you login through sftp if you disable the chroot?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads