# A way to "pipe" a password into SSH?

## Dragonlord

A rather simple task. I would like to directly connect from my administrative pc to the various other pcs I administer without having to enter the cryptic password for the SSH session pubkey all the time. Hence I thought if there are possibilities to still have a pubkey with a cryptic password but not having to enter it on this peticular ( and closed off ) machine.

I had three thoughts. First if there is a command line option allowing me to specify the password in a file or a like. I could not find such a thing. The second has been to pipe an 'echo' into ssh but this won't work as only interactive terminals are allowed. Finally I thought about a trick to make my bash script first copy the password to the cut-buffer so that I can paste it when the password is asked for. For that I could not find a solution so far.

Any ideas how I could achieve this?

----------

## Rayne

I had a similar problem. Have a look at this:

https://forums.gentoo.org/viewtopic-t-465047-highlight-.html

----------

## Janne Pikkarainen

Have you considered using keychain? With it you only need to type in your passphrase once, after that keychain will remember your passphrase.

----------

## contextswitch

 *Janne Pikkarainen wrote:*   

> Have you considered using keychain? With it you only need to type in your passphrase once, after that keychain will remember your passphrase.

 

or sys-auth/pam_ssh then the password bit is done when you login.

-- 

Geoff

----------

## Ast0r

 *Janne Pikkarainen wrote:*   

> Have you considered using keychain? With it you only need to type in your passphrase once, after that keychain will remember your passphrase.

 

Keychain is definitely the way to go.

----------

## contextswitch

 *Ast0r wrote:*   

> Keychain is definitely the way to go.

 

I'm not disagreeing with you but it would be helpful if you said why.

-- 

Geoff

----------

## Ast0r

 *contextswitch wrote:*   

>  *Ast0r wrote:*   Keychain is definitely the way to go. 
> 
> I'm not disagreeing with you but it would be helpful if you said why.
> 
> -- 
> ...

 

I just like keychain. It's very easy to use and provides a way to securely bypass password authentication. You enter the passphrase for your DSA/RSA key once when you start your computer and then ssh-agent keeps your key loaded until you reboot. So if you leave your box on for months at a time (which a linux box can do easily) then you enter the passphrase only once every couple months.

Furthermore, using DSA/RSA authentication is inherently more secure than password-based authentication (assuming that you disable password authentication once you have it set it) because it is not possible to log in without the DSA/RSA key ... it makes SSH nearly impossible to hack.

I have keychain on my desktop and it greatly simplifies logging into machines. I type my passphrase for my DSA key when I boot and then I just type "ssh [host]" and <BAM> I'm logged in. I also have keychain installed on a few other machines. Our devel server at our office needs to be able to automatically send files up to and bring files down from our web server. Keychain allows me to runs scripts as cron jobs (and as part of larger scripts) to accomplish this without password-based authentication.

EDIT: I just looked at sys-auth/pam_ssh and it looks like it provides a similar service. However, it looks like your login password has to match your SSH key passphrase. Is that correct?

Either way, pam_ssh doesn't seem to solve the problem of running cron jobs, unless I misinterpreted something.

----------

## contextswitch

 *Ast0r wrote:*   

> 
> 
> I just like keychain. It's very easy to use and provides a way to securely bypass password authentication. You enter the passphrase for your DSA/RSA key once when you start your computer and then ssh-agent keeps your key loaded until you reboot. So if you leave your box on for months at a time (which a linux box can do easily) then you enter the passphrase only once every couple months.
> 
> Furthermore, using DSA/RSA authentication is inherently more secure than password-based authentication (assuming that you disable password authentication once you have it set it) because it is not possible to log in without the DSA/RSA key ... it makes SSH nearly impossible to hack.
> ...

 

Thank-you for explaining that.

 *Ast0r wrote:*   

> EDIT: I just looked at sys-auth/pam_ssh and it looks like it provides a similar service. However, it looks like your login password has to match your SSH key passphrase. Is that correct?

 

It does indeed provide a very similar service as both keychain and pam_ssh rely on ssh-agent to get the job done so they both share the advantages that ssh-agent provides.  You are correct in saying that you log in using your SSH key passphrase but you can set up PAM so that if that fails it will automatically try your unix password in which case it will log you in but without starting ssh-agent.

 *Ast0r wrote:*   

> Either way, pam_ssh doesn't seem to solve the problem of running cron jobs, unless I misinterpreted something.

 

That's also correct, with pam_ssh the ssh-agent runs for the length of the login session whereas with keychain ssh-agent is running until you reboot.  This probably makes pam_ssh more suited to desktop machines but it's probably more down to taste (and the need to run cron jobs   :Smile:  )

-- 

