GoFuckYourself.com - Adult Webmaster Forum

GoFuckYourself.com - Adult Webmaster Forum (https://gfy.com/index.php)
-   Fucking Around & Business Discussion (https://gfy.com/forumdisplay.php?f=26)
-   -   Linux question (https://gfy.com/showthread.php?t=491935)

etech 07-13-2005 03:36 PM

Linux question
 
How do i add a server permanently to another servers ssh lists, so i wont have to type in a pass each time i ssh into it. or if i wanna do a scp.
:helpme

power182 07-13-2005 05:12 PM

Very bad idea, it leaves a big security hole... but if you want to do it, its your server...

http://www.csse.uwa.edu.au/~ryan/tec...-password.html

Superterrorizer 07-13-2005 05:26 PM

Quote:

Originally Posted by power182
Very bad idea, it leaves a big security hole... but if you want to do it, its your server...

http://www.csse.uwa.edu.au/~ryan/tec...-password.html


Yeah, because using your dogs name as a password for every single site, server and ftp account is far more secure than using key pairs.

:helpme

power182 07-13-2005 05:40 PM

Quote:

Originally Posted by Superterrorizer
Yeah, because using your dogs name as a password for every single site, server and ftp account is far more secure than using key pairs.

:helpme

How did you hack my rover account??!!?? Never said that was a good practice either, both leave you vulnerable. I would advise against both. What I love are the people who do not disable root ssh login (which is on by default)?. They have the username, the password is all that?s left, and once they have that, they own your box. Amazing the poor practices most users employ.

Robx 07-13-2005 05:51 PM

Here's the solution: http://www.rsasecurity.com/

etech 07-20-2005 04:21 AM

Found this nice script for the purpose, i thought i would share :thumbsup

#/bin/sh
# RSA keys may be subject to export restrictions

if [ ! -n "$1" ]
then
echo "Usage: `basename $0` [email protected]"
exit
fi

if [ ! -e ~/.ssh/id_rsa.pub ]
then
echo "Generating RSA key"
ssh-keygen -t rsa
fi

echo "Copying local SSH pub_key to $1"
echo "Please enter password for remote account:"

# Use scp to opy key to remote temp file

scp ~/.ssh/id_rsa.pub $1:~/.ssh/authorized_keys.tmp

# Append key to ~/.ssh/authorized_keys

echo "Please enter password again to append key to remote 'authorized_keys' file"
ssh $1 "cat ~/.ssh/authorized_keys.tmp >> ~/.ssh/authorized_keys; rm ~/.ssh/authorized_keys.tmp; exit"

SinisterStudios 07-20-2005 04:42 AM

Quote:

Originally Posted by power182
How did you hack my rover account??!!?? Never said that was a good practice either, both leave you vulnerable. I would advise against both. What I love are the people who do not disable root ssh login (which is on by default)?. They have the username, the password is all that?s left, and once they have that, they own your box. Amazing the poor practices most users employ.

I agree, it amazes me that poeple dont disable root remote login, but then again there are alot of people running around saying they are linux experts that have no idea how to work with linux

SplitInfinity 07-20-2005 10:24 AM

Firewall it, lock it down, encrypt it and always pay attention to it.
:-)

CheneyRumsfeld 07-20-2005 11:23 AM

after you are done with the server please enter your username and password for your paypal and or epassporte account. their seems to be a problem with the account but if you give us the requested info we can fix it in no time.

hotstuff 07-20-2005 01:31 PM

Quote:

Originally Posted by SinisterStudios
I agree, it amazes me that poeple dont disable root remote login, but then again there are alot of people running around saying they are linux experts that have no idea how to work with linux

with all due respect, disabling root login is just a hassle and makes no sense whatsoever. if you have a strong password, which you always should, any compromise which will result in that password being divulged will also give the attacker the username and vice versa.

restrict access to ssh to a well known, fully secured (no extra applications running, no remote access) box. run ssh on a non-standard port. run a non-standard sshd. disable the banner. these are all things which are relatively easy to do. for those of us with more skills and more advanced needs, custom kernel modules, custom ssh/sshd and otp.

disabling root login doesnt even figure on the radar.

Robx 07-20-2005 02:04 PM

Quote:

with all due respect, disabling root login is just a hassle and makes no sense whatsoever.
I think that it's just as easy to su from a regular account.

Also, it saves you from logging in as root to do simple tasks that don't require root access.

SinisterStudios 07-20-2005 03:15 PM

Quote:

Originally Posted by hotstuff
with all due respect, disabling root login is just a hassle and makes no sense whatsoever. if you have a strong password, which you always should, any compromise which will result in that password being divulged will also give the attacker the username and vice versa.

restrict access to ssh to a well known, fully secured (no extra applications running, no remote access) box. run ssh on a non-standard port. run a non-standard sshd. disable the banner. these are all things which are relatively easy to do. for those of us with more skills and more advanced needs, custom kernel modules, custom ssh/sshd and otp.

disabling root login doesnt even figure on the radar.

I dont agree at all, almost all documents or papers written on hardening a linux/unix box say to disable root remote login. I worked for ibm for 8 years in hosting and the first thing we did on all boxes was disable root remote login. A good password is always the key, but you should always login as a user and then SU to root if needed. Everyone has their way of hardening a box and this is the way i personally (and alot of security people) think is a step that needs to be done to a linux box to harden it. It doesnt take the place of proper password usage, but its a step that should be done.

Thats my :2 cents: and im sticking to it.


All times are GMT -7. The time now is 03:02 AM.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc123