Tag Info

Hot answers tagged

47

Your shell is meant to evaluate that shell code output by ssh-agent. Run this instead: eval "$(ssh-agent)" Or if you've started ssh-agent already, copy paste it to your shell prompt (assuming you're running a Bourne-like shell). ssh commands need to know how to talk to the ssh-agent, they know that from the SSH_AUTH_SOCK environment variable.


18

This is a typical example of a trade-off between security and convenience. Luckily there are a number of options. The most appropriate solution depends on the usage scenario and desired level of security. ssh-key with passphrase, no ssh-agent Now the passphrase has to be entered every time the key is used for authentication. While this is the best option ...


14

Use the -l option to ssh-add to list them by fingerprint. $ ssh-add -l 2048 72:...:eb /home/gert/.ssh/mykey (RSA) Or with -L to get the full key in OpenSSH format. $ ssh-add -L ssh-rsa AAAAB3NzaC1yc[...]B63SQ== /home/gert/.ssh/id_rsa The latter format is the same as you would put them in a ~/.ssh/authorized_keys file.


11

The server can't know whether the key you're using to connect to it has a passphrase or not. The passphrase is used to encrypt the SSH key for storage. When you use an SSH key, it is decrypted into memory using the passphrase so that it can be used to connect to the server. So the server has no way to tell whether the key being used was decrypted or not. ...


11

If you're checking from the server that people are connecting to, then no dice. The SSH key has to be decrypted in memory before use, which means to the server they look the same. Unless you can get a copy of the actual key file, you're sunk. But if you're on the machine people are connecting from, well then it's trivial -- just look at the key file. ...


7

The addition of keys to the agent is transient. They last only so long as the agent is running. If you kill it or restart your computer they're lost until you re-add them again. From the ssh-agent man page: excerpt #1 ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA, ECDSA). The idea is that ssh-agent is started ...


6

Pass the -t option to ssh-agent or to ssh-add. The argument can be a number of seconds or use other time units.


6

If it were setgid root then the agent would run as group root, which likely has broader permissions than the user it started as. That could be a security risk; at the least, running something as root unnecessarily is a red flag (even the group) and requires extra attentiveness. Setting the group ownership to nobody, which is a group that shouldn't have any ...


5

When you run ssh with no command, it sets up a pseudo-terminal on the server side and runs an interactive shell in that terminal. When you pass a command, the command is executed with its input and output directly connected to the SSH channel, there is no remote terminal. If you pass the -t option, then a terminal is created on the remote side, and you will ...


5

Try running eval $(ssh-agent -s) before ssh-add, to export the environment variables that refer to the just started agent, then run ssh-agent -k (without eval) at end of script to kill the agent.


5

Well first off, keys are supposed to identify the client, not the remote server. Thus you should only have a very small number of keys (such as 1). The official ssh-agent utility itself will only look for a few predefined names when looking for your keys (~/.ssh/id_rsa ~/.ssh/id_dsa ~/.ssh/id_ecdsa and ~/.ssh/identity). However there are other ssh key ...


4

(Long story short, it uses FOG.) If I understood your question properly, I guess it comes from EC2 like this: lib/chef/knife/ec2_server_create.rb knows something about the SSH key name in this section (def run): server = connection.servers.create(create_server_def) # ... msg_pair("SSH Key", server.key_name) this connection.servers.create can be found in ...


4

You need to enable authentication agent connection forwarding (Option "-A"). Example: hostA$ ssh -A hostB # agent forwarding enabled hostB$ ssh-add hostB$ ssh hostC # tries now the keys from hostA and the newly added hostC$ If you do not want to forward a key for security reasons, you could start a new ssh-agent instance by using hostB$ eval ...


4

You probably want to unlock private keys on your server to access different machines from there using these keys. Since these are the same keys as on your local machine, there is an easier way than unlocking those, by using ssh key forwarding. This concept is described here in the section ' Public Key Access with Agent Forwarding'. From the commandline ...


3

As usual? { eval `ssh-agent`; ssh-add /path/to/my/key; } &>/dev/null


3