Geoff

----------

## Ast0r

 *contextswitch wrote:*   

>  *Ast0r wrote:*   Either way, pam_ssh doesn't seem to solve the problem of running cron jobs, unless I misinterpreted something. 
> 
> That's also correct, with pam_ssh the ssh-agent runs for the length of the login session whereas with keychain ssh-agent is running until you reboot.  This probably makes pam_ssh more suited to desktop machines but it's probably more down to taste (and the need to run cron jobs   )
> 
> -- 
> ...

 

Yeah, pam_ssh sounds great for a desktop machine. With this in mind, either sounds like it will solve the problem he is trying to solve.

----------

## Dragonlord

Hm. So far key-chain has been mentioned but as far as I see there is a problem with this. You say you need to re-enter the password whenever you boot. Unfortunatly this is exactly the problem. I need like once upon a couple of days those passwords and it is really cryptic and impossible to memorize. Hence I need to look up the password each time and I want to avoid this ( as people could peep over my shoulder in "certain" places ). Hence I need a solution which keeps this password unseen and over reboots.

----------

## darkphader

http://expect.nist.gov/

It's in portage.

Chris

----------

## Dragonlord

This does the job. Thanks  :Very Happy: 

----------

## Dragonlord

 :Crying or Very sad:  ... unfortunatly not fully... damn.

I'm now stuck with this simple task just not working no matter what I do. I want to automate the scp command so I can simply write "scp.expect file host:/file". For this I made this script but it always complains.

```
#!/usr/bin/expect --

spawn scp -i key $argv

expect {

        "Enter passphrase for key 'key':" {

                send "****\n"

                interact

        }

        timeout {

                exp_continue

        }

}
```

But it always tells me:

```
scp: illegal option --  

usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]

           [-l limit] [-o ssh_option] [-P port] [-S program]

           [[user@]host1:]file1 [...] [[user@]host2:]file2
```

Any ideas why it does not work? I replaced scp with echo and there is no "--" argument passed so why does it complain? If I use the command on the command line it works hence it has to be expect doing something wrong there.

----------

## Janne Pikkarainen

 *Dragonlord wrote:*   

> Any ideas why it does not work? I replaced scp with echo and there is no "--" argument passed so why does it complain? If I use the command on the command line it works hence it has to be expect doing something wrong there.

 

Yes there is a "--" argument passed. Look at the very first line of your expect script.  :Wink: 

```
#!/usr/bin/expect --
```

----------

## Dragonlord

But this ain't true. Like I said I used "echo" instead of "scp" and I got no "--" parameter shown. I also ommited the "--" and I get the same output. So for example if I run it using the line

"#!/usr/bin/expect -f"

and using "expect -f myscript ..." with the same parameters but no -- I still get the same output.

----------

## Ast0r

You could try giving us the parameters that you are using when you call the script.

----------

## Dragonlord

Ok, here the full bits.

scp.expect /local/file host.net:/remote/file

with echo I get "-i key /local/file host.net:/remote/file" like I should. with scp I get the error. Here how the two lines look.

```
spawn scp -i key $argv
```

```
spawn echo -i key $argv
```

----------

## Ox-

If ssh-agent/keychain are too much hassle with having to type in the password once every reboot you should just use keys without a passphrase.

That's no less secure than having your passphrase visible in an expect script.

----------

## Dragonlord

The script is 0700. This is not readable to anybody else than me ( and root, which is also me ). It simply doesn't make sense to use keychain if you have already expect working for ssh connections. I simply don't get why it fails for scp but works on ssh.

----------

## darkphader

 *Dragonlord wrote:*   

> The script is 0700. This is not readable to anybody else than me ( and root, which is also me ). It simply doesn't make sense to use keychain if you have already expect working for ssh connections.

 

If you use a private key without a passphrase then keychain isn't needed. It seems no less safe than using the expect script and might be more safe as you can set ssh to not accept passwords thereby preventing some attacks. The private key should only be readable by you as well (0400 works) and is therefore no less secure.

----------

## Dragonlord

Could be an idea. There is indeed only one user allowed to ssh into the machine anyways. Just need to figure out this "no-password" thingy.

----------

## Ast0r

 *Ox- wrote:*   

> If ssh-agent/keychain are too much hassle with having to type in the password once every reboot you should just use keys without a passphrase.
> 
> That's no less secure than having your passphrase visible in an expect script.

 

I could not, in good conscience, suggest to someone that they use keys without a passphrase. That's really irresponsible.

----------

## darkphader

 *Ast0r wrote:*   

