• Automate user/pass transmission?

    From Dieter Braun@1:0/0 to All on Mon Nov 25 09:36:57 2013
    Hi newsgroup,

    I am trying to write a maintenance script which connects to a server via SSH and cleans up several files..
    I know e.g. that you can transmit username and password of HTTP Auth like http://user:pass@some.server.com, but how can I write a simple bash file to connect via SSH?
    I tried so far: - ssh dbraun@176.94.109.57 -p ku2jsx9r
    - ssh -p ku2jsx9r dbraun@176.94.109.57

    but neither works..

    Can anyone help?

    Thank you,
    Dieter

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Richard Kettlewell@110:110/2002 to All on Mon Nov 25 10:13:00 2013
    Dieter Braun <dbraun@gmx.net> writes:
    I am trying to write a maintenance script which connects to a server
    via SSH and cleans up several files..
    I know e.g. that you can transmit username and password of HTTP Auth
    like http://user:pass@some.server.com, but how can I write a simple
    bash file to connect via SSH?
    I tried so far: - ssh dbraun@176.94.109.57 -p ku2jsx9r
    - ssh -p ku2jsx9r dbraun@176.94.109.57

    but neither works..

    I don’t know why you think -p would provide a password.

    Can anyone help?

    Use public key authentication instead.

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Anjou (110:110/2002@linuxnet)
  • From Jamma Tino Schwarze@110:110/2002 to All on Mon Nov 25 10:14:06 2013
    Hi Dieter,

    Dieter Braun <dbraun@gmx.net> wrote:

    I am trying to write a maintenance script which connects to a server
    via SSH and cleans up several files.. I know e.g. that you can
    transmit username and password of HTTP Auth like http://user:pass@some.server.com, but how can I write a simple bash
    file to connect via SSH?
    I tried so far: - ssh dbraun@176.94.109.57 -p ku2jsx9r
    - ssh -p ku2jsx9r dbraun@176.94.109.57

    You are looking for public key authentication. Providing passwords in
    clear text is a bad idea.

    Short HOWTO:
    - on CLIENT
    * run ssh-keygen -t dsa, no to enter a pass phrase
    * scp .ssh/id_dsa.pub dbraun@176.94.109.57:client-id_dsa.pub
    - on SERVER:
    * mkdir .ssh
    * cat client-id_dsa.pub >> .ssh/authorized_keys

    Afterwards, a simple "ssh dbraun@176.94.109.57" should work without
    prompting for a password.

    Of course, take care to secure .ssh/id_dsa since it holds the private
    key neccessary for login.

    HTH,

    Jamma.

    --
    "What we nourish flourishes." - "Was wir nhren erblht."

    www.tisc.de

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Individual Network Chemnitz, FRG (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Mon Nov 25 21:24:55 2013
    On Mon, 2013-11-25, Jamma Tino Schwarze wrote:
    Hi Dieter,

    Dieter Braun <dbraun@gmx.net> wrote:

    I am trying to write a maintenance script which connects to a server
    via SSH and cleans up several files.. I know e.g. that you can
    transmit username and password of HTTP Auth like
    http://user:pass@some.server.com, but how can I write a simple bash
    file to connect via SSH?
    I tried so far: - ssh dbraun@176.94.109.57 -p ku2jsx9r
    - ssh -p ku2jsx9r dbraun@176.94.109.57

    I hope that wasn't your real password on that host!

    You are looking for public key authentication. Providing passwords in
    clear text is a bad idea.

    Short HOWTO:
    - on CLIENT
    * run ssh-keygen -t dsa, no to enter a pass phrase
    * scp .ssh/id_dsa.pub dbraun@176.94.109.57:client-id_dsa.pub
    - on SERVER:
    * mkdir .ssh
    * cat client-id_dsa.pub >> .ssh/authorized_keys

    Afterwards, a simple "ssh dbraun@176.94.109.57" should work without
    prompting for a password.

    Of course, take care to secure .ssh/id_dsa since it holds the private
    key neccessary for login.

    And be damn sure the owners of any system where that key allows access
    are fine with it existing in a passphrase-less form somewhere.

    Personally I would not allow it.

    A better way to do periodic maintenance is usually via a cron job on
    the server. No networking or login is involved then.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Adam Wysocki@110:110/2002 to All on Tue Dec 3 13:53:22 2013
    Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

    And be damn sure the owners of any system where that key allows access
    are fine with it existing in a passphrase-less form somewhere.

    If they're not, they can disable it in sshd config.

    AW

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: ATMAN - ATM S.A. (110:110/2002@linuxnet)
  • From Richard Kettlewell@110:110/2002 to All on Tue Dec 3 17:25:04 2013
    gof@somewhere.invalid (Adam Wysocki) writes:
    Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    And be damn sure the owners of any system where that key allows access
    are fine with it existing in a passphrase-less form somewhere.

    If they're not, they can disable it in sshd config.

    Even if they couldn’t it’d be a pretty confused objection in context. A password stored on disk, as proposed, is no better than a key stored on
    disk (assuming for the sake of argument that both are comparably
    strong).

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Anjou (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Wed Dec 4 23:14:05 2013
    On Tue, 2013-12-03, Richard Kettlewell wrote:
    gof@somewhere.invalid (Adam Wysocki) writes:
    Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
    And be damn sure the owners of any system where that key allows access
    are fine with it existing in a passphrase-less form somewhere.

    If they're not, they can disable it in sshd config.

    How? The answer is not "PermitEmptyPasswords no" if that's what
    you're thinking; that doesn't apply to public key authentication.

    As I understand it, the unlocking of the secret key is completely out
    of the server's control, so there is no way to disable it on the
    server side.

    Even if they couldn???t it???d be a pretty confused objection in context. A password stored on disk, as proposed, is no better than a key stored on
    disk (assuming for the sake of argument that both are comparably
    strong).

    I never suggested anyone should store plaintext passwords on disk (or
    for that matter, place them on the command line for everyone to see).

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Richard Kettlewell@110:110/2002 to All on Wed Dec 4 23:24:24 2013
    Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
    On Tue, 2013-12-03, Richard Kettlewell wrote:

    Even if they couldn’t it’d be a pretty confused objection in context.
    A password stored on disk, as proposed, is no better than a key
    stored on disk (assuming for the sake of argument that both are
    comparably strong).

    I never suggested anyone should store plaintext passwords on disk (or
    for that matter, place them on the command line for everyone to see).

    “in context” is the bit you seem to be missing. Have a look at the OP’s original guess.

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Anjou (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Sat Dec 7 09:40:33 2013
    On Wed, 2013-12-04, Richard Kettlewell wrote:
    Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
    On Tue, 2013-12-03, Richard Kettlewell wrote:

    Even if they couldn???t it???d be a pretty confused objection in context. >>> A password stored on disk, as proposed, is no better than a key
    stored on disk (assuming for the sake of argument that both are
    comparably strong).

    I never suggested anyone should store plaintext passwords on disk (or
    for that matter, place them on the command line for everyone to see).

    ???in context??? is the bit you seem to be missing. Have a look at the
    OP???s
    original guess.

    Well, I thought it was obvious already that passwords on the command
    line is a Really Bad Idea. Surely it must be ok to point out that
    something is insecure, without listing all the even worse alternatives?

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Adam Wysocki@110:110/2002 to All on Sat Dec 7 12:43:26 2013
    Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

    And be damn sure the owners of any system where that key allows access >>>> are fine with it existing in a passphrase-less form somewhere.

    If they're not, they can disable it in sshd config.

    How?

    You're right, I missed the "passphrase-less" part and I was talking
    about completely disabling public key authentication.

    AW

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: ATMAN - ATM S.A. (110:110/2002@linuxnet)
  • From Adam Wysocki@110:110/2002 to All on Sat Dec 7 12:45:15 2013
    Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

    Well, I thought it was obvious already that passwords on the command
    line is a Really Bad Idea.

    It all depends on the configuration. If he for example has his personal
    LAN with two computers, without other users and without connection to
    the Internet, then I would justify it. Maybe security doesn't matter in
    this specific case, we don't know.

    But in most cases you're right.

    AW

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: ATMAN - ATM S.A. (110:110/2002@linuxnet)