Ssh with 2FA using Google Authenticator worked well for many months. My cellphone broke and I had to use the backup codes. All backup codes were used.
I fixed the phone, I'm able to use the Google Authenticator, but the codes don't work. I tried using the 'Time correction for codes' but it didn't help.
The administrator of the servers can't access the root account of the server (they are using VMWare but they don't know how to login as root without the password, yes, they are a little stupid).
So, I can't access the server. What can I do, consider my limitations?
Thanks.
I don't see a way besides reset root's password.
To reset root's password: reboot the host, edit Grub boot options and add init=/bin/bash to the kernel line. This will drop you into a bash command prompt where you can run passwd to reset the password
See this full guide with images here.
After successfully reset of root's password, reconfigure Google Authenticator for your user.
P.S:
Authy is a good alternative for Google Authenticator. It syncs your codes between all your devices. So, if your phone gets broken or lost again you won't have these troubles anymore.
Authy has a ssh integration, you may give it a try.
I am using node v0.18.4 on a raspberry pi 3 Jessie. I want to secure the node-red editor, for which i followed the security.html page provided by node red and also I watched a video on youtube. I did the exact same steps, which are:-
1) Go to ~/.node-red/settings.js
2) Uncomment adminAuth
3) Install node-red-admin - sudo npm install -g node-red-admin
4) Generate hash password using, node-red-admin hash-pw
5) Paste the hashed password to adminAuth password field.
6) Save and restart node red
However I do not get the login prompt. The editor just loads without asking me for the username and the password.
I looked it up online, and all I found were httpNodeAuth. I am not trying to secure the UI, I am trying to secure the editor. Also I found a post that said sessions.json file would be written by node-red which was empty when I checked. It said that, it was because on when running node red on images, this file is not writable.
So I even followed the steps to placing the settings.json file to a writable location, and then created a shortcut for it in the node-red folder. This also didn't work out for me.
I also found a post where it said that the hashed password must have a correct format. I got a link to a hash password generator site. I copied the hash password from there but even that didn't result in the login prompt.
Please suggest why I might be getting this problem.
Thanks in advance.
I had somewhat similar problem on PC - asked for login at first, then didn't ask again. Shift with reload didn't change it either.
I did log out, then it asked for password, so you might try that. Also switching from Chrome to IE, I got a login as well.
I'm trying to connect to my Debian Google Compute Engine server through PuTTy (I've tried other alternatives too) but when I do I get the error "Disconnected: No supported authentication methods available (server sent: publickey)
The google server came without a username and password, only a url to automatically login to their own terminal.
I had PuTTY working and then one day got this error.
Solution: I had revised the folder path name containing my certificates (private keys), and this caused Pageant to lose track of the certificates and so was empty.
Once I re-installed the certificate into Pageant then Putty started working again.
Turn on Password Authentication
By default, you need to use keys to ssh into your google compute engine machine, but you can turn on password authentication if you do not need that level of security.
Tip: Use the Open in browser window SSH option from your cloud console to gain access to the machine. Then switch to the root user with sudo su - root to make the configuration changes below.
Edit the /etc/ssh/sshd_config file.
Change PasswordAuthentication and ChallengeResponseAuthentication to yes.
Restart ssh /etc/init.d/ssh restart.
Please follow this guide: https://gist.github.com/feczo/7282a6e00181fde4281b
with pictures.
In short:
Using Puttygen, click 'Generate' move the mouse around as instructed and wait
Enter your desired username
Enter your password
Save the private key
Copy the entire content of the 'Public key for pasting into OpenSSH authorized_keys file' window. Make sure to copy every single character from the beginning to the very end!
Go to the Create instances page in the Google Cloud Platform Console and in the advanced options link paste the contents of your public key.
Note the IP address of the instance once it is complete.
Open putty, from the left hand menu go to Connection / SSH / Auth and define the key file location which was saved.
From the left hand menu go to Connection / Data and define the same username
Enter the IP address of your instance
name the connection below saved Sessions as 'GCE' click on 'Save'
double click the 'GCE' entry you just created
accept the identy of the host
Now login with the password you specified earlier and run
sudo su - and you are all set.
You need to use an SSH key to login to your instance.
The GCE documentation explains the process here.
I had the same problem but got it working by changing enable-oslogin from TRUE to FALSE in google cloud.
from:
to:
I had the same issue and just figured it out !!
Assuming that you already went and created private/public key added your public key on the remote server ... type in username#remotehost.com and THEN go to Connection -> SSH -> Auth and click Browse to locate your private key. After you choose it will populate the input field. After that click OPEN ...
So the important thing here is the order... make sure you first enter parameters for the host and then locate your private key.
I got this error because I had forgotten to add my username behind the key in the GCE metadata section. For instance, you are meant to add an entry into the metadata section which looks like this:
sshKeys username:key
I forgot the username: part and thus when I tried to login with that username, I got the no supported auth methods error.
Or, to turn off the ssh key requirement entirely, check out my other answer.
Apparently running sudo chmod -R a+rw on your home folder causes this to happen as well.
This problem mainly caused by your connected username not have the access to the shell in GCE. So you use the following steps to solve this issue.
gcloud auth list
If you are using the correct login. please follow the below steps. otherwise use
gcloud auth revoke --all
gcloud auth login [your-iam-user]
and you get the token or it automatically detect the token.
gcloud compute --project "{projectid}" ssh --zone "{zone_name}" "{instance_name}" .
if you dont know this above line click to compute engine-> ssh dropdown arrow-> view google command-> copy that code and use it
Now it update your metadata and it is available in your computer's folder Users->username
~/.ssh/google_compute_engine.ppk
~/.ssh/google_compute_engine.pub
Then you create a new ppk file using puttygen and you give the username, which you want like my_work_space. Then
save the publickey and privatekey in a folder.
Next step: Copy the public key data from puttygen and create new ssh key in gcloud metadata
cloud console ->compute engine->metadata->ssh key->add new item->paste the key and save it
and now return your shell commandline tool then enter
sudo chown -R my_work_space /home/my_work_space
now you connect this private key using sftp to anywhere. and it opens the files without showing the permission errors
:) happy hours.
If the private key has been generated with ssh-keygen in Linux it needs to be converted with puttygen because Putty does not support openssh keys.
Start puttygen, and click on Conversions - Import key, then click Browse and select the private key generated with openssh, then click on Save private key.
Use your new key to connect.
I faced the same issue and solve after several trial and error.
In the /etc/ssh/ssh_config, set
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
AuthenticationMethods publickey
then, open putty.
In the "Saved Sessions", enter the server IP, go through the path Connection->SSH->Auth->Browse on the left panel to search your private key and open it.
Last but not least, go back to Session of putty on the left panel and you can see the server IP address is still in the field, "Saved Sessions", then click "Save", which is the critical step.
It will let the user login without password any more.
Have fun,
Download "PuttyGEN" get publickey and privatekey
use gcloud SSH edit and paste your publickey located in /home/USER/.ssh/authorized_keys
sudo vim ~/.ssh/authorized_keys
Tap the i key to paste publicKEY.
To save, tap Esc, :, w, q, Enter.
Edit the /etc/ssh/sshd_config file.
sudo vim /etc/ssh/sshd_config
Change
PasswordAuthentication no
[...]
ChallengeResponseAuthentication to no.
[...]
UsePAM no
[...]
Restart ssh
/etc/init.d/ssh restart.
the rest config your putty as tutorial
NB:choose the pageant add keys and start session would be better
Electricity went down and got this error. Solution was to double click your .ppk (Putty Private Key) and enter your password.
PasswordAuthentication and ChallengeResponseAuthentication default set to NO in rhel7.
Change them to NO and restart sshd.
Similar problem - same error message. I got the same message when trying to clone something from bitbucket with ssh. The problem was in my ssh configuration configured in the mercurial.ini: I used the wrong bitbucket username. After I corrected the user name things worked.
For me these was my problem, solution from https://unix.stackexchange.com/questions/282908/server-refused-public-key-signature-despite-accepting-key-putty
"Looking at the log /var/log/secure showed that it was just downright refused. I'm somewhat new to centos since I'm mainly a debian kind of guy, so I was unaware of /var/log/secure
After checking this and doing a bit of searching, it turns out PermitRootLogin no needs to be PermitRootLogin without-password if you want to specifically use just keys for root login. That did the trick. Thanks everyone for contributing."
I had the same error message and discovered that my mistake was in the username I used with putty. Apparently GCE SSH Keys listing would change your username characters in some of the listing. In my case, the underscore was changed to period. i.e: my_username becomes my.username
I inadvertently copied the wrong username from the listing and got the same error message.
I know this is an old question, but I had the same problem and solved it thanks to this answer.
I use Putty regularly and have never had any problems. I use and have always used public key authentication. Today I could not connect again to my server, without changing any settings.
Then I saw the answer and remembered that I inadvertently ran chmod 777 . in my user's home directory. I connected from somewhere else and simply ran chmod 755 ~. Everything was back to normal instantly, I didn't even have to restart sshd.
I hope I saved some time from someone
Today I've restarted my computer (running Windows Vista) and when it went up again, it showed a Windows log-in screen. This screen has never appeared before (for almost 4 years now. Windows is original, came with the laptop.
On the screen I had 2 options to enter with: PC-Name (let's call it Johnny) and "Privileged Server". Both of them are asking for password.
Now I don't think that I had ever set a password for my account, nor did it ever ask me to use one, in order to start Windows.
A few tries of my frequently used password, including some "easy" / default passwords such as 1234, admin, 1-9, and so on, were futile.
I am not able to enter my Windows at the moment.
What I suspect happened, is that Cygwin is somehow the cause for it.
Last week I tried to install Hadoop on my Windows, and I followed the Apache tutorial, which instructed to start sshd service on the computer (which is done with Cygwin). during the process of starting that service, there have been some steps that could have messed up the windows account. (setting RSA password / phraseless RSA thingie / whatever)
It also said in the middle, something about problems with the "accounts in the system".
I am sorry I can't be more informative about it, but these commands, among others, were used:
$ ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
I can't find the exact tutorial(s) I've been working according to, but this one has some stuff I did: oracle docs
the relevant steps are under the headline "Configuring SSH After Installing Cygwin", steps 1-4
Any help will be appreciated
Look for cyg_server in your registry and get rid of it. You will need it, however, if you're doing sshd with cygwin.
I've spent quite a few hours trying to figure out what the problem is. The issue is:
Login works but the page doesn't change once I log in as admin. I know that the login works because wrong credentials generate an error. I do not even see the administrative toolbar. No other pages exist on the page, but if I am to, say, input ?q=admin, on user/1, it will go 'Access Denied'
What I've done:
cleared cache and cookies many times
have checked that mod_rewrite works
the cookie path on the drupal settings.php is / and not \
.htaccess is on the drupal root directory, exactly as provided by
drupal.org
in httpd.conf, I have written a new directory and AllowOverride=All
(*note: the parent directory has AllowOverride=None)
Clean URL's are enabled via drush vset
What I suspect the problem is, but don't know how to solve it:
Proxy?
Some permissions that need to be configured on some files/directories
What I have:
CentOS 6.3
Apache 2.2.15
Drush 5.9
Drupal 7.22
Thank you in advance
I can't imagine that this would be a permissions issue, but if it were, you could just start by doing (and btw, I would NEVER recommend doing this on a production server):
cd /<path_in_which_drupal_root_sits>
chown -R apache:apache <drupal_root>
chmod -R 777 <drupal_root>
You might need to sudo to do these, and you will definitely want to bring the chmod permission back down to 775, 755 or 644 as is appropriate to the directory/sub-directory once you're done testing.
This will probably not solve your issue outright, but it will at least help you to eliminate permissions as an issue.
To test proxy issues, you might try installing lynx (command-line http client), and try accessing your site through it using localhost. You should be able to login, and if you get a different result that way than via remote access, you might indeed have some weird proxy or other network issue that's interfering.
Lastly, and this might actually be the most helpful bit here, you ought to inspect your headers before, during and after the login process. You can do this using FireBug or Developer Tools or the like. And, of course, check your Apache access and error logs for anything unexpected or out of the ordinary.
Most likely, though, you just need to reinstall and try it again.
Turns out that it was a SELinux problem. I found out that if I logout via the logout URL and then use https on my website, I can login and use it properly. I needed to reinstall the certificates and setup the security... Thanks for everyone's help.