SSH id: unknown ID 1000 (dropbear)

138 views
Skip to first unread message

Eric R. Wick

unread,
Dec 16, 2016, 1:01:38 PM12/16/16
to Alt-F
Hello,

got a quirk after moving the Alt-F folder around and did not found information where it is coming from. Every kind of login to a known user on the Alt-F box with a ssh service sftp, scp did give a line: id: unknown ID 1000

The user id and group do exist in /etc/passwd and /etc/group and match the clients id. It appears on 3 clients without any changes on them, so it must be Alt-F related on my box and appears on all defined users that had worked before. As result the gnome-vfs and fuse is unable to mount these services and fail. Here is a plain login verbose, can someone see a bug there?

One with key

eric@athena:~$ ssh -v er...@192.168.1.225
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.225 [192.168.1.225] port 22.
debug1: Connection established.
debug1: identity file /home/eric/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version dropbear_2015.71
debug1: no match: dropbear_2015.71
debug1: Authenticating to 192.168.1.225:22 as 'eric'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve255...@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp521
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp521 SHA256:laZ/uJyW9/CHWci--changed-------
debug1: Host '192.168.1.225' is known and matches the ECDSA host key.
debug1: Found key in /home/eric/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/eric/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.225 ([192.168.1.225]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LC_PAPER = de_DE.UTF-8
debug1: Sending env LC_ADDRESS = de_DE.UTF-8
debug1: Sending env LC_MONETARY = de_DE.UTF-8
debug1: Sending env LC_NUMERIC = de_DE.UTF-8
debug1: Sending env LC_TELEPHONE = de_DE.UTF-8
debug1: Sending env LC_IDENTIFICATION = de_DE.UTF-8
debug1: Sending env LANG = de_DE.utf8
debug1: Sending env LC_MEASUREMENT = de_DE.UTF-8
debug1: Sending env LC_TIME = de_DE.UTF-8
debug1: Sending env LC_NAME = de_DE.UTF-8
id: unknown ID 1000

One with password handshake

eric@athena:~$ ssh -v dej...@192.168.1.225
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.225 [192.168.1.225] port 22.
debug1: Connection established.
debug1: identity file /home/eric/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/eric/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version dropbear_2015.71
debug1: no match: dropbear_2015.71
debug1: Authenticating to 192.168.1.225:22 as 'dejadup'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve255...@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp521
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp521 SHA256:laZ/uJyW9/CHWci---changed------
debug1: Host '192.168.1.225' is known and matches the ECDSA host key.
debug1: Found key in /home/eric/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/eric/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: eric@persephone
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/eric/.ssh/id_dsa
debug1: Trying private key: /home/eric/.ssh/id_ecdsa
debug1: Trying private key: /home/eric/.ssh/id_ed25519
debug1: Next authentication method: password
dej...@192.168.1.225's password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.225 ([192.168.1.225]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LC_PAPER = de_DE.UTF-8
debug1: Sending env LC_ADDRESS = de_DE.UTF-8
debug1: Sending env LC_MONETARY = de_DE.UTF-8
debug1: Sending env LC_NUMERIC = de_DE.UTF-8
debug1: Sending env LC_TELEPHONE = de_DE.UTF-8
debug1: Sending env LC_IDENTIFICATION = de_DE.UTF-8
debug1: Sending env LANG = de_DE.utf8
debug1: Sending env LC_MEASUREMENT = de_DE.UTF-8
debug1: Sending env LC_TIME = de_DE.UTF-8
debug1: Sending env LC_NAME = de_DE.UTF-8
id: unknown ID 1001

Other services that did run aside dropbear are fine, dropbear is running behind inetd and not as daemon.
(key id was changed)

Eric

Eric R. Wick

unread,
Dec 17, 2016, 6:10:27 AM12/17/16
to Alt-F


Just found out what went wrong here, so i want to share to help others if the same bug appears. Mind that it appears after using the Package->Alt-F function to copy Alt-F to another partition.

So what happened is a lost of permissions on the copy, so that /etc/passwd and /etc/groups was owned by 0,0. This points to a general linux problem described here: http://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/whoami-unknown-uid-1000-a-4175447881/

As stated in the article a chmod 644 (as root) to the /etc/passwd and /etc/group has repaired the problem for me.

Open question: Is there a bug within the copy function in 0.1rc5 , that the permissions getting lost from copy operations?

Eric

João Cardoso

unread,
Dec 17, 2016, 12:41:21 PM12/17/16
to Alt-F


On Saturday, 17 December 2016 11:10:27 UTC, Eric R. Wick wrote:


Just found out what went wrong here, so i want to share to help others if the same bug appears.

Thanks!
 
Mind that it appears after using the Package->Alt-F function to copy Alt-F to another partition.

So what happened is a lost of permissions on the copy, so that /etc/passwd and /etc/groups was owned by 0,0. This points to a general linux problem described here: http://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/whoami-unknown-uid-1000-a-4175447881/

As stated in the article a chmod 644 (as root) to the /etc/passwd and /etc/group has repaired the problem for me.

Open question: Is there a bug within the copy function in 0.1rc5 , that the permissions getting lost from copy operations?

I couldn't reproduce that.
I performed the copy using the Alt-F Package Manager webUI, and the files ended up with the right permissions, so I don't thing it is a bug (the copy is performed using the 'cp -a' command)
 
Thanks anyway


Eric

Reply all
Reply to author
Forward
0 new messages