I have a client and I need to access their FTP and it’s an SSH FTP. I’ve never accessed one before. He gave me his credentials.
I have the server address (starts with sftp) that includes the username and a port number. He also gave me the public and private keys. I don’t know how to access this ftp. I’m using Cyberduck. I save my info there and would prefer to use it but if I can get any advice on how to do this using anything, that would be great.
So I have a login name, NO password, public and private keys, and a server address. I am unable to connect. How should I do this?
Right on @ZooKeeper! The public/private keys are all you need, as they replace the password. Granted, you can take it one step further and have the private key require a password too, but many do not go that far, as the keys themselves are very secure (unless you pas them around…)
You don’t really need the public key, unless the key pair hasn’t been set up and configured properly.
The SFTP client (Cyberduck?) will use the private key to authenticate against the public key (which depends on the SFTP server being configured to properly read this public key). Typically, you put the public key in a specific directory in a specific file (with appropriate permissions), typically this is in /home/%user%/.ssh. Typically the filename is id_dsa or id_rsa, but it can vary depending on how the SFTP server is configured. If this hasn’t been done, then you won’t be able to connect with the private key.
Sometimes the private key is encrypted and requires a passphrase to decrypt the private key before it is checked against the public key.
As the name suggests, the private key is meant to be kept private. Generally you don’t pass those around - it kind of defeats the point of public/private key encryption.
Wow. This is much more complex than I imagined. I don’t entirely understand what you’re describing.
It’s likely my client didn’t know what to do with the keys he sent me. I assumed I shouldn’t have to have a private key but I still don’t know what to do with them.
So Cyberduck allows me to select a public key available but you’re saying that the public key has to be located in a specific location on my local machine in order to work? I loaded my public key, entered the server, and proper port number. No results.
It might be a DNS issue. I tried to access the site several times and I think they blocked my IP… I fucking hate that.
Specifically the section labeled Asymmetrical Encryption and even more specific, the last two paragraphs in that section.
I was wrong in my above post, the public key typically goes on the server in the .ssh directory in the file named authorized_keys
The idea here is that - the client (anybody that is going to connect to the system) - would generate their own public/private key pair. You would keep your private key completely to yourself. You would have to give the public key to someone that has administrative rights to the account and can append the authorized_keys file to include your public key. This also assumes that this administrator wants you to be able to connect to the account. This administrator never sees your private key. When you try to connect, the server sends an encrypted challenge with one of these authorized_keys, if you have a private key that can decrypt it and accept the challenge, then you are allowed to connect.
All of this is probably immensely over kill if you do not understand this. If you are a developer and work with many different clients, it would behoove you to garner a better understanding of this. It would also behoove the client to better understand this. But - real world application has taught us, no matter how well intentioned a security measure is, if it’s too complex, most people don’t care to take the time to better understand it and just stick with what they know. That’s one reason why we still have people using stupid passwords in 2017.
Succumbing to the masses, you’re probably just as well off to ask the client for their username and password and use password authentication instead of public/private key pairs.