Cygwin SSH public key auth UNC network path "not a directory" - ssh

I have a unique problem when accessing a Cygwin based SSH Server through public key (rsa) based authentication.
If I login to the server via password auth:
ssh Administrator#domain.com
I login just fine and can then either execute:
cd //anotherpc/shareName
or cd /backup/anotherpc where this is a symlink to the aforementioned network share
This is successful and I can access anything on that share without issue.
The problem arises if i do the same thing above just after logging in using a public key authentication mechanism.
The error output is:
cd //anotherpc/shareName
-bash: cd: //anotherpc/shareName: Not a directory
Update:
The /etc/sshd_config file has the following commands having removed all commented out lines:
Port 22
StrictModes no
AuthorizedKeysFile .ssh/authorized_keys
UsePrivilegeSeparation yes
Subsystem sftp /usr/sbin/sftp-server
It is extremely strange. Any help would be hugely appreciated!
Kind Regards

If you run this command before trying to access a network share, the required authentication token will be created.
net use '\machineName\shareName' /user:"DOMAIN\Username" password
For full details see:
See http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview

Related

Junos not accepting key authentication

I have a problem with ssh rsa key authentication. I'm using an SRX100H2 that is running JUNOS 12.1X46-D10.2. I generated a private/public key pair without password on an ubuntu host. I copied the public key in /var/tmp using scp on the SRX100H2 and committed the following changes:
user salvador {
uid 2001;
class super-user;
authentication {
ssh-rsa "ssh-rsa AAAA..."
}
}
I loaded the key with load-key-file command. The problem is I can't get authenticated. It's asking for the password every time, although the key has no password. I'm trying to use this account to run some script with fail2ban. To connect, I'm using:
ssh -i .ssh/name_of_the_key -l salvador x.x.x.x
I even went as far as modifying /var/etc/sshd_config on the SRX and added LogLevel DEBUG3, but for some reason it doesn't log so much information as a regular sshd linux daemon.
Is there a bug for this firmware version JUNOS 12.1X46-D10.2, or am I doing something wrong?
Thank you for your help.
I found a workaround. There is a python library named Junos PyEZ:
https://github.com/Juniper/py-junos-eznc
It can connect directly to a junos device using a username and password, without the need of an ssh key, and it can perform various configurations on the device. I managed to create a script that just adds an address in address book and adds that address in an address set that is applied to a security policy. This way the attacking host is banned and cannot access the exposed resources. The script is being run by fail2ban each time it is needed.

dokku - giving another user root access

I added another user's public ssh-key to my dokku server, but they can't login using ssh root#appname.com.
I can see their ssh-key in authorized_keys and also if I run sshcommand list dokku or sshcommand list root.
I have checked in the sudoers config, and it seems that all ssh-keys are given root permissions:
$ cat sudoers
/...
# User privilege specification
root ALL=(ALL:ALL) ALL
I am using the dokku-acl plugin, but haven't found anything in the docs that would help.
The server is an Aliyun ECS (China).
Feel like I am missing something simple. Any advice is very much appreciated!
root ssh access and dokku ssh access are governed separately. The user's public key should be added as is to the /root/.ssh/authorized_keys file, whereas the /home/dokku/.ssh/authorized_keys file should only be managed by the subcommands of the ssh-keys plugin (included with Dokku).
You may wish to remove the entries from both files manually, then add the entries back as described above. For dokku user access - which would grant the ability to push code as well as perform remote commands via ssh dokku#host $command - you can use the command dokku ssh-keys:add to add a specific user:
echo "PUBLIC_KEY_CONTENTS" | dokku ssh-keys:add some-user-name

Unable to connect using SSH to the pushed MobileFirst container image on Bluemix

I have built an MF container image and pushed it. I have copied the file in (Mac) ~/.ssh/id_rsa.pub to mfpf-server/usr/ssh before building the image.
I am trying to connect using the command in Mac terminal:
ssh -i ~/.ssh/id_rsa admin#public_ip
It says:
Permission denied (publickey).
Any idea? What is the user I shall use?
your problem is very probably related to the permissions of the pub key copied on the container or to the configuration of your key.
You could check the permissions of key copied on the container, sshd is really strict on permissions for the authorized_keys files: if authorized_keys is writable for anybody other than the user or can be made writable by anybody other than the user, sshd will refuse to authenticate (unless sshd is configured with StrictModes no)
Moreover such a problem won't be showed using ssh -v, it will showed only on daemon logs (on the container)
From man sshd(8):
~/.ssh/authorized_keys
Lists the public keys (RSA/DSA) that can be used for logging in
as this user. The format of this file is described above. The
content of the file is not highly sensitive, but the recommended
permissions are read/write for the user, and not accessible by
others.
If this file, the ~/.ssh directory, or the user's home directory
are writable by other users, then the file could be modified or
replaced by unauthorized users. In this case, sshd will not
allow it to be used unless the StrictModes option has been set to
“no”.
So I suggest you to check about the files and directories permissions.
Then check that the content of your pub key has been copied correctly on authorized_keys listing
/root/.ssh/authorized_keys
To access the container with the ssh key you need to use the "root" user.
ssh -i ~/.ssh/id_rsa root#<ip address>

