Related
I am trying to compile some sources using a makefile. In the makefile there is a bunch of commands that need to be ran as sudo.
When I compile the sources from a terminal all goes fine and the make is paused the first time a sudo command is ran waiting for password. Once I type in the password, make resumes and completes.
But I would like to be able to compile the sources in NetBeans. So, I started a project and showed netbeans where to find the sources, but when I compile the project it gives the error:
sudo: no tty present and no askpass program specified
The first time it hits a sudo command.
I have looked up the issue on the internet and all the solutions I found point to one thing: disabling the password for this user. Since the user in question here is root. I do not want to do that.
Is there any other solution?
Granting the user to use that command without prompting for password should resolve the problem. First open a shell console and type:
sudo visudo
Then edit that file to add to the very end:
username ALL = NOPASSWD: /fullpath/to/command, /fullpath/to/othercommand
eg
john ALL = NOPASSWD: /sbin/poweroff, /sbin/start, /sbin/stop
will allow user john to sudo poweroff, start and stop without being prompted for password.
Look at the bottom of the screen for the keystrokes you need to use in visudo - this is not vi by the way - and exit without saving at the first sign of any problem. Health warning: corrupting this file will have serious consequences, edit with care!
Try:
Use NOPASSWD line for all commands, I mean:
jenkins ALL=(ALL) NOPASSWD: ALL
Put the line after all other lines in the sudoers file.
That worked for me (Ubuntu 14.04).
Try:
ssh -t remotehost "sudo <cmd>"
This will remove the above errors.
After all alternatives, I found:
sudo -S <cmd>
The -S (stdin) option causes sudo to read the password from the standard input instead of the terminal device.
Source
Above command still needs password to be entered. To remove entering password manually, in cases like jenkins, this command works:
echo <password> | sudo -S <cmd>
sudo by default will read the password from the attached terminal. Your problem is that there is no terminal attached when it is run from the netbeans console. So you have to use an alternative way to enter the password: that is called the askpass program.
The askpass program is not a particular program, but any program that can ask for a password. For example in my system x11-ssh-askpass works fine.
In order to do that you have to specify what program to use, either with the environment variable SUDO_ASKPASS or in the sudo.conf file (see man sudo for details).
You can force sudo to use the askpass program by using the option -A. By default it will use it only if there is not an attached terminal.
Try this one:
echo '' | sudo -S my_command
For Ubuntu 16.04 users
There is a file you have to read with:
cat /etc/sudoers.d/README
Placing a file with mode 0440 in /etc/sudoers.d/myuser with following content:
myuser ALL=(ALL) NOPASSWD: ALL
Should fix the issue.
Do not forget to:
chmod 0440 /etc/sudoers.d/myuser
Login into your linux. Fire following commands. Be careful, as editing sudoer is a risky proposition.
$ sudo visudo
Once vi editor opens make the following changes:
Comment out Defaults requiretty
# Defaults requiretty
Go to the end of the file and add
jenkins ALL=(ALL) NOPASSWD: ALL
If by any chance you came here because you can't sudo inside the Ubuntu that comes with Windows10
Edit the /etc/hosts file from Windows (with Notepad), it'll be located at: %localappdata\lxss\rootfs\etc, add 127.0.0.1 WINDOWS8, this will get rid of the first error that it can't find the host.
To get rid of the no tty present error, always do sudo -S <command>
This worked for me:
echo "myuser ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
where your user is "myuser"
for a Docker image, that would just be:
RUN echo "myuser ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
In Jenkins:
echo '<your-password>' | sudo -S command
Eg:-
echo '******' | sudo -S service nginx restart
You can use Mask Password Plugin to hide your password
Make sure the command you're sudoing is part of your PATH.
If you have a single (or multi, but not ALL) command sudoers entry, you'll get the sudo: no tty present and no askpass program specified when the command is not part of your path (and the full path is not specified).
You can fix it by either adding the command to your PATH or invoking it with an absolute path, i.e.
sudo /usr/sbin/ipset
Instead of
sudo ipset
Command sudo fails as it is trying to prompt on root password and there is no pseudo-tty allocated (as it's part of the script).
You need to either log-in as root to run this command or set-up the following rules in your /etc/sudoers
(or: sudo visudo):
# Members of the admin group may gain root privileges.
%admin ALL=(ALL) NOPASSWD:ALL
Then make sure that your user belongs to admin group (or wheel).
Ideally (safer) it would be to limit root privileges only to specific commands which can be specified as %admin ALL=(ALL) NOPASSWD:/path/to/program
I think I can help someone with my case.
First, I changed the user setting in /etc/sudoers referring to above answer. But It still didn't work.
myuser ALL=(ALL) NOPASSWD: ALL
%mygroup ALL=(ALL:ALL) ALL
In my case, myuser was in the mygroup.
And I didn't need groups. So, deleted that line.
(Shouldn't delete that line like me, just marking the comment.)
myuser ALL=(ALL) NOPASSWD: ALL
It works!
Running shell scripts that have contain sudo commands in them from jenkins might not run as expected. To fix this, follow along
Simple steps:
On ubuntu based systems, run " $ sudo visudo "
this will open /etc/sudoers file.
If your jenkins user is already in that file, then modify to look like this:
jenkins ALL=(ALL) NOPASSWD: ALL
save the file
Relaunch your jenkins job
you shouldnt see that error message again :)
This error may also arise when you are trying to run a terminal command (that requires root password) from some non-shell script, eg sudo ls (in backticks) from a Ruby program. In this case, you can use Expect utility (http://en.wikipedia.org/wiki/Expect) or its alternatives.
For example, in Ruby to execute sudo ls without getting sudo: no tty present and no askpass program specified, you can run this:
require 'ruby_expect'
exp = RubyExpect::Expect.spawn('sudo ls', :debug => true)
exp.procedure do
each do
expect "[sudo] password for _your_username_:" do
send _your_password_
end
end
end
[this uses one of the alternatives to Expect TCL extension: ruby_expect gem].
For the reference, in case someone else encounter the same issue, I was stuck during a good hour with this error which should not happen since I was using the NOPASSWD parameter.
What I did NOT know was that sudo may raise the exact same error message when there is no tty and the command the user try to launch is not part of the allowed command in the /etc/sudoers file.
Here a simplified example of my file content with my issue:
bguser ALL = NOPASSWD: \
command_a arg_a, \
command_b arg_b \
command_c arg_c
When bguser will try to launch "sudo command_b arg_b" without any tty (bguser being used for some daemon), then he will encounter the error "no tty present and no askpass program specified".
Why?
Because a comma is missing at the end of line in the /etc/sudoers file...
(I even wonder if this is an expected behavior and not a bug in sudo since the correct error message for such case shoud be "Sorry, user bguser is not allowed to execute etc.")
I was getting this error because I had limited my user to only a single executable 'systemctl' and had misconfigured the visudo file.
Here's what I had:
jenkins ALL=NOPASSWD: systemctl
However, you need to include the full path to the executable, even if it is on your path by default, for example:
jenkins ALL=NOPASSWD: /bin/systemctl
This allows my jenkins user to restart services but not have full root access
If you add this line to your /etc/sudoers (via visudo) it will fix this problem without having to disable entering your password and when an alias for sudo -S won't work (scripts calling sudo):
Defaults visiblepw
Of course read the manual yourself to understand it, but I think for my use case of running in an LXD container via lxc exec instance -- /bin/bash its pretty safe since it isn't printing the password over a network.
Using pipeline:
echo your_pswd | sudo -S your_cmd
Using here-document:
sudo -S cmd <<eof
pwd
eof
#remember to put the above two lines without "any" indentations.
Open a terminal to ask password (whichever works):
gnome-terminal -e "sudo cmd"
xterm -e "sudo cmd"
I faced this issue when working on an Ubuntu 20.04 server.
I was trying to run a sudo command from a remote machine to deploy an app to the server. However when I run the command I get the error:
sudo: no tty present and no askpass program specified
The remote script failed with exit code 1
Here's how I fixed it:
The issue is caused by executing a sudo command which tries to request for a password, but sudo does not have access to a tty to prompt the user for a passphrase. As it can’t find a tty, sudo falls back to an askpass method but can’t find an askpass command configured, so the sudo command fails.
To fix this you need to be able to run sudo for that specific user with no password requirements. The no password requirements is configured in the /etc/sudoers file. To configure it run either of the commands below:
sudo nano /etc/sudoers
OR
sudo visudo
Note: This opens the /etc/sudoers file using your default editor.
Next, Add the following line at the bottom of the file:
# Allow members to run all commands without a password
my_user ALL=(ALL) NOPASSWD:ALL
Note: Replace my_user with your actual user
If you want the user to run specific commands you can specify them
# Allow members to run specific commands without a password
my_user ALL=(ALL) NOPASSWD:/bin/myCommand
OR
# Allow members to run specific commands without a password
my_user ALL=(ALL) NOPASSWD: /bin/myCommand, /bin/myCommand, /bin/myCommand
Save the changes and exit the file.
For more help, read the resource in this link: sudo: no tty present and no askpass program specified
That's all.
I hope this helps
The solution to the problem is
If you came across this issue anywhere else apart from the Jenkins instance follow this from the 2nd step. The first step is for the user who is having issue with the Jenkins instance.
Go to Jenkins instance of Google Cloud Console.
Enter the commands
sudo su
visudo -f /etc/sudoers
Add following line at the end
jenkins ALL= NOPASSWD: ALL
Checkout here to understand the rootcause of this issue
No one told what could cause this error, in case of migration from one host to another, remember about checking hostname in sudoers file:
So this is my /etc/sudoers config
User_Alias POWERUSER = user_name
Cmnd_Alias SKILL = /root/bin/sudo_auth_wrapper.sh
POWERUSER hostname=(root:root) NOPASSWD: SKILL
if it doesn't match
uname -a
Linux other_hostname 3.10.17 #1 SMP Wed Oct 23 16:28:33 CDT 2013 x86_64 Intel(R) Core(TM) i3-4130T CPU # 2.90GHz GenuineIntel GNU/Linux
it will pop up this error:
no tty present and no askpass program specified
Other options, not based on NOPASSWD:
Start Netbeans with root privilege ((sudo netbeans) or similar) which will presumably fork the build process with root and thus sudo will automatically succeed.
Make the operations you need to do suexec -- make them owned by root, and set mode to 4755. (This will of course let any user on the machine run them.) That way, they don't need sudo at all.
Creating virtual hard disk files with bootsectors shouldn't need sudo at all. Files are just files, and bootsectors are just data. Even the virtual machine shouldn't necessarily need root, unless you do advanced device forwarding.
Although this question is old, it is still relevant for my more or less up-to-date system. After enabling debug mode of sudo (Debug sudo /var/log/sudo_debug all#info in /etc/sudo.conf) I was pointed to /dev: "/dev is world writable". So you might need to check the tty file permissions, especially those of the directory where the tty/pts node resides in.
I was able to get this done but please make sure to follow the steps properly.
This is for the anyone who is getting import errors.
Step1: Check if files and folders have got execute permission issue.
Linux user use:
chmod 777 filename
Step2: Check which user has the permission to execute it.
Step3: open terminal type this command.
sudo visudo
add this lines to the code below
www-data ALL=(ALL) NOPASSWD:ALL
nobody ALL=(ALL) NOPASSWD:/ALL
this is to grant permission to execute the script and allow it to use all the libraries. The user generally is 'nobody' or 'www-data'.
now edit your code as
echo shell_exec('sudo -u the_user_of_the_file python your_file_name.py 2>&1');
go to terminal to check if the process is running
type this there...
ps aux | grep python
this will output all the process running in python.
Add Ons:
use the below code to check the users in your system
cut -d: -f1 /etc/passwd
Thank You!
1 open /etc/sudoers
type sudo vi /etc/sudoers. This will open your file in edit mode.
2 Add/Modify linux user
Look for the entry for Linux user. Modify as below if found or add a new line.
<USERNAME> ALL=(ALL) NOPASSWD: ALL
3 Save and Exit from edit mode
I had the same error message when I was trying to mount sshfs which required sudo : the command is something like this :
sshfs -o sftp_server="/usr/bin/sudo /usr/lib/openssh/sftp-server" user#my.server.tld:/var/www /mnt/sshfs/www
by adding the option -o debug
sshfs -o debug -o sftp_server="/usr/bin/sudo /usr/lib/openssh/sftp-server" user#my.server.tld:/var/www /mnt/sshfs/www
I had the same message of this question :
sudo: no tty present and no askpass program specified
So by reading others answer I became to make a file in /etc/sudoer.d/user on my.server.tld with :
user ALL=NOPASSWD: /usr/lib/openssh/sftp-server
and now I able to mount the drive without giving too much extra right to my user.
Below actions work for on ubuntu20
edit /etc/sudoers
visudo
or
vi /etc/sudoers
add below content
userName ALL=(ALL) NOPASSWD: ALL
%sudo ALL=(ALL:ALL) NOPASSWD:ALL
I'm not sure if this is a more recent change, but I just had this problem and sudo -S worked for me.
Mac OSX Lion 10.7.
In an effort to get around weird environment stuff (homebrew wasn't installing wget, and I had all sorts of weird blocks and errors), I uninstalled zschrc and homebrew and a bunch of other stuff, then installed fish shell.
Now, whenever I try to push/pull to/from github, I get this error:
The authenticity of host 'github.com (204.232.175.90)' can't be established.
RSA key fingerprint is <string of colon-separated chars that I should probs keep private>.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/Users/sasha/.ssh/known_hosts).
So I tried to check the permissions of my ~./ssh folder, and got this, which looks fine to me:
-rw-r--r-- 1 sasha staff 97B Jul 9 22:56 config
-rw------- 1 sasha staff 1.7K May 16 2012 id_rsa
-rw-r--r-- 1 sasha staff 403B May 16 2012 id_rsa.pub
drwx------ 5 sasha staff 170B Jul 15 09:56 known_hosts
All that's in known_hosts is a pem file I used for ssh'ing (also with the "authenticity..." prompt) to an Amazon ec2 instance, though I tried copying id_rsa and id_rsa.pub there when things got desperate.
Any idea what's going on? I'd love to fix this so I don't get prompted all the many times I push/pull.
EDIT I followed these instructions successfully a while ago, so I do have my ssh keys on Github, and they're recognized, so that when I run ssh -T git#github.com, I get
Hi sashafklein! You've successfully authenticated, but GitHub does not provide shell access.
It seems to be exclusively my local computer that's unhappy with my ssh situation.
In your specific case, your known_hosts is a folder, so you need to remove it first.
For other people which experiencing similar issue, please check the right permission to your ~/ssh/known_hosts as it may be owned by different user (e.g. root). So you may try to run:
sudo chown -v $USER ~/.ssh/known_hosts
to fix it.
This is the solution i needed.
sudo chmod 700 ~/.ssh/
sudo chmod 600 ~/.ssh/*
sudo chown -R ${USER} ~/.ssh/
sudo chgrp -R ${USER} ~/.ssh/
For guys on Ubuntu, if you get this error:
Failed to add the host to the list of known hosts
Then simply delete the known_hosts file, and re-run your ssh. This will regenerate the known_host file with appropriate permissions, and add the remote host you are trying to ssh into to this file.
I think the OP's question is solved by deleting the ~/.ssh/known_hosts (which was a folder, not a file). But for other's who might be having this issue, I noticed that one of my servers had weird permissions (400):
-r--------. 1 user user 396 Jan 7 11:12 /home/user/.ssh/known_hosts
So I solved this by adding owner/user PLUS write.
chmod u+w ~/.ssh/known_hosts
Thus. ~/.ssh/known_hosts needs to be a flat file, and must be owned by you, and you need to be able to read and write to it.
You could always declare known_hosts bankruptcy, delete it, and continue doing things as normal, and connecting to things (git / ssh) will regenerate a new known_hosts that should work just fine.
Shouldn't known_hosts be a flat file, not a directory?
If that's not the problem, then this page on Github might be of some help. Try using SSH with the -v or -vv flag to see verbose error messages. It might give you a better idea of what's failing.
This command worked for me,
sudo chown -v $USER ~/.ssh/known_hosts
as mentioned by #kenorb.
The error was coming due to broken permissions, for the current user.
Okay so ideal permissions look like this
For ssh directory (You can get this by typing ls -ld ~/.ssh/)
drwx------ 2 oroborus oroborus 4096 Nov 28 12:05 /home/oroborus/.ssh/
d means directory, rwx means the user oroborus has read write and execute permission. Here oroborus is my computer name, you can find yours by echoing $USER. The second oroborus is actually the group. You can read more about what does each field mean here. It is very important to learn this because if you are working on ubuntu/osx or any Linux distro chances are you will encounter it again.
Now to make your permission look like this, you need to type
sudo chmod 700 ~/.ssh
7 in binary is 111 which means read 1 write 1 and execute 1, you can decode 6 by similar logic means only read-write permissions
You have given your user read write and execute permissions. Make sure your file permissions look like this.
total 20
-rw------- 1 oroborus oroborus 418 Nov 8 2014 authorized_keys
-rw------- 1 oroborus oroborus 34 Oct 19 14:25 config
-rw------- 1 oroborus oroborus 1679 Nov 15 2015 id_rsa
-rw------- 1 oroborus oroborus 418 Nov 15 2015 id_rsa.pub
-rw-r--r-- 1 oroborus root 222 Nov 28 12:12 known_hosts
You have given here read-write permission to your user here for all files.
You can see this by typing ls -l ~/.ssh/
This issue occurs because ssh is a program is trying to write to a file called known_hosts in its folder. While writing if it knows that it doesn't have sufficient permissions it will not write in that file and hence fail. This is my understanding of the issue, more knowledgeable people can throw more light in this.
Hope it helps
to me, i just do this :
rm -rf ~/.ssh/known_hosts
then :
i just ssh to the target host and all will be okay.
This only if you dont know, what permission and the default owner of "known_hosts" file.
just in case anyone else encounters this error message and the permissions on .ssh and .ssh/known_hosts look good.
My problem was that I had installed gh from snap and snap apps have limited access to the file system and apparently could not access .ssh. The solution is to remove the snap installation and install from apt.
It happened to me simply because of broken permissions. My user did not have read nor write access to that file. Fixing permissions fixed the problem
I generated the "ssh" key again and added to my git account. This worked for me.
Please find following commands to generate the "ssh-key":
$ ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
-> This creates a new ssh key, using the provided email as a label.
Generating public/private rsa key pair.
-> When you're prompted to "Enter a file in which to save the key," press Enter. This accepts the default file location.
Enter a file in which to save the key (/home/you/.ssh/id_rsa): [Press enter]
-> At the prompt, type a secure passphrase. For more information, see "Working with SSH key passphrases"
Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]
-> Your key is generated, to copy the key:
$ sudo cat /root/.ssh/id_rsa-pub
Hope this works!
For anyone interested, this one worked for me in Ubuntu:
Go to .ssh directory.
$ cd ~/.ssh
Remove the known_hosts file.
$ rm known_hosts
Re-push your Git changes.
I was having this issue and found that within ~/.ssh/config I had a line that read:
UserKnownHostsFile=/home/.ssh-agent/known_hosts
I just modified this line to read:
UserKnownHostsFile=~/.ssh/known_hosts
That fixed the problem for me.
It may be due to the fact that the known_hosts file is owned by another user i.e root in most cases.
You can visit the path directory given (/home/taimoor/.ssh/known_hosts in my case) and check if the root is the owner and change it to the default owner.
Example:
Error Description -
Before changing the owner -
After changing the owner -
"Failed to add the host to the list of know hosts"
Was also my error.
I tried chancing owner and rights.
And then i did see that it tried to write to "~/.ssh/known_hosts.d/"
Failed to add the host to the list of known hosts (~/.ssh/known_hosts.d/<hostname>).
if this also happens to you,
just create the folder:
mkdir ~/.ssh/known_hosts.d
chmod 700 ~/.ssh/known_hosts.d
While this wouldn't have Solved the Problem of the Original Poster, (since his system tryed to write to the "~/.ssh/known_hosts" file and not to an systemd directory like "~/.ssh/known_hosts.d/") i thought it would help others who searched for the same error message.
The difference is that when an system tries to write to an known_hosts file all host data will be contained there.
While in the directory it will create an file for each host in that directory.
For more info on such directories -> https://askubuntu.com/questions/7648/many-directories-have-a-d-suffix-extension-what-does-it-mean
#check permissions of directory and files.
ls -la ~/.ssh/
#in my case, ~/.ssh/known_hosts was owned by root.
sudo chown xxx:xxx ~/.ssh/known_hosts
#where xxx = my username
#then ssh to some server, the warning message will still appear until you have ssh'd in successfully once, to verify, exit and ssh in again.
Check permissions of the file, if it is good check parent directories
I had to correct
/home/sravindr/.ssh permissions which worked for me
it works with me when I tried the following commands
sudo chown $my_user .ssh/id_rsa
sudo chown $my_user .ssh/id_rsa.pub
sudo chown $my_user .ssh/known_hosts
This command worked for me,
sudo chmod +x ~/.ssh/known_hosts
I couldn't solve this despite all the above answers.
My solution was to move from ssh to https.
I'm trying to setup a GitHub account and every time I get to the point of entering a passphrase for my SSH key my terminal freezes. Here are my steps:
Parkers-MacBook-Pro:~ ppreyer$ ssh-keygen -t rsa -C Parker.preyer1#gmail.com
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/ppreyer/.ssh/id_rsa): (/Users/ppreyer/.ssh/id_rsa):
Created directory '/Users/ppreyer/.ssh'.
Enter passphrase (empty for no passphrase): (WONT LET ME TYPE ANYTHING)
Anybody else run into this problem?
You're on a unix compliant machine. Therefore, most terminal-based password entry mechanisms use what's called a "Unix password field" (as far as I know, that's the most common name for it). You do not actually see the characters you are typing, but they are there. Simply make sure you type the same thing twice and you should be good.
Give it a try, type your password and press Enter. Type it again and press Enter again. You've just create an SSH passphrase.
I agree with MaxMackie's answer (upvoted), but I also like to generate my ssh keys non-interactively:
[space]ssh-keygen -t rsa -f "${H}/.ssh/myKey" -C "Gitolite Admin access (not interactive)" -q -P "xxxx"
That generates a 'mykey' private ssh key and a 'mykey.pub' public ssh key in my ~/.ssh directory.
Note the space before the command, in order to avoid, in my bash session, to record that command in the bash history (because I have defined a HISTCONTROL=ignorespace as in "Execute a terminal command without saving it to .bash_history on OS X?")
I need to do the SSH key audit for GitHub, but I am not sure how do find my RSA key fingerprint. I originally followed a guide to generate an SSH key on Linux.
What is the command I need to enter to find my current RSA key fingerprint?
Run the following command to retrieve the SHA256 fingerprint of your SSH key (-l means "list" instead of create a new key, -f means "filename"):
$ ssh-keygen -lf /path/to/ssh/key
So for example, on my machine the command I ran was (using RSA public key):
$ ssh-keygen -lf ~/.ssh/id_rsa.pub
2048 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff /Users/username/.ssh/id_rsa.pub (RSA)
To get the GitHub (MD5) fingerprint format with newer versions of ssh-keygen, run:
$ ssh-keygen -E md5 -lf <fileName>
Bonus information:
ssh-keygen -lf also works on known_hosts and authorized_keys files.
To find most public keys on Linux/Unix/OS X systems, run
$ find /etc/ssh /home/*/.ssh /Users/*/.ssh -name '*.pub' -o -name 'authorized_keys' -o -name 'known_hosts'
(If you want to see inside other users' homedirs, you'll have to be root or sudo.)
The ssh-add -l is very similar, but lists the fingerprints of keys added to your agent. (OS X users take note that magic passwordless SSH via Keychain is not the same as using ssh-agent.)
The newer SSH commands will list fingerprints as a SHA256 Key.
For example:
ssh-keygen -lf ~/.ssh/id_dsa.pub
1024 SHA256:19n6fkdz0qqmowiBy6XEaA87EuG/jgWUr44ZSBhJl6Y (DSA)
If you need to compare it against an old fingerprint you also need to specify to use the MD5 fingerprint hashing function.
ssh-keygen -E md5 -lf ~/.ssh/id_dsa.pub
2048 MD5:4d:5b:97:19:8c:fe:06:f0:29:e7:f5:96:77:cb:3c:71 (DSA)
Also available: -E sha1
Update... YES...yes... I know... DSA keys for SSH should no longer be used, the older RSA key or newer ecliptic keys should be used instead.
To those 'admins' that keep editing the command I used in the above. STOP CHANGING IT! You make the command and resulting output mis-match!
To see your key on Ubuntu, just enter the following command on your terminal:
ssh-add -l
You will get an output like this:
2568 0j:20:4b:88:a7:9t:wd:19:f0:d4:4y:9g:27:cf:97:23 yourName#ubuntu (RSA)
If however you get an error like; Could not open a connection to your authentication agent.
Then it means that ssh-agent is not running. You can start/run it with:
ssh-agent bash (thanks to #Richard in the comments) and then re-run ssh-add -l
A key pair (the private and public keys) will have the same fingerprint; so in the case you can't remember which private key belong to which public key, find the match by comparing their fingerprints.
The most voted answer by Marvin Vinto provides the fingerprint of a public SSH key file. The fingerprint of the corresponding private SSH key can also be queried, but it requires a longer series of step, as shown below.
Load the SSH agent, if you haven't done so. The easiest way is to invoke
$ ssh-agent bash
or
$ ssh-agent tcsh
(or another shell you use).
Load the private key you want to test:
$ ssh-add /path/to/your-ssh-private-key
You will be asked to enter the passphrase if the key is password-protected.
Now, as others have said, type
$ ssh-add -l
1024 fd:bc:8a:81:58:8f:2c:78:86:a2:cf:02:40:7d:9d:3c you#yourhost (DSA)
fd:bc:... is the fingerprint you are after. If there are multiple keys, multiple lines will be printed, and the last line contains the fingerprint of the last loaded key.
If you want to stop the agent (i.e., if you invoked step 1 above), then simply type `exit' on the shell, and you'll be back on the shell prior to the loading of ssh agent.
I do not add new information, but hopefully this answer is clear to users of all levels.
Reproducing content from AWS forums here, because I found it useful to my use case - I wanted to check which of my keys matched ones I had imported into AWS
openssl pkey -in ~/.ssh/ec2/primary.pem -pubout -outform DER | openssl md5 -c
Where:
primary.pem is the private key to check
Note that this gives a different fingerprint from the one computed by ssh-keygen.
The fastest way if your keys are in an SSH agent:
$ ssh-add -L | ssh-keygen -E md5 -lf /dev/stdin
Each key in the agent will be printed as:
4096 MD5:8f:c9:dc:40:ec:9e:dc:65:74:f7:20:c1:29:d1:e8:5a /Users/cmcginty/.ssh/id_rsa (RSA)
$ ssh-add -l
will also work on Mac OS X v10.8 (Mountain Lion) - v10.10 (Yosemite).
It also supports the option -E to specify the fingerprint format so in case MD5 is needed (it's often used, e.g. by GitHub), just add -E md5 to the command.
On Windows, if you're running PuTTY/Pageant, the fingerprint is listed when you load your PuTTY (.ppk) key into Pageant. It is pretty useful in case you forget which one you're using.
This is the shell function I use to get my SSH key finger print for creating DigitalOcean droplets:
fingerprint() {
pubkeypath="$1"
ssh-keygen -E md5 -lf "$pubkeypath" | awk '{ print $2 }' | cut -c 5-
}
Put it in your ~/.bashrc, source it, and then you can get the finger print as so:
$ fingerprint ~/.ssh/id_rsa.pub
d2:47:0a:87:30:a0:c0:df:6b:42:19:55:b4:f3:09:b9
Sometimes you can have a bunch of keys in your ~/.ssh directory, and don't know which matches the fingerprint shown by GitHub/Gitlab/etc.
Here's how to show the key filenames and MD5 fingerprints of all the keys in your ~/.ssh directory:
cd ~/.ssh
find . -type f -exec printf "\n{}\n" \; -exec ssh-keygen -E md5 -lf {} \;
(For what the parameters mean, refer to this answer about the find command.
Note that the private/public files that belong to one key have the same fingerprint, so you'll see duplicates.
If your SSH agent is running, it is
ssh-add -l
to list RSA fingerprints of all identities, or -L for listing public keys.
If your agent is not running, try:
ssh-agent sh -c 'ssh-add; ssh-add -l'
And for your public keys:
ssh-agent sh -c 'ssh-add; ssh-add -L'
If you get the message: 'The agent has no identities.', then you have to generate your RSA key by ssh-keygen first.
Google Compute Engine shows the SSH host key fingerprint in the serial output of a Linux instance. The API can get that data from GCE, and there is no need to log in to the instance.
I didn't find it anywhere else but from the serial output. I think the fingerprint should be in some more programmer-friendly place.
However, it seems that it depends on the type of an instance. I am using instances of Debian 7 (Wheezy) f1-micro.
If you need to obtain that from the private key do it:
ssh-keygen -y -f key > key.pub && ssh-keygen -lf key.pub
To check a remote SSH server prior to the first connection, you can give a look at www.server-stats.net/ssh/ to see all SHH keys for the server, as well as from when the key is known.
That's not like an SSL certificate, but definitely a must-do before connecting to any SSH server for the first time.
On Fedora I do locate ~/.ssh which tells me keys are at
/root/.ssh
/root/.ssh/authorized_keys
I'm trying to make a certificate for testing and I am using this site How to: Create Your Own Test Certificate as a tutorial on how to but when it comes time to enter in the password after you create the password it says failed in the command prompt why is that?
What I've done:
First, I open a command prompt and type in:
cd C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
Second, I type in
makecert -sv myPrivateKeyFile.pvk -n "TestCert" myCertFile.cer -b 01/01/2011 -e 01/01/2015 -r
Then I create the password then enter the password on the sencond pop up box and then it says failed in command prompt
When I enter in this again, the popup is asking for the password pops up first this time, and I enter it in and it says:
Error: CryptCertStrToNameW failed => 0x80092023 (-2146885597)
makecert -sv myPrivateKeyFile.pvk -n "TestCert" myCertFile.cer -b 01/01/2011 -e 01/01/2015 -r
I solved the problem by running the program as an administrator, but I had to change also the name of certificate in a LDAP style like this (CN=...):
makecert -sv myPrivateKeyFile.pvk -n "CN=TestCert" myCertFile.cer -b 01/01/2011 -e 01/01/2015 -r
This was a bit of a shotgun-debug for me. I started with this after reading the makecert guide:
makecert.exe /b 01/01/2014 /e 01/01/2114 /len 256 /m 1200 /n "CN=In-House-Software" /pe /r /sr localMachine Test_Cert.cer
There's two error-causing flaws here:
/e and /m likely are not supposed to overlap; seems kind of obvious, but they didn't document it or create an expressive error message for it.
/len 256 was an invalid value -- too low. This also didn't seem too obvious/documented/expressed in a good error message. 512 did work. I didn't bother finding the floor-value, but by default 1024 is used.
I ended up using this with success:
makecert.exe /b 01/01/2014 /e 01/01/2114 /len 512 /pe /r /n "CN=In-House-Software" /sr localMachine Test_Cert.cer
The reason why I was getting this error is, because I didn't right click on cmd when I ran it. So when you have this problem you need to right click on cmd and then run as administrator and see if that fixes your problem as it did mine.
I also received this error when I specified the CA name for a self-signed cert, in other words, if you specify the '-cy authority' and the '-r' options, then DON'T specify the CA name explicitly in the name via the -n option.
The issue was by the publisher name not starting with "CN=".
This fixed the issue, I didn't need to run as administrator.
For some reason I couldn't run makecert properly from Dropbox folders. So try moving it to a solid disk like C:\ and try again.