Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^12: [OT] A New Everything ?

by Aldebaran (Deacon)
on Sep 25, 2020 at 07:07 UTC ( #11122190=note: print w/replies, xml ) Need Help??


in reply to Re^11: [OT] A New Everything ?
in thread [OT] A New Everything ?

Aldebaran is telling you that /home/fred does not exist.

That did throw me for my first of many "what the heck" moments. I soon created barney with the right command. I misunderstood a good handful of things in trying to get barney's ssh squared away, so I moved on to wilma. I needed to have directories and files set with proper ownership, e.g. wilma needs to own .ssh . One thing I was reading wrong was that I thought authorized_keys was a directory that contained files. Not so.

We're getting deep down into the weeds of this thread, and I've gotten a lot of great help on a nebulus and moving target, but we get fewer eyes down here, and I don't want to punish the people who are helping me by keeping it going forever. I'm close with wilma and I think I'm gonna get over on betty. Here's my latest attempt with wilma:

root@third:/home/wilma/.ssh/authorized_keys# mv id_rsa.pub ../ root@third:/home/wilma/.ssh/authorized_keys# cd .. root@third:/home/wilma/.ssh# ls authorized_keys id_rsa.pub root@third:/home/wilma/.ssh# rmdir authorized_keys/ root@third:/home/wilma/.ssh# echo id_rsa.pub >>authorized_keys -rw-r--r-- 1 wilma wilma 419 Sep 25 02:46 id_rsa.pub root@third:/home/wilma/.ssh# chown wilma:wilma authorized_keys root@third:/home/wilma/.ssh# cd .. root@third:/home/wilma# chown wilma:wilma .ssh root@third:/home/wilma# chmod 700 .ssh root@third:/home/wilma# ls -la ... drwx------ 2 wilma wilma 4096 Sep 25 06:16 .ssh ... root@third:/home/wilma# cd .ssh/ root@third:/home/wilma/.ssh# chmod 600 authorized_keys root@third:/home/wilma/.ssh# exit logout Connection to 143.110.153.42 closed. $ ssh wilma@143.110.153.42 wilma@143.110.153.42: Permission denied (publickey). $ ssh -v wilma@143.110.153.42 OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 143.110.153.42 [143.110.153.42] port 22. debug1: Connection established. debug1: identity file /home/hogan/.ssh/id_rsa type 0 debug1: key_load_public: No such file or directory debug1: identity file /home/hogan/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/hogan/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/hogan/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/hogan/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/hogan/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/hogan/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/hogan/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 debug1: Remote protocol version 2.0, remote software version OpenSSH_8 +.2p1 Ubuntu-4ubuntu0.1 debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0 +4000000 debug1: Authenticating to 143.110.153.42:22 as 'wilma' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: + <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: + <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:D6XoS17x+bi8QeACsX +mMrZeRDV9bOVcPIJ94zP9xZx4 debug1: Host '143.110.153.42' is known and matches the ECDSA host key. debug1: Found key in /home/hogan/.ssh/known_hosts:2 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed2551 +9@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-ni +stp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256 +@openssh.com> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:bBpP0w2TsMSLQyp0qTPPZ0pQFS5SZf +Rz4aS9S3xHjhA /home/hogan/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Trying private key: /home/hogan/.ssh/id_dsa debug1: Trying private key: /home/hogan/.ssh/id_ecdsa debug1: Trying private key: /home/hogan/.ssh/id_ed25519 debug1: No more authentication methods to try. wilma@143.110.153.42: Permission denied (publickey).

Thanks all for comments.

Replies are listed 'Best First'.
Re^13: [OT] A New Everything ?
by hippo (Chancellor) on Sep 25, 2020 at 08:45 UTC
    root@third:/home/wilma/.ssh# echo id_rsa.pub >>authorized_keys

    The authorized_keys file is not a list of filenames; it is a list of keys themselves. At this point you should just have done something akin to

    $ cat id_rsa.pub > authorized_keys

    HTH.


    🦛

      better >> than > to avoid clobbering. Alternatively ssh-add might be available.
        better >> than > to avoid clobbering.

        Ordinarily yes. In this case however, the file is apparently full of nonsense so clobbering is actually more desirable.

        Alternatively ssh-add might be available.

        ssh-add has no effect on the contents of the authorized_keys file. It is only useful for adding local keys to a local agent.


        🦛

Re^13: [OT] A New Everything ?
by marto (Cardinal) on Sep 25, 2020 at 11:17 UTC

    You'd have saved yourself a lot of time and effort if you'd read the DigitalOcean tutorials on this subject.

      You'd have saved yourself a lot of time and effort if you'd read the DigitalOcean tutorials on this subject.

      Maybe. I wouldn't say the time was wasted when I needed to read up so much with unix again, along with a new vendor to me, DigitalOcean. Also, I just had to make half a dozen big mistakes on my own time, but success was achieved 12 days after my first droplet formed. I may have twisted my arm off patting my own back when I used vi correctly, but ALL THREE TIMES, I locked myself out. Somewhere along the line, I found the button for "send me a new root password."

      Furthermore, I wouldn't call the process as linear as digital ocean might make it seem with their hyperlinks. set-up-ssh-keys has many pointers, but I don't think it has anything about chown'ing and chmod'ing .ssh and authorized_keys. Many hyperlinks don't make the search more specific.

      The above gives this line of code, which I could never get to work:

      cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

      Similarly, I couldn't get this to work, and not for lack of trying:

      ssh-copy-id -i id_rsa.pub wilma@143.110.153.42

      What did work was doing it from scratch. From my laptop:

      scp id_rsa.pub root@164.90.158.33::/home/fred/.ssh

      Log-in as root one last time:

      root@fourth:/home/fred# cd .ssh/ root@fourth:/home/fred/.ssh# ls -al total 12 drwx------ 2 fred fred 4096 Sep 26 23:38 . drwxr-xr-x 3 fred fred 4096 Sep 26 23:36 .. -rw-r--r-- 1 root root 419 Sep 26 23:38 id_rsa.pub root@fourth:/home/fred/.ssh# cat id_rsa.pub > authorized_keys root@fourth:/home/fred/.ssh# chown fred:fred authorized_keys root@fourth:/home/fred/.ssh# chmod 600 authorized_keys -rw------- 1 fred fred 419 Sep 26 23:43 authorized_keys -rw-r--r-- 1 root root 419 Sep 26 23:38 id_rsa.pub root@fourth:/home/fred/.ssh#

      And finally, log-in as fred:

      fred@fourth:~/.ssh$ ls -al total 16 drwx------ 2 fred fred 4096 Sep 26 23:43 . drwxr-xr-x 4 fred fred 4096 Sep 26 23:46 .. -rw------- 1 fred fred 419 Sep 26 23:43 authorized_keys -rw-r--r-- 1 root root 419 Sep 26 23:38 id_rsa.pub fred@fourth:~/.ssh$ .. fred@fourth:~$ ls -al total 32 drwxr-xr-x 4 fred fred 4096 Sep 26 23:46 . drwxr-xr-x 3 root root 4096 Sep 26 20:57 .. -rw-r--r-- 1 fred fred 925 Sep 26 23:39 .bash_aliases -rw-r--r-- 1 fred fred 220 Sep 26 20:57 .bash_logout -rw-r--r-- 1 fred fred 3771 Sep 26 20:57 .bashrc drwx------ 2 fred fred 4096 Sep 26 23:46 .cache -rw-r--r-- 1 fred fred 0 Sep 26 20:57 .cloud-locale-test.skip -rw-r--r-- 1 fred fred 807 Sep 26 20:57 .profile drwx------ 2 fred fred 4096 Sep 26 23:43 .ssh fred@fourth:~$

      Thanks all for criticisms and comments,

        Thanks all for criticisms and comments,

        None of it was critical of you. Pointing out a deprecated command was being used improperly, and suggesting that reading the docs would help. On DO, like most of these platforms I've used they provide a trivial way to supply ssh keys before VMs/droplets(whatever) are created, making management a breeze and providing better security from the get go. On DO sadly the default is left at 'password' in the Authenticator section. Their quick start section and how tos cover this in more detail. N.B. that some of the user provided documentation has corrections from DO, usually found at the bottom.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11122190]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2020-12-04 05:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How often do you use taint mode?





    Results (58 votes). Check out past polls.

    Notices?