Cannot ssh into server except with google dev console ssh

I cannot ssh from my computer into the server hosted on Google Cloud.
I tried the normal ssh-keygen with user#domain.com and uploading the public key, which worked last time, but this time it didn't. The issue started after I changed the password for the account. After that I could no longer ssh or sftp into the account, although I wasn't disconnected until I disconnected.
I then tried the gcloud ssh user#instance and it ran fine and told me it just hasn't propagated yet.
I added AllowUsers user to the server's ssh config file and I restarted ssh on the server, but still the same result
Here's the error:
Permission denied (publickey).
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
Update:
I've been working with Google tech support and this issue is still unresolvable. A file called authorized_keys permissions keep getting changed on boot to another user, who I also cannot log in as.
So I change it to:
thisUser:www-data 755
but on boot it changes it to:
otherUser:otherUser 600
There are a couple of things in order to fix this. You can take advantage of the metadata feature in GCE and add a startup script that would automatically change the permissions.
From the developers console, go to your Instance > Metadata and add a pair of Key/value
key : startup-script
value: chmod 755 /home/your_user/.ssh/authorized_keys OR chmod 755 ~/.ssh
after rebooting you should check the Serial Ouput option further down that page and see if it ran on startup. it should show you something along these lines :
startup script found in metadata.
startupscript: Running startup script /var/run/google.startup.script
Further information can be found HERE
Hope that helps!
I solved this by deleting the existing ssh key under Custom metadata in the VM settings. I then could login on ssh

Putty: Getting Server refused our key Error

