Hot answers tagged

160

Use the -y option to ssh-keygen: ssh-keygen -f ~/.ssh/id_rsa -y > ~/.ssh/id_rsa.pub From the 'man ssh-keygen' -y This option will read a private OpenSSH format file and print an OpenSSH public key to stdout. Specify the private key with the -f option, yours might be dsa instead of rsa. The name of your private key probably contains ...


77

For OpenSSH there's also BatchMode which in addition to disabling password prompting should disable querying for passphrase(s) for keys. BatchMode If set to “yes”, passphrase/password querying will be disabled. This option is useful in scripts and other batch jobs where no user is present to supply the password. The argument must be ...


37

From yum -h: --nogpgcheck disable gpg signature checking


36

You can have as many keys as you desire. It's good practice to use separate private/public key sets for different realms anyway, like one set for your personal use, one for your work, etc. First, generate two separate keypairs, one for home and one for work: ssh-keygen -t rsa -f ~/.ssh/id_rsa.home ssh-keygen -t rsa -f ~/.ssh/id_rsa.work Next, add an ...


36

I believe there is no technical reason, it's merely an artifact of Base64 and the length of the string. Try it out with any base 64 encoder 1 -> MQ== (1 characters, 2 equals) 12 -> MTI= (2 characters, 1 equals) 123 -> MTIz (3 characters, 0 equals) 1234 -> MTIzNA== (4 characters, 2 equals) [repeat] But I may be wrong about ...


34

Thinking more deeply about the authentication process, what needs to be kept secret? Amazon knows the public half of the key, and anybody can know the public half. The public half of the keypair, when matched with the private half, denotes that the private half was used to authenticate. You private key that is provided to you when Amazon generates a keypair ...


31

That is one of the reasons sudo exists. Simply allow your users to run 1 single command with only the pre-authorized command-line options and most obvious circumventions are solved. e.g. #/etc/sudoers %users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost sets up sudo so all members of the group users ...


23

If you raise the LogLevel to VERBOSE in /etc/sshd/sshd_config it will log the fingerprint of the public key used to authenticate the user. LogLevel VERBOSE then you get messages like this Jul 19 11:23:13 centos sshd[13431]: Connection from 192.168.1.104 port 63529 Jul 19 11:23:13 centos sshd[13431]: Found matching RSA key: 54:a2:0a:cf:85:ef:89:96:3c:a8:...


22

Just add a space after the key and put in the comment, e.g.: ssh-dss AAAAB3NzaC1kc3MAAACBAN+NX/rmUkRW7Xn7faglC/pxqbVIohbcVOt41VThMYORtMQr QSqMZugxew2s9iX4qRowHWLBRci6404nSydLiDe1q6/NmpK+oQ8zD1yXekl+fruBAYeno7f6dM7c 2swwwXY6knp4umXkLItxIUki6SXM0WfabJ8BwuNDyA8IrbFAAAAFQCynEN3MYXbs4AA7E/1I03jb ...


18

As already mentioned by pulegium, any generic configuration management software like Puppet, Chef, Bcfg2 or cfengine could accomplish the task. Since the authorized_keys file is not that complicated, you could also use rsync or a (D)SCM like git or hg to manage this file. You have the "master" file on one of your servers and serve it via rsync/git/hg/…. On ...


18

The ssh server decides which authentication options it allows, the ssh client can be configured to decide in which order to try them. The ssh client uses the PreferredAuthentications option in the ssh config file to determine this. PreferredAuthentications Specifies the order in which the client should try protocol 2 authentication methods. ...


17

Keep in mind that the server DOES have a private and public key which is completely separate from the keypair you generate as a user. The private key for the server is usually stored with the server configuration and the public key is transmitted by the server when you attempted to connect. You client compares the server's public key against your ...


17

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAtKYac1ZiC43jF6BdclPok0Yv2g4YecBVJ6a7qggOSGjRAxh2cckwCBUR6VoVc2vmt9tcHCLWuVVpKUTUynbMdWq8wOdbK7Ud7n63cpg1PL44Hg9Wn2kT/aJdMMABSE5wSNsffxslcoUhF4h0mHaf+X6E5IKVhhHsy2g1yeoc2//0Q5YPt5Kj72VY1j3aeZ8a/...


