0

I need to SSH from Ubuntu server into Windows 10 (OpenSSH). Everything is fine when I connect using username and password, but I have trouble if I introduce RSA key

  1. On Linux I ran ssh-keygen and generated 'id_rsa' and 'id_rsa.pub' without passphrase (location ~/.ssh).

  2. On Windows I copy/pasted content of id_rsa.pub into C:\Users\foobar\.ssh\authorized_keys

  3. On Linux I try to connect with following command

ssh -i /home/foobar/.ssh/id_rsa 192.168.100.101

but it just asks for password for user 'foobar' anyway, which if I enter allows me in without problem, but it does not use the key.

What am I missing? My best guess is that something's wrong on Windows end, but what?

Here is the verbose output:

autotunnel@ercserver:~$ ssh -v -i /home/autotunnel/.ssh/id_rsa 192.168.100.101
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.100.101 [192.168.100.101] port 22.
debug1: Connection established.
debug1: identity file /home/autotunnel/.ssh/id_rsa type 0
debug1: identity file /home/autotunnel/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_7.7
debug1: match: OpenSSH_for_Windows_7.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.100.101:22 as 'autotunnel'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:uk5rA8yTEzwrtTOQqC04u5SKnv56BbA1pBSiafkV3Ro
debug1: Host '192.168.100.101' is known and matches the ECDSA host key.
debug1: Found key in /home/autotunnel/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/autotunnel/.ssh/id_rsa RSA SHA256:7RJoq/HURzcbte/G+GI0/CY3ed6B44mDt+GevScznFI explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/autotunnel/.ssh/id_rsa RSA SHA256:7RJoq/HURzcbte/G+GI0/CY3ed6B44mDt+GevScznFI explicit
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
[email protected]'s password:

and here is the sshd_config

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedPrincipalsFile none
# For this to work you will also need host keys in %programData%/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp sftp-server.exe
# Example of overriding settings on a per-user basis
#Match User anoncvs
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Match Group administrators
 AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
asked Sep 10, 2020 at 20:53
6
  • Please run ssh with the "-v" flag to print debugging info, then edit your question to include the debugging output. You should also check on the windows server for any logs produced by the ssh server process. If it's refusing to accept a key from your client, it might be logging the reason why. This page suggests the logs would be in %programdata%\ssh\logs. Commented Sep 10, 2020 at 22:42
  • Thanks, I added -v output and %programdata%\ssh\logs folder is empty. Commented Sep 10, 2020 at 23:02
  • We now need your OpenSSH configuration file from the server. It doesn't appear the server has the key you want to use. Commented Sep 10, 2020 at 23:31
  • I added sshd_config, anything else? Commented Sep 10, 2020 at 23:44
  • I don't believe that to be the correct sshd_config file. The one you provided clearly indicates that password authentication is not allowed (the line is commented). You didn't answer the second part of my comment, it does not appear the server has a copy of your key in the correct location, so it's never used. Commented Sep 10, 2020 at 23:52

1 Answer 1

0

Thank you all for help, which finally lead me to solution.

It was all in permissions of authorized_keys file in Windows. There is recommended solution in link given by @dave_thompson_085, but it does not work anymore as required 'OpenSSHUtils' is depreciated and can't be officially downloaded. So basically I did the same thing but manually.

Bottom line:

  1. Login in Windows into user that you are ssh-ing into
  2. Delete existing .ssh folder (to start from clean slate)
  3. Create .ssh folder and authorized_keys file in it (with RSA key copy/pasted in it)
  4. Remove permission inheritances for both folder and file
  5. Remove all users (including Administrators) and leave only current user and SYSTEM (I tried without SYSTEM user and apparently it is important).

I did not change anything in sshd config file.

Hope it helps somebody to save time.

answered Sep 11, 2020 at 11:32
1
  • It’s odd this was the problem has the verbose log wasn’t actually complaining about the permissions on the keys Commented Sep 11, 2020 at 11:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.