Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I thought you were trying to obfuscate the username.
You can add debug messages via the ssh -v option. Adding -vs will increase the verbosity with max at 3.
For completion have you verified ownership/permissions of bob-id on machine yyyyyy. Was bob-id located in the current working directory?
It is standard practice to create the keys on the client and transfer the public key to the server for security reasons but it should work and I have done it successfully.
It is standard practice to create the keys on the client and transfer the public key to the server for security reasons but it should work and I have done it successfully.
...so I had it backwards...and the op is generating keys on the server...so that’s not right, then?
I’ll shut up now...
...so I had it backwards...and the op is generating keys on the server...so that’s not right, then?
I’ll shut up now...
Thanks scasey, you help is appreciated. When I fist had this issue I was generating the key pairs on my desktop with PuTTYgen and transferring the public key to the xxxxxx box. So this time I just flipped that and used ssh-keygen on the server and pulled off the private key. It should not matter what way around as the rsa keys are not encoded with any information specific to the box they are generated on.
But following that thought I checked that the key files were valid in case I messed up transferring them. (not sure if this is a 100% valid test)
Code:
root@yyyyyy:~/keys# ssh-keygen -l -f bob.id
2048 SHA256:V8xoylA3pk+/1gA5i7R8LhHMaFM8smuxsgS313UBLiU no comment (RSA)
I thought you were trying to obfuscate the username.
You can add debug messages via the ssh -v option. Adding -vs will increase the verbosity with max at 3.
For completion have you verified ownership/permissions of bob-id on machine yyyyyy. Was bob-id located in the current working directory?
It is standard practice to create the keys on the client and transfer the public key to the server for security reasons but it should work and I have done it successfully.
Here it is...
Code:
root@yyyyyy:~/keys# ls -la
total 20
drwxr-xr-x 2 root root 4096 Jun 28 13:18 .
drwx------ 9 root root 4096 Jun 27 08:23 ..
-rw------- 1 root root 1679 Jun 28 12:55 bob.id
-rw------- 1 root root 1675 Jun 27 07:07 root.id
Here is the vvverbouse output when trying to connect. All I'm seeing is "we did not send a packet, disable method" before it falls back to password only.
Code:
root@yyyyyy:~/keys# ssh -vvv -i bob.id bob@192.168.16.71
OpenSSH_7.4p1 Raspbian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.16.71" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.16.71 [192.168.16.71] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file bob.id type -1
debug1: key_load_public: No such file or directory
debug1: identity file bob.id-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u3
debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u3 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.16.71:22 as 'bob'
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from 192.168.16.71
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:tRyrXbZxhnl62UBT0tJ5LLu0VBwcddPRpcZpAvKXVSo
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from 192.168.16.71
debug1: Host '192.168.16.71' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: bob.id ((nil)), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,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: bob.id
debug3: sign_and_send_pubkey: RSA SHA256:V8xoylA3pk+/1gA5i7R8LhHMaFM8smuxsgS313UBLiU
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
bob@192.168.16.71's password:
OK Some progress... After reading another blog it was sugested I could also run sshd on the server in debug mode so that's what I did and again connected with the bob user and bob key.
Code:
root@xxxxxx:~# /usr/sbin/sshd -p 2020 -Dd -f /etc/ssh/sshd_config
debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2l 25 May 2017
debug1: private host key #0: ssh-rsa SHA256:6TZCnnYo8YoF/ExYQ2D7Y1CRFaRw7g+p5ZpIaNFwufM
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:tRyrXbZxhnl62UBT0tJ5LLu0VBwcddPRpcZpAvKXVSo
debug1: private host key #2: ssh-ed25519 SHA256:Ji23VJ7NJ+4KyvrNfG8Zyc+y7XRqnTn1w7xiej1ufFo
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='2020'
debug1: rexec_argv[3]='-Dd'
debug1: rexec_argv[4]='-f'
debug1: rexec_argv[5]='/etc/ssh/sshd_config'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 2020 on 0.0.0.0.
Server listening on 0.0.0.0 port 2020.
debug1: Bind to port 2020 on ::.
Server listening on :: port 2020.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.16.79 port 50524 on 192.168.16.71 port 2020
debug1: Client protocol version 2.0; client software version OpenSSH_7.4p1 Raspbian-10+deb9u3
debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u3 pat OpenSSH* compat 0x04000000
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u3
debug1: Enabling compatibility mode for protocol 2.0
debug1: permanently_set_uid: 107/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: curve25519-sha256 [preauth]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none [preauth]
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: rekey after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey after 134217728 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user bob service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "bob"
debug1: PAM: setting PAM_RHOST to "192.168.16.79"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user bob service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: temporarily_use_uid: 1002/1002 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: Could not open authorized keys '/root/.ssh/authorized_keys': Permission denied
debug1: restore_uid: 0/0
Failed publickey for bob from 192.168.16.79 port 50524 ssh2: RSA SHA256:V8xoylA3pk+/1gA5i7R8LhHMaFM8smuxsgS313UBLiU
So clearly when I login as bob sshd is looking to /root/.ssh/authorized_keys and obviously getting blocked because it's not something bob should have access to.
Back to /etc/ssh/sshd_conf to be 100% and yes it should be looking in the user home.
Code:
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
AuthorizedKeysFile ~/.ssh/authorized_keys
What are the file and directory permissions for /home/ and /home/bob/ and /home/bob/.ssh/ and /home/bob/.ssh/authorized_keys on the destination machine or are those the ones you posted in #4 above?
If I comment out the AuthorizedKeysFile directive in the config and restart ssh everything JUST STARTS WORKING like magic.
D'oh!
We all missed it even though you even posted that part of /etc/ssh/sshd_config in your original question in post #1. The AuthorizedKeysfile directive is relative to the user's home directory if nothing else is specified. The tilde overrode that and perhaps that part of sshd was running as root for authorization. From sshd_config(5)
AuthorizedKeysFile
Specifies the file that contains the public keys used for user
authentication. The format is described in the AUTHORIZED_KEYS
FILE FORMAT section of sshd(8). Arguments to AuthorizedKeysFile
accept the tokens described in the TOKENS section. After expan‐
sion, AuthorizedKeysFile is taken to be an absolute path or one
relative to the user's home directory. Multiple files may be
listed, separated by whitespace. Alternately this option may be
set to none to skip checking for user keys in files. The default
is ".ssh/authorized_keys .ssh/authorized_keys2".
Try the AuthorizedKeysFile directive again but without the tilde.
We all missed it even though you even posted that part of /etc/ssh/sshd_config in your original question in post #1. The AuthorizedKeysfile directive is relative to the user's home directory if nothing else is specified. The tilde overrode that and perhaps that part of sshd was running as root for authorization. From sshd_config(5)
AuthorizedKeysFile
Specifies the file that contains the public keys used for user
authentication. The format is described in the AUTHORIZED_KEYS
FILE FORMAT section of sshd(8). Arguments to AuthorizedKeysFile
accept the tokens described in the TOKENS section. After expan‐
sion, AuthorizedKeysFile is taken to be an absolute path or one
relative to the user's home directory. Multiple files may be
listed, separated by whitespace. Alternately this option may be
set to none to skip checking for user keys in files. The default
is ".ssh/authorized_keys .ssh/authorized_keys2".
Try the AuthorizedKeysFile directive again but without the tilde.
Yes your correct. this works fine as well.
Code:
AuthorizedKeysFile .ssh/authorized_keys
Just want to thank every one for your help on this, I won't get the two days of my life back but at least it's resolved now.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