I created key pair using puttygen.exe (client is windows 8). On server (Ubuntu 12.04.3 LTS), I have put my public key in ~/.ssh/authorized_keys. The public key is this:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231
So it's correct (one line, no comments, starts with ssh-rsa, etc.)
.ssh dir permission level is 700, authorized_keys file permission is 600. Both directory and file owned by the actual user that I try to log in.
When I try connecting I'm getting 'server refused our key' and server asks for password. That's all. Nothing is logged to /var/log/auth.log when attempting to log in with the key.
I've looked everywhere and all articles and tips mention setting chmod 600 and 700 for the file/directory and formatting the key correctly. I've done all this still getting 'refused our key' error and I'm out of ideas.
OK, there was a small typo in my key. Apparently when pasting to file the first letter was cut off and it started with sh-rsa instead of ssh-rsa.
nrathathaus - your answer was very helpful, thanks a lot, this answer is credited to you :) I did like you said and set this in sshd_conf:
LogLevel DEBUG3
By looking at the logs I realized that sshd reads the key correctly but rejects it because of the incorrect identifier.
Adding a few thoughts as other answers helped, but were not exact fit.
First of all, as mentioned in accepted answer, edit
/etc/ssh/sshd_config
and set log level:
LogLevel DEBUG3
Then restart sshd on the server to have it use the changed log level, e.g.:
sudo service ssh restart
Then try to authenticate, and when it fails, look for log file:
/var/log/secure
It will have errors you are looking for.
In my case I had to change the permissions of /home/user from 0755 to 0700 as well.
In my case, is a permission problem.
I changed the log level to DEBUG3, and in /var/log/secure I see this line:
Authentication refused: bad ownership or modes for directory
Googled and I found this post:
https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/
chmod g-w /home/$USER
chmod 700 /home/$USER/.ssh
chmod 600 /home/$USER/.ssh/authorized_keys
Basically, it tells me to:
get rid of group w permission of your user home dir
change permission to 700 of the .ssh dir
change permission to 600 of the authorized_keys file.
And that works.
Another thing is that even I enabled root login, I cannot get root to work. Better use another user.
Running Windows 8.1 I ran into the server refused our key problem.
Following the guide: https://winscp.net/eng/docs/guide_windows_openssh_server
It was easy to make a connection using the Windows login username and password. However, authenticating with the username in combination with a private key, the response was server refused our key.
Getting it to work with a public key came down to the permissions on the file:
C:\ProgramData\ssh\administrators_authorized_keys
This is a helpful page: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps
Stop the two OpenSSH services, then open a command prompt with admin permissions. Then run:
C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd
Note: specify the full path to the exe otherwise sshd complains.
This creates a one-time use connection listener. The -ddd is verbose level 3.
After making a connection, scanning the logs revealed:
debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
No such file or directory
Had to create the file: C:\ProgramData\ssh\administrators_authorized_keys
And copy the public key text into it, e.g: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505
And then save the file. I saved the file as UTF-8 with the BOM. Didn't test ANSI.
Then running the one-time command line again, in the logs showed:
debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
Authentication refused.
S-1-5-11 is the name given to the System.
To fix the Bad permissions, right click on the administrators_authorized_keys file, goto the Security Tab , click the Advanced button and remove inherited permissions.
Then delete all Group or user names: except for the Windows login username, e.g: YourMachineName\username
The permissions for that username should be Read Allow, Write Deny everything else is unchecked. The owner of the file should also be YourMachineName\username
This fixed the problem.
Other Useful links:
Download OpenSSH-Win32.zip from: https://github.com/PowerShell/Win32-OpenSSH/releases
C# example of how to use the WinSCPnet.dll to make a connection to the OpenSSH server: https://winscp.net/eng/docs/library#csharp
Here is the code snippet to make a connection using the WinSCPnet.dll:
static void WinSCPTest() {
SessionOptions ops = new SessionOptions {
Protocol = Protocol.Sftp,
PortNumber = 22,
HostName = "192.168.1.188",
UserName = "user123",
//Password = "Password1",
SshHostKeyFingerprint = #"ssh-rsa 2048 qu0f........................ddowUUXA="
};
ops.SshPrivateKeyPath = #"C:\temp\rsa-key-20190505.ppk";
using (Session session = new Session()) {
session.Open(ops);
MessageBox.Show("success");
}
}
Replace SshHostKeyFingerprint and SshPrivateKeyPath with your own values.
Edit: added screenshot of administrators_authorized_keys file permissions:
When OpenSSH SSH Server is running as a Service, then only System should have permission. However, if running sshd.exe from the command prompt, then the current user should be the only one listed (read allow, write deny).
The simple solution i found was to move the authorized_keys file away from the hidden .ssh directory and put it in the system ssh directory:
/etc/ssh/keys/authorized_keys
As soon as I did this it worked with no problems.
having same issue in windows server 2008 r2 and explored a lot to solve, finally did that by following:
open C:\Program Files (x86)\OpenSSH\etc\sshd_config with textpad or any other text editor
remove comment from following lines, after removing they should look like following:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
save it and try to login with private key now.
have fun.
I'm adding this answer to help anyone, like me, who spent hours scouring the internet without success.
YOUR HOME FOLDER MIGHT BE ENCRYPTED.
Or for that matter any folder in which your "authorized_keys" file is nested. Man, that would have saved me a lot of time. To check, go perform
ls -A
on the directory whose encryption status you would like to determine. If the folder contains a folder named ".encryptfs" the answer is, yes, that folder is encrypted. This will impede your ability to access the "authorized_keys" file containing the public ssh key needed for verification.
To fix this, place the "authorized_key" file in a directory tree that contains no encryption.
After adding key, login as ec2-user if you are using an Amazon Linux machine
If its ubuntu machine then use ubuntu
Thanks to nrathaus and /var/log/auth.log investigation on debug level comes the following.
Another reason is that your home directory may have permissions different than 755.
In my case it was caused by (/etc/ssh/sshd_config):
PermitRootLogin no
Changed to yes, restarted the service and got in normally.
I have solved this problem,puttygen is a third-party software, ssh key which generated by it didn't be used directly, so you must make some changes.
For example, it look like this
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ----
I omit some of the alphabets in the middle, replaced by *, if not, StackOverflow told me that the code format is wrong, do not let me post。
this is my ssh key generated by puttygen, you must change to this
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname#hostname
In my case, I have deleted some comments, such as
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----
and add ssh-rsa at the beginning,
add yourname#hostname at the last.
note: not delete== in the last and you must change "yourname" and "hostname" for you, In my case, is uaskh#mycomputer,yourname is that you want to log in your vps .when all these things have done,you could to upload public-key to uaskh's home~/.ssh/authorized_keys by cat public-key >> ~/.ssh/authorized_keys then sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keys then you must to modify /etc/ssh/sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys my operating system is CentOS 7,This is my first time to anwser question,I will try my efforts to do ,Thank you!
I encountered this problem today and my issue was that when copying the public key from file, new line characters are included as well. You can use ":set list" in vim to see all the hidden new lines and make sure to delete all the new lines except for the last one. Also, my key was missing "ssh-rsa " in the beginning. Make sure you have that as well.
The equivilent of an SSH command:
ssh -i <path_to_pem_file> ec2-user#calendar.com
In Windows, first use PuTTYGen to convert the pem file to a ppk file.
Open PuTTYGen
File/Load the private pem key (or an OpenSSH key)
In the Open FileDialog, use the drop down to select "All files" (it only shows ppk file formats not pem, also OpenSSH key files that can be converted like pem files don't have a file extension)
File/Save private key (*.ppk)
The same settings in Putty as the SSH command:
Open Putty
Session/Hostname: calendar.com
Connection/Data/Auto-login username: ec2-user
Connection/SSH/Auth/PrivateKeyFile Path: the file path to the PPK file
OpenSSH disable the ssh-rsa signature scheme by default in the next
release.
In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1
hash algorithm in conjunction with the RSA public key algorithm. It is
now possible1 to perform chosen-prefix attacks against the SHA-1
algorithm for less than USD$50K.
Source
So, update the key.
For those receiving this error from Windows Server, I received this same error and it was a user account issue. With many organizations, group policy for Administrators may not allow setting up SSH Server and connections. With that type of setup, this must be done from Local Admin account. Might be worth looking into if you have confirmed there are not any typos in the public key.
In my case, I had to disable SELinux on Centos6.6 to get it working :)
Edit /etc/selinux/config and set the following and then reboot the host.
selinux=disabled
BTW...forgot to mention that I had to set the LogLevel=DEBUG3 to identify the issue.
I had the same error on solaris but found in /var/adm/splunk-auth.log the following:
sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed
In /etc/shadow the account was locked:
weblogic:*LK*UP:16447::::::3
Removed the "*LK*" part:
weblogic:UP:16447::::::3
and I could use ssh with authorized_keys as usual.
I have this issue where sshd only reads from authorized_keys2.
Copying or renaming the file fixed the problem for me.
cd ~/.ssh
sudo cat authorized_keys >> authorized_keys2
P.S. I'm using Putty from Windows and used PuTTyKeygen for key pair generation.
I was facing similar issue when trying to logon through Mobaxterm. The private key was generated through puttygen. Regenerating the key helped in my case.
As my experience, I suggest you should generate keys from putty, should not generate from linux side. Because the key will be old PEM format. Anyway, just my suggestion. I did as steps below and worked fine with me and with my team.
Generate a key pair with PuTTYGen.exe on your local (type: RSA, length: 2048 bits).
Save private/public key as "id_rsa.ppk/id_rsa.pub" files on your local.
Create "authorized_keys" file on your local, then enter the public key in "id_rsa.pub" to "authorized_keys".
Remember content has to begin with "ssh-rsa" and one line only.
Use WinScp (or putty command) to copy "authorized_keys & id_rsa.pub" from your local to your linux-user-home "/home/$USER/.ssh/".
Run these commands:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
chown $USER:$USER .ssh -R
Test your connect setting by load the private key "id_rsa.ppk" in the PuTTY.exe profile, then click open (put your passphrase if have).
check your key, this should be a rsa (id_rsa.pub) key today and no longer a dss (id_dsa.pub) key, use puttygen 0.70 and choose RSA on type of key to generate, replace the public key on host ~/.ssh/authorized_keys
Oh my God I spent days trying to fix this. So here is what worked for me. I went back to the root fold like this:
cd /root/
mkdir .ssh
cd .ssh
chmod 700 .ssh
nano -w authorized_keys
service ssh restart
So I used root to logging via Putty and it worked. so try to do the same with the user you want to use in putty.
In the case of mine it was a wrong user:group attribution. I solved setting the right user and group:
sudo chown [user]:[group] -R /home/[user]
This helps to me:
# /etc/ssh/sshd_config
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa
# temporarily added:
LogLevel DEBUG3
# gentoo
# tail -n 50 /var/log/messages
and restart sshd
/etc/init.d/sshd restart
If you run Putty in a version before 0.75, then updating Putty should solve the problem.
Newer version of openSSH (as in Ubuntu 22.04) have deprecated the use of the SHA1 hashing algorithm during the login, but Putty used SHA1 until version 0.74.
If sshd log file on the server shows
$ sudo grep 'sshd' /var/log/auth.log
sshd[113232]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
then this in fact causing the error, and should be gone after Putty has been updated.
I'm using a PUTTYgen file with psftp, and I encountered this problem on my Windows Server when we were required to create new keys for a client. The private_key_name.ppk file and the open_ssh.txt file must be in the same directory for the connection to work.
In my case home on nfs was 777, needed to be 750. That fixed the issue.
When using Cpanel you can check if the key is authorized in
SSH Access >> Public keys >> Manage >> Authorize or Deauthorize.
if you get this error in /var/log/secure
error: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
it means your key is having space, if you generated key through puttgen when you view .ppk file, it will look like this:
AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==
and when you try to paste it you will get an error in reading key, so try to edit key and make it one line and try it
this should look like something
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username#domainname