> I could not, in good conscience, suggest to someone that they use keys without a passphrase. That's really irresponsible.

 Not under the current given circumstances (a refusal to type the password, even as little as every boot). Are you suggesting that it is less safe than using a script that contains the password in plain text? It seems to be the better solution (of the two - and if not please explain) and the private key would have to be compromised (stolen) to effect any damage.

----------

## Dlareh

A passwordless key in a file and a password in a plaintext file are both equally insecure.

But they can be convenient.

----------

## Ast0r

 *Dlareh wrote:*   

> A passwordless key in a file and a password in a plaintext file are both equally insecure.
> 
> But they can be convenient.

 

Exactly. Having a key without a [strong] passphrase is just as bad as having the password in a script. If a user is able to read *either*, they can log in as the user for which the key is added on the remote system(s). In fact, a key is probably worse, because I'd be willing to bet the root password is more likely to be changed than the key is.

----------

## Ox-

 *Ast0r wrote:*   

>  *Ox- wrote:*   If ssh-agent/keychain are too much hassle with having to type in the password once every reboot you should just use keys without a passphrase.
> 
> That's no less secure than having your passphrase visible in an expect script. 
> 
> I could not, in good conscience, suggest to someone that they use keys without a passphrase. That's really irresponsible.

 Ah, but you can in good conscience go along with them having their passphrase in plaintext in a script.   :Rolling Eyes: 

----------

## Ast0r

 *Ox- wrote:*   

>  *Ast0r wrote:*    *Ox- wrote:*   If ssh-agent/keychain are too much hassle with having to type in the password once every reboot you should just use keys without a passphrase.
> 
> That's no less secure than having your passphrase visible in an expect script. 
> 
> I could not, in good conscience, suggest to someone that they use keys without a passphrase. That's really irresponsible. Ah, but you can in good conscience go along with them having their passphrase in plaintext in a script.  

 

I never said that. I recommended keychain.

----------

## Dragonlord

People this is all shit.

The idea behind file system security is to "prevent" people from reading files. With your argumentations a key would be as insecure as a password in a file unreadable by anybody else then you. The secury of that system requires a key on disc with proper chmod. If I can provide security for the key than I can also for the password.

And those who call me "lazy" because I don't want to enter the password on each boot should know that I always enter my server password by hand each time I log in. But this peticular server uses my special remote administration key which has a passphrase as complicate and long as you can imagine. You can not keep this passphrase in mind hence it has to be written down somewhere. And if it is written on a piece of paper and hidden in a safe it is as safe as having a file on your file system readable only by you.

So please don't off-topic abou if this is safe or not. The problem is why SCP does not work but SSH does.

----------

## Dlareh

 *Dragonlord wrote:*   

> if it is written on a piece of paper and hidden in a safe it is as safe as having a file on your file system readable only by you.

 

Not true, unless your computer is also hidden in a safe, because otherwise anyone can boot Knoppix to take a look at your "safe" file just as easily as reading a piece of paper.

Basically a chmod 000 file is no more secure than a post-it note under your keyboard.

----------

## Dragonlord

Nothing on a computer is safe if you gain physical access to it. So this argument doesn't really hold. Files on a computer are considered safe if you can not access them from an outside connection. It's like a car. There's not much sense in preventing people from breaking the car open if you can't prevent them from picking up the entire car.

----------

## Dlareh

 *Dragonlord wrote:*   

> Nothing on a computer is safe if you gain physical access to it. So this argument doesn't really hold.

 

It holds 100% because you are comparing it to gaining physical access to a piece of paper.

 *Dlareh wrote:*   

> Basically a chmod 000 file is no more secure than a post-it note under your keyboard.

 

Remember this, it's important.  It's not intuitive to some people, but it's very true.

----------

## Ast0r

 *Dragonlord wrote:*   

> Nothing on a computer is safe if you gain physical access to it. So this argument doesn't really hold. Files on a computer are considered safe if you can not access them from an outside connection. It's like a car. There's not much sense in preventing people from breaking the car open if you can't prevent them from picking up the entire car.

 

I have a friend who keeps his key on a USB thumb drive. If you are sure that you will never lose it and keep it on you at all times, then I guess you could keep one of there with no passphrase. I can't recommend not using a passphrase though.

----------

## contextswitch

Trying to get back to the reason for the original post ...   :Smile: 

Dragonlord, I still think that ssh-agent and keychain / pam_ssh would provide a good enough compromise for you (but only you can decide this of course).  Re-reading your posts I think you have mis-understood something (and I apologise if this is not the case):

When you use ssh-agent you still need to provide a password but this password is the one for access to your local key file and this can be anything memorable for you.  The keys within this file are supplied by ssh-agent to ssh so that ssh can then do its public/private key authentication magic.