17

Amazon provides key generation services because some operating systems (cough, Windows, cough) may not make it easy to generate the SSH keypairs. With SSH (and SFTP), the public key is installed in the user's authorized_keys file as the EC2 instance starts up. The private key is held only by the user and is presented to authenticate against the server. ...


15

What you are looking for is generally referred to as mutual authentication. Normally a server certificate exists for "server authentication", which means it validates the identity of the server to the client. Note that when pursuing this scheme, you have an additional challenge of certificate renewal for the clients. Here is an example of how it is ...


14

There is a reason it is called a "Public Key" It is ment to be let out into the wild. the worst that could happen is that someone could encrypt files in such a way only your private key could decrypt it. Now if you lose you private key ... that is a whole 'nother can o worms.


12

Make sure the following configuration items are set like this in your sshd_config: PasswordAuthentication no UsePAM no ChallengeResponseAuthentication no


12

Assuming you mean public-key-authentication on a user-level by 'certificate' and you created them by using ssh-keygen with the default location, they should be at place where your ssh-client will find them. The key consists of a private part, usually stored in ~/.ssh/id_rsa and a public part in ~/.ssh/id_rsa.pub. The last one will have to be transferred to ...


12

Can anyone break the cycle for me? You are basically just experiencing the standard bootstrapping problem for public key cryptography. There are many places you can download the public keys for the various archives, but frequently they are not provided over HTTPS, and any checksum files are delivered from the same location. That wiki link you provided ...


11

There is a patch available for OpenSSH that allows it to use public keys from an LDAP server, but this only really makes sense if your auth/account checks are also done against that LDAP server (which is how my environment is set up). Also it's only as secure as your LDAP configuration (so you want to be using SSL & verifying keys). See http://code....


11

I found this question when trying to answer it myself. After some searching and experimentation, I've found a few other options for this. I'm going to skip the part about distributing keys as an alternative since Matt Simmons covered that. Also, I know there are times when that is not good enough. For example, if you are GitHub and have to store millions of ...


10

/etc/ssh/ssh_config is for the client. You want to set those options on the server config file, which is /etc/ssh/sshd_config.


10

Adding this: PreferredAuthentications keyboard-interactive,password,publickey,hostbased,gssapi-with-mic ...to my /etc/ssh/ssh_config helped me to solve this, and saved a lot of time too! You can check if it works by using ssh -v user@host command to connect, where -v stands for "verbose".


10

Yes, that will do it but you should add some keys to ~/.ssh/authorized_keys of course.


10

Your problem is that you didn't install debian-keyring as well. Simply run the following: apt-get install debian-keyring apt-get install debian-archive-keyring That's it.


10

Protocol 2 public key consist of: options, keytype, base64-encoded key, comment. There are actually more parts, but they could be (and almost always are) empty. The last part is comment and could be anything. So the answer to you question is NO, comment is not part of authentication. You could read more in documentation: http://www.linuxcertif.com/man/5/...


10

This seems like a good use case for host-based authentication. This is a method of authentication where SSH does not use an individual user's key on the local machine (in this case, your server) to authenticate; instead, it uses the host's private key, the one stored in /etc/ssh/ and which is only readable by root. To set this up, you'll need to create a ...


9

This is expected behaviour according to the man page of ssh_config: IdentityFile Specifies a file from which the user's DSA, ECDSA or DSA authentica‐ tion identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol version 2. Additionally, ...


9

You can also try this one liner: cat ~/.ssh/id_rsa.pub | ssh user@remote-system 'umask 077; cat >>.ssh/authorized_keys'


9

I doubt you're really using certificates for authentication. Almost all non-password-based SSH authentication is done with public-private key pairs, but without certificates getting involved at all. Before writing this Answer, I Googled, "ssh certificates", and the first 5 hits were from idiots erroneously referring to bare public keys (not certificates) ...



Only top voted, non community-wiki answers of a minimum length are eligible