The question is too broad so there are multiple variants to fix this. The first one is to use a key without passphrase. Technically, a passphrase is a key for some symmetric crypting algorithm which crypts local private key. Empty passphrase means the key isn't crypted and can be used by any who has access to read it. You can instruct ssh-keygen to use ...


3

As answered elsewhere, the trick is adding the option IdentitiesOnly yes which makes sure that only the configured keys will be used even if others are available from the agent.


3

Try using -A option in order to forward auth agent connection, something like this: ssh -A serverA 'bash -s' < deploy.sh


3

It turns out that the key that didn't work wasn't configured properly in the authorized_keys file after all. Sorry about that... I wrongly assumed that ssh -i /home/user1/.ssh/id_rsa user1@myserver was an indication that it was configured properly, but this turns out not to be the case. It makes use of other keys too. Forcing ssh -i /home/user1/.ssh/id_rsa ...


3

You can use the -A option to forward the agent connection to the remote host (ssh commands on B will talk to the agent on A, so you don't need to ssh-add). But note that Agent forwarding may be administratively prohibited on B. Otherwise, you'll have to start an agent on B: eval "$(ssh-agent)" ssh-add ...


3

if [[ -o login ]]; then echo "I'm a login shell" fi if [[ -o interactive ]]; then echo "I'm interactive" fi [[ -o the-option ]] returns true if the-option is set. You can also get the values of options with the $options special associative array, or by running set -o. To check if there's an ssh-agent: if [[ -w $SSH_AUTH_SOCK ]]; then echo ...


3

In your remote shell, can simply run: ssh-agent bash That way you get a new SSH agent instance and a new bash shell with the necessary environment variables set. When you leave the shell with exit or logout, the SSH agent quits as well. If you have the same keys available in the device you're using directly, you can also use ssh -A to make the local ...


2

You can use this pattern to solve your problem: http://superuser.com/questions/180148/how-do-you-get-screen-to-automatically-connect-to-the-current-ssh-agent-when-re That allows you to have the SSH agent connection dynamically updated to reflect each connection; I think it uses screen, but tmux should be very much the same pattern. The principal is to use ...


2

I don't actually use gnome, but chances are it's trying to communicate to an ssh-agent (or even starting one for your convenience). You didn't mention whether or not your keys are passwordless. Another things that MAY have gone wrong in the copy is the permissions on a) user2's /home, b) their .ssh or c) the authorized_keys file.


2

What is meant to happen is: You start a gnome session, part of that a gnome-keyring daemon (which also acts as a ssh agent) starts and the environment of anything started during that gnome session is updated with information on how to contact that ssh agent. The password you issue upon graphically logging in is used to unlock the default keyring. When you ...


2

Yes, ssh uses the SSH_AUTH_SOCK variable to access the agent. If you start different agents in different sessions they will not share the keys. Run ssh-agent to see the variables set by this instance. Read man ssh-agent to find out about possible options. (Especially -a should be helpful in your case.) The best way to share one agent pretty much depends ...


2

Sorry, not an answer but too long for a comment, which I think is in place. Important thing is what you are trying to achieve by storing the key in the database encrypted. An attacker that is able to access the temporary private key file will be able to read the ssh client process' memory as well (and hence get to the key data anyway), because both of ...


2

If you want to use the existing tools like ssh/ssh-agent you have to provide the key as a file. Another, maybe more feasible solution is to either directly implement a ssh client within your application and depend on third party libraries such as JSch or extend either ssh/ssh-agent to directly receive and decrypt the key from your database.


2

I use keychain to manage my ssh-agent environment variables, and it deals with making sure only one agent is running at a time. From my .bashrc on appropriate machines: # is this an interactive shell? if [[ $- == *i* ]]; then # set up ssh key server if [[ -x /usr/bin/keychain ]]; then eval $(keychain --eval --ignore-missing the <keys I ...


2

You can make a script for everyone's login process which checks if at least one ssh-agent instance is running (for this user) selects the instance to be used (the oldest) checks whether the socket info for this process is available (and correct) in case of success takes this info in its own environment and maybe kills the other instances (at least its own ...



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