So you no longer have to remember that long and cryptic password only the password you set for your local key file and if you use keychain then you only need to supply this password after a boot.

-- 

Geoff

----------

## Dragonlord

Ok, if I only need a master password for the key-chain then this is a solution. I have another less cryptic password which allows me to hook remotly up on my server and this one is memorizable but still rather secure. Sounds like an idea then. Let's have a look at it.

Finally a "productive" post after a long drought of nonsense in this topic   :Rolling Eyes: 

EDIT: Doesn't work unfortunatly. I still have to enter the cryptic password each time I start the keychain hence this solution doesn't work too. Nice try.

----------

## contextswitch

 *Dragonlord wrote:*   

> 
> 
> EDIT: Doesn't work unfortunatly. I still have to enter the cryptic password each time I start the keychain hence this solution doesn't work too. Nice try.

 

Odd, I use this technique on a remote server and it works fine   :Confused: 

Have you set up the public and private keys?  This article may help.  It's in three parts but probably only parts 1 and 2 are relevant.

-- 

Geoff

----------

## Dragonlord

I guess the problem is that this machine I use for remote administrating runs not all day long but is shut down every night. Hence on every boot the key-cache is empty and the problem starts again. Granted the key-chain would prevent me from entering the password during a day but that has not been the major idea.

If really nothing else works I have to change the password to what I use for my own server but I hate doing this as ( although I remeber this password well and it is strong ) in the worst imaginable case of somebody somehow getting this password he gains access to the main server here and this i want to prevent in any case. Without the same password it could only happen somebody gains access to the outpost servers which are not vital.

----------

## contextswitch

 *Dragonlord wrote:*   

> I guess the problem is that this machine I use for remote administrating runs not all day long but is shut down every night.

 

I think the problem is down to ssh itself not using the public/private key pair, at least that's my guess.

Before any of this can work though you have to set up ssh to use a public/private key pair, in a nutshell this means:

Using ssh-keygen to generate a key pair on your local machine

Using scp to copy the public key from the local machine to the remote one (you'll have to use the long password I'm afraid)

Putting this public key into /home/<user>/.ssh/authorized_keys on the remote machine

At this point you should be able to use ssh to login to the remote machine without entering a password, now you need to set up ssh-agent and then keychain or pam_ssh to give it some persistence.

Have a read at the link I provided, it's a bit wordy but if you follow it then you should get secure remote logons without entering a password (except for the first time after a reboot of the local machine).

-- 

GeoffLast edited by contextswitch on Fri Oct 27, 2006 12:13 pm; edited 1 time in total

----------

## Dragonlord

What you propose is using a non-encrypted private key and this I do not want. The article states says too that a non-encrypted priv-key is the worst so your idea can not work with a properly encrypted private key.

----------

## contextswitch

 *Dragonlord wrote:*   

> What you propose is using a non-encrypted private key and this I do not want. The article states says too that a non-encrypted priv-key is the worst so your idea can not work with a properly encrypted private key.

 

 :Surprised:  No no no   :Shocked: 

I'm sorry, I'm not making myself clear.  I'm trying to understand why you are still asked for the password to the remote machine when you log on to it.  If you have set up the public/private key pair then ssh should use that and the only password you have to enter is the one for the local private key.

It's been a while since I looked into such things but, as far as I remember, ssh will ask you for the password if it doesn't detect the public key in the ~/.ssh directory or if sshd has not been configured to use the key pair scheme.

I'm betting on the former because use of the keypair is normally on by default, at least in Debian (although I may be wrong).

-- 

Geoff

----------

## Dragonlord

Nope, you misunderstand me. I am asked for the priv-key password and not the account password. Problem is upon reboot I have to re-enter this password and this has not been the main idea.

----------

## Dlareh

 *Dragonlord wrote:*   

> upon reboot I have to re-enter this password and this has not been the main idea.

 

This will always be the case with secure solutions like pam-ssh and keychain.

There is simply no way for it to remember your password across reboots without saving it to disk somewhere, and if it were to do that it would be no more secure than a chmod 700 file or passwordless key.

----------

## contextswitch

 *Dragonlord wrote:*   

> Nope, you misunderstand me. I am asked for the priv-key password and not the account password. Problem is upon reboot I have to re-enter this password and this has not been the main idea.

 

This is the compromise I mentioned earlier, at least the private key password can be memorable and reasonably short and you will avoid the long and cryptic password of the server account, that's got to be better hasn't it?

Sorry for the misunderstanding, I am trying to help, honest   :Smile: 

-- 

Geoff

----------

## Dragonlord

Nah, the priv-key has the cryptic password and not the server account. But like mentioned I guess there is no other way than using a similar pwd to the one I have on the main server.

----------

