Tag Info

Hot answers tagged

53

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.


39

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 ...


22

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.


15

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 ...


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. ...


10

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

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

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 ...


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

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

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 usual? { eval `ssh-agent`; ssh-add /path/to/my/key; } &>/dev/null


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

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

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 ...


3

Use tee to grab the output Tee Manual tee reads from Standard INPUT/OUTPUT to write files. I have a Python script which supports one of my requirements, and simple ">" redirection fails. Tee is the way to grab output. Your line should be: 10 04 * * * user /usr/bin/python2.7 /home/user/script.py -f someFlag | tee -a ~/cronout.log 2>&1 Try this: ...


3

To connect to the ssh-agent, ssh client (or any other process, for that matter) needs to know how to connect to it. This information is emitted by the ssh-agent when started in the form of shell commands. Usually it looks like this: $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-H8yPWdYCNFmT/agent.506989; export SSH_AUTH_SOCK; SSH_AGENT_PID=506990; export ...


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

Instead of having ssh-agent generate a random socket name, use the -a option to make it always use the same name. Export this name in the SSH_AUTH_SOCK environment variable. When you log in, run rm -f "$SSH_AUTH_SOCK" ssh-agent -a "$SSH_AUTH_SOCK" This way all your terminals will connect to the same agent. Then, either start one terminal when you log in ...


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

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

